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
10 matches
Mail list logo
