Closed Bug 716549 Opened 8 years ago Closed 8 years ago

Flush layout on mousemove events so that they get delivered to the right place

Categories

(Core :: User events and focus handling, defect, P1)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

This is spun off from bug 598482 so we can land part 24 of that without all the other bits.
https://hg.mozilla.org/integration/mozilla-inbound/rev/04e2d8313601
Assignee: nobody → bzbarsky
Flags: in-testsuite+
Priority: -- → P1
Target Milestone: --- → mozilla12
Blocks: 598482
This caused about a 5% Tdhtml MozAfterPaint regression.  It seems to all be concentrated in the layers1 (57% regression) and scrolling (120% regression) tests.

Are we dispatching the synthetic mousemoves sync and triggering flushes on those or something?  If so, would it make sense to not flush on synthetic mousemoves, if we can detect them here?
Can we dispatch synthetic mousemoves after we've flushed in the refresh driver, or something like that?

I'd actually like to dispatch mousemoves in the refresh driver too, to help reduce flushing.
https://hg.mozilla.org/mozilla-central/rev/04e2d8313601
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Hmm.  That might be doable, yes.  I just pushed a patch to that effect to try; if it pans out I'll ask for review in a followup bug.
Depends on: 716793
Blocks: 627628
Depends on: 777590
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.