mousemove event trigger granularity

[Mitch Germansky <mb...@cs.rutgers.edu>]

i am new in this svg batik world and am looking at some performance 
issues related to handling mouse events for an app that allows user 
mousemove events to render lines on the display.  i observe performance 
differences on a winxp laptop with mouse input vs. pen input on a winxp 
tablet; also performance diffs between pen and mouse on the same winxp 
tablet.

can someone educate me as to the granularity of how often the mousemove 
event triggers, how it varies across various platforms and input 
devices, and whether this is tunable?

on 
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-mouseevents 
i see

"The mousemove event occurs when the pointing device is moved while it 
is over an element. This event is valid for most elements."

TIA...
-mitch



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

RE: mousemove event trigger granularity

[Thomas E Deweese <th...@kodak.com>]

>>>>> "MG" == Mitch Germansky <mb...@cs.rutgers.edu> writes:

MG> i am new in this svg batik world and am looking at some
MG> performance issues related to handling mouse events for an app
MG> that allows user mousemove events to render lines on the display.
MG> i observe performance differences on a winxp laptop with mouse
MG> input vs. pen input on a winxp tablet; also performance diffs
MG> between pen and mouse on the same winxp tablet.

MG> can someone educate me as to the granularity of how often the
MG> mousemove event triggers, how it varies across various platforms
MG> and input devices, and whether this is tunable?

    So my guess (and it is only a guess) is that when a pen is used
with a tablet the OS hugely increases the number of 'mouse move'
events generated so that handwriting recog can be done.  I have no
idea if this is tunable in Windows.

    In Batik we already do some mouse-move compression, but doing this
still takes some significant work as we need to figure out if the
mouse has changed the element it is over - if so we consider this a
significant mouse event that can not be compressed, doing this check
requires walking the rendering tree checking for point inclusion.

    It might be possible to add a second level of mouse compression
that just 'throws away' mouse events if they happen too quickly (say
limit it to 10-20 mouse events/sec - more than enough for user
feedback).  The tricky bit is that it is _REALLY_ important that the
last event (even for pauses) not be thrown away - but of course you
don't know it's the last event until no more events come :) So you
would need to have a timer that if it expires triggers the sending of
the mouse event you were otherwise going to throw away.

    Anyway this is not a trivial addition although it is probably
fairly localized.  You might also be able to optimize the existing
mouse event compression code somewhat - and get performance back.


MG> on
MG> http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-mouseevents
MG> i see

MG> "The mousemove event occurs when the pointing device is moved
MG> while it is over an element. This event is valid for most
MG> elements."

MG> TIA...  -mitch



MG> ---------------------------------------------------------------------
MG> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org For
MG> additional commands, e-mail: batik-users-help@xml.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org