W3C home > Mailing lists > Public > www-svg@w3.org > May 2003

RE: mousemove event trigger granularity

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Tue, 27 May 2003 08:55:49 -0400
Message-ID: <16083.24661.189270.315728@frog.rl.kodak.com>
To: Batik Users <batik-users@xml.apache.org>
Cc: www-svg@w3.org, Mitch Germansky <mbg@cs.rutgers.edu>

>>>>> "MG" == Mitch Germansky <mbg@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
Received on Tuesday, 27 May 2003 09:01:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:56 UTC