[haiku-appserver] Re: GetMouse()

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 19 May 2005 19:35:56 +0200 CEST

Axel D=F6rfler wrote on Thu, 19 May 2005 19:05:16 +0200 CEST:

> > One thing I'm wondering about: How about doing the stuff we now do 
> > in 
> > BView::GetMouse() in BWindow::UpdateIfNeeded()=3D3F We will need this 
> > for 
> > synchronous BAlerts::Go() too BTW. BView::GetMouse() could then use 
> > UpdateIfNeeded(). I haven't looked very close at that code, so I 
> > might 
> > be way off here.
> I just had a look, and indeed, these are very similar - or should be, 
> in fact, UpdateIfNeeded() doesn't work as it's done now; it would 
> need 
> to be something more like GetMouse() or even should call DoUpdate() 
> directly.

I saw you fixed it in SVN already. I wonder if BAlerts are already 
working now. But I'm currently busy with WonderBrush. I finally worked 
out editing a gradient transformation... :-) 

You could add an About button to Playground and check out BAlerts, if 
you liked. :-)

> But as I think about it: it's a bad idea that there is always only 
> one 
> =5FUPDATE=5F message in the queue, as it slows down the whole thing quite 
> a 
> lot; the latency between to (necessary) =5FUPDATE=5F messages is 
> increased 
> a lot this way and for no reason.

app=5Fserver will combine update requests from the client. Until a window 
has performed one request, no new ones will be sent to it, if I 
understood Adi correctly. It looked to me the right way to go 
(combining updates), but maybe we have not seen something or there is a 
catch in the implementation.

> BTW I have tried several apps now under Haiku, and some of them even 
> run (R5 & Haiku DataTranslation preferences apps, for example, even 
> though both look kinda strange).
> Many of them will let the app=5Fserver crash.


> How would I try FFM with our app=5Fserver=3F The Mouse preferences app 
> doesn't work yet (it's one of those that let the app=5Fserver crash 
> here) 
> :-)

I don't think it is supported yet. IIRC, I came across a TODO remark. 
Again, have a look at RootLayer.cpp.

> Also, why is moving windows so damn slow=3F I thought it would use 
> hardware acceleration by now=3F

=3F It does over here. Are you using anything else then a B=5FRGB32 or 
B=5FRGBA32 screen=3F If so, it falls back to double buffered/unaccelerated 
mode without further notice.

Best regards,

Other related posts: