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.
--
Wa
On Sun, Feb 24, 2013 at 1:41 PM, Neil 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 than that.
>>
>>
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, wher
On Sat, Feb 23, 2013 at 5:37 PM, Jonas Sicking wrote:
> Well, my proposal was to default all pages to type 1, and only send them
> mouse events at 60 frames per second.
>
> And then let them opt in to being type 2.
>
> This should be fine since I strongly suspect that type 1 is the by far
> more
On Feb 21, 2013 3:12 PM, "Robert O'Callahan"
wrote:
>
> On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones 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
>
On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones 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 (as per roc's
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
On Tue, Feb 19, 2013 at 7:24 PM, Jonas Sicking 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. The result i
On Tue, Feb 19, 2013 at 8:42 PM, Justin Dolske 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.
>>
>
> Hmm,
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.
Hmm, we could even do a bit of this today without an opt-in -- throttle
eve
On Mon, Feb 18, 2013 at 4:51 PM, Robert O'Callahan wrote:
> On Tue, Feb 19, 2013 at 1:40 PM, Brian Birtles 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 Tue, Feb 19, 2013 at 1:40 PM, Brian Birtles 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:
>
>
> http://parapara
(2013/02/15 11:36), 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 sugges
On Tue, Feb 19, 2013 at 12:44 PM, Karl Tomlinson 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 considerably.
>
On
Robert O'Callahan writes:
> On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson 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, exi
On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson 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.
>
> The gen
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 "ignore
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 th
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
as
On Sat, Feb 16, 2013 at 6:16 AM, Steve Fink 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 think it is s
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 sugges
On 02/14/2013 07:48 PM, Robert O'Callahan wrote:
> On Fri, Feb 15, 2013 at 4:44 PM, John Volikas 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 witho
On 02/14/2013 05:48 AM, Robert O'Callahan wrote:
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg wrote:
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
http://blogs.msdn.com/b/oldne
On Fri, Feb 15, 2013 at 4:44 PM, John Volikas 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 the peri
On Friday, February 15, 2013 4:36:21 AM UTC+2, Robert O'Callahan wrote:
> On Fri, Feb 15, 2013 at 10:14 AM, Benjamin Smedberg
>
> wrote:
>
>
>
> > 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
On Fri, Feb 15, 2013 at 10:14 AM, Benjamin Smedberg
wrote:
> 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
> 60fps would be ad
On 2/13/2013 10:48 PM, Robert O'Callahan wrote:
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg wrote:
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
http://blogs.msdn.com/b/oldnew
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg wrote:
> 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
> http://blogs.msdn.com/b/oldnewthing/archive/2011/12/19/10249000.aspx
>
>
Benjamin Smedberg wrote:
I do wonder if WM_MOUSEMOVE has priority over WM_PAINT so that if the
mouse is moving a lot, that could affect the latency of WM_PAINT.
I think we used to artificially bump keyboard and mouse messages over
posted messages to stop posted messages from affecting the lat
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
http://b
On Wed, Feb 13, 2013 at 5:14 PM, Rob Arnold 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
> other concern is i
On Tue, Feb 12, 2013 at 7:57 PM, Robert O'Callahan wrote:
> On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold 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 do
On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold 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
> is close (wi
Context: bug 837985.
At times we can be flooded by OS-level mousemove events. I think it would
make sense to process mousemoves at most once per refresh driver tick. This
matters for a couple of reasons: mousemove processing can cause arbitrary
JS handlers to run which can do slow things, and also
34 matches
Mail list logo
