[haiku-development] Re: Pe and mouse tracking under Haiku
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 09 Jul 2008 16:14:47 +0200
On 2008-07-09 at 15:18:23 [+0200], Stephan Assmus <superstippi@xxxxxx> wrote:
> Ingo Weinhold wrote:
> > On 2008-07-09 at 12:40:28 [+0200], Stephan Assmus <superstippi@xxxxxx>
> > wrote:
> > > I think that multiple mouse messages in the queue could actually be
> > > intended. For example in WonderBrush, when doing a brush stroke there
> > > may be some delay in processing one ore mouse mouse messages, but
> > > multiple messages are eventually processed at once. If messages would
> > > be dropped, or only send after the application responded, the resulting
> > > stroke would be less smooth.
> >
> > Actually I thought so too first, but I'm not so sure, that this would
> > really happen. If one refrains from doing things that take much time in
> > the window thread, I guess one could still handle thousands of "mouse
> > moved" messages per second. Anyway, if it really turns out to be a
> > problem for graphics apps a BWindow flag to enable unlimited "mouse
> > moved" messages could be added.
> >
> > > I think I have found a good solution, but maybe you or someone else
> > > sees a flaw with that, please point it out of course.
> >
> > Can't see any. I'd still vote for throttling "mouse moved" messages in
> > general, as apart from graphics apps I can't think of any situations in
> > which that wouldn't desirable. I'm quite optimistic that this would also
> > fix the laggy scrollbars encountered when the system is busy.
>
> I do see your point. In BWindow::DispatchMessage() there is already the
> reverse option "B_NO_POINTER_HISTORY" which makes the window drop the
> message if it isn't the last mouse moved message in the queue. We could add
> the a similar behavior for "too old" mouse messages and optionally add a
> flag that alyways gets all messages regardless of their age.
>
> I am wondering if messaging the server back to acknowledge a mouse move
> adds more overhead/latency because of context switching. What do you think?
Sending a message back to the app server isn't really necessary when using
shared memory. I was thinking of client-read-only shared memory for the
current mouse position and client-writable shared memory for a simple flag
indicating that the client would accept another "mouse moved" notification.
The app server would check that flag, send a notification, if desired, and
clear the flag. On the client side when receiving it, the current mouse
position would be fetched from the shared memory, the flag be set again and
the "mouse moved" event be processed.
When a mouse event occurs that requires in-order processing of "mouse moved"
events (i.e. mouse down/up), that could be indicated in the mouse position
shared memory. The client would then use the mouse position sent with the
notification message instead of fetching the latest position.
> > BTW, I'm also all for throttling redraw messages. As experienced when
> > working on the Terminal, it is really counter-productive to redraw 500
> > times per seconds. Capping the redraw frequency at the vertical screen
> > frequency (ideally even synchronizing drawing with the vertical blank)
> > seems to be the least that should be done.
>
> Sounds reasonable. It is probably fairly easy to implement too. The VESA
> based drawing already implements a delayed screen update. I have thought of
> a way to do the same trick for "real" drivers too. It would probably not be
> too hard to delay the back to front "blit" to happen during the retrace.
That would be nice indeed.
CU, Ingo
Other related posts:
