Robert O'Callahan wrote:
WM_MOUSEMOVE events, like other native events, would still take priority over
all Gecko events and potentially starve the refresh driver.
Sorry, I misread the code, I didn't realise that it only prioritised
keyboard and mouse events over other native events.
--
Robert O'Callahan wrote:
I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event
pending, but that sounds kinda scary. I think deferring DOM mousemove events to
the next refresh driver tick would be safer than that.
Currently we peek for WM_MOUSEFIRST to WM_MOUSELAST,
On Sun, Feb 24, 2013 at 1:41 PM, Neil n...@parkwaycc.co.uk wrote:
Robert O'Callahan wrote:
I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event
pending, but that sounds kinda scary. I think deferring DOM mousemove
events to the next refresh driver tick would be safer
On Feb 21, 2013 3:12 PM, Robert Oapos;Callahan rob...@ocallahan.org
wrote:
On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones ajo...@mozilla.com wrote:
We really have to choices:
A. Provide an API that allows applications to specify whether they are
type 1 or type 2. It could be implicitly
On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones ajo...@mozilla.com wrote:
We really have to choices:
A. Provide an API that allows applications to specify whether they are
type 1 or type 2. It could be implicitly done by including a mouse event
history array.
B. Automatically prevent flooding
On Tue, Feb 19, 2013 at 8:42 PM, Justin Dolske dol...@mozilla.com wrote:
On 2/18/13 10:24 PM, Jonas Sicking wrote:
One possible solution is to allow pages to opt in to high-precision
mousemove events. Then a drawing program could do that on the
mousedown event end opt out again on mouseup.
On Tue, Feb 19, 2013 at 7:24 PM, Jonas Sicking jo...@sicking.cc wrote:
But I would expect that in the majority of other cases, each mousemove
event will not leave persisted data and dispatching more mouse moves
will simply mean that the page will redo the same calculations over
and over only.
On 19/02/13 23:52, Robert O'Callahan wrote:
I think my idea for an anti-flood state makes this unnecessary.
There are two distinct use cases:
1. You only care where the mouse currently is.
2. You need to know both where the mouse is and how it got there.
We really have to choices:
A. Provide an
Benjamin Smedberg a écrit :
it's important for certain kinds of drawing apps especially to have as
much mouse input as possible,
Yes
and I doubt that only receiving mouse input at 60fps would be adequate in
general
I don't know if what I'm saying is stupid, but I think it would be seen
How about this idea: after processing a WM_MOUSEMOVE event, go into an
anti-flood state where WM_MOUSEMOVE is ignored. After we service the
Gecko event queue, exit the anti-flood state.
This is very simple and I think it would work well for all cases. When DOM
mousemove handlers are cheap and
Robert O'Callahan writes:
How about this idea: after processing a WM_MOUSEMOVE event, go into an
anti-flood state where WM_MOUSEMOVE is ignored. After we service the
Gecko event queue, exit the anti-flood state.
The general approach sounds good.
I expect ignored will have to be ignored at
On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson mozn...@karlt.net wrote:
Robert O'Callahan writes:
How about this idea: after processing a WM_MOUSEMOVE event, go into an
anti-flood state where WM_MOUSEMOVE is ignored. After we service the
Gecko event queue, exit the anti-flood state.
Robert O'Callahan writes:
On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson mozn...@karlt.net wrote:
Robert O'Callahan writes:
How about this idea: after processing a WM_MOUSEMOVE event, go into an
anti-flood state where WM_MOUSEMOVE is ignored. After we service the
Gecko event queue,
On Tue, Feb 19, 2013 at 12:44 PM, Karl Tomlinson mozn...@karlt.net wrote:
I don't know exactly what happens with WM_MOUSEMOVE, it would seem
unfortunate if a WM_MOUSEMOVE with an updated mouse position is
not received before key events. Changing the order of events
changes the meaning
On Tue, Feb 19, 2013 at 1:40 PM, Brian Birtles bbirt...@mozilla.com wrote:
I'm not sure if this is a relevant data point but we had an issue[1] with
touch event coalescing on fennec that produced poor results for the
following drawing application on some devices such as the Dell Streak:
On Sat, Feb 16, 2013 at 6:16 AM, Steve Fink sf...@mozilla.com wrote:
It suggests a solution where a quick handler sees all mouse move events
and batches them up, delivering the batches at a lower rate (60fps isn't
completely unreasonable). Which is of course completely not
spec-compliant.
I
On 02/14/2013 05:48 AM, Robert O'Callahan wrote:
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
On what OSes? Windows by default coalesces mouse move events. They are
like WM_PAINT events in that they are only delivered when the event queue
is empty. See
On 02/14/2013 07:48 PM, Robert O'Callahan wrote:
On Fri, Feb 15, 2013 at 4:44 PM, John Volikas fero...@gmail.com wrote:
I tried the test on Nightly runnig Windows 7 64bit.
I get up to 1000(!) mousemoves per second but I have a Logitech G400
gaming mouse that defaults to a 1000Hz polling rate
On 2/14/13 6:36 PM, Robert O'Callahan wrote:
I created http://people.mozilla.com/~roc/mousemove-freq.html. We get up to
120-ish mousemoves per second on my machine in Firefox, and a bit more in
IE9, but it caps out at 60fps in Chrome which suggests to me they're doing
something like what I
On Fri, Feb 15, 2013 at 10:14 AM, Benjamin Smedberg
benja...@smedbergs.uswrote:
I think we should try to process mousemoves as quickly as we can: it's
important for certain kinds of drawing apps especially to have as much
mouse input as possible, and I doubt that only receiving mouse input at
On Fri, Feb 15, 2013 at 4:44 PM, John Volikas fero...@gmail.com wrote:
I tried the test on Nightly runnig Windows 7 64bit.
I get up to 1000(!) mousemoves per second but I have a Logitech G400
gaming mouse that defaults to a 1000Hz polling rate without Logitech's
software. I guess it depends
On 2/12/2013 10:18 PM, Robert O'Callahan wrote:
Context: bug 837985.
At times we can be flooded by OS-level mousemove events.
On what OSes? Windows by default coalesces mouse move events. They are
like WM_PAINT events in that they are only delivered when the event
queue is empty. See
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
On what OSes? Windows by default coalesces mouse move events. They are
like WM_PAINT events in that they are only delivered when the event queue
is empty. See
On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold tell...@gmail.com wrote:
Would you want to predict the mouse location based on past events when you
dispatch the synthetic event? I guess it depends on how frequently you get
the events but this is done for touches on mobile where the input frequency
On Tue, Feb 12, 2013 at 7:57 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold tell...@gmail.com wrote:
Would you want to predict the mouse location based on past events when
you dispatch the synthetic event? I guess it depends on how frequently you
On Wed, Feb 13, 2013 at 5:14 PM, Rob Arnold tell...@gmail.com wrote:
I agree; it should be no worse than today. I do have some concerns with
dispatching a mouse move event that contains coordinates the mouse may not
have been at but the visual results for scrolling ought to be nice. Only
26 matches
Mail list logo
