1256727 - [APZ] code mirror's panel with line numbers twitches when I scroll code area horizontally

Status: RESOLVED DUPLICATE of bug 1257641

(Core :: Panning and Zooming, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 48, 32bit, ID 20160313030418
STR:
1. Open https://www.mozilla.org/en-US/firefox/nightly/firstrun/
2. Open Style editor, make sure that the biggest stylesheet is selected
3. Click in the beginning of line 12:   "/*! updated 2015-06-17 */@font-face {"
4. Hover mouse over the code area, rotate mouse wheel down 10 times to make caret not visible
5. Press Right arrow
6. Hover mouse over horizontal scrollbar in source code area, hold left mouse button, 
   then move mouse to the left and right 5 times. Release left mouse button

AR:  The panel with line numbers twitches a log
ER:  Line numbers should stay still

This is regression from bug 1253860. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=412c5cae8dea7b52da7c6981eec6a2a2884897c9&tochange=cd65b31bdeb565c34ae8e9d56107289ce71d9885

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Ok, so I think this is happening because the scroll-offset-update message that I added in bug 1253860 gets sent before the scroll event fires, and so the updates that the scroll event does lag behind the visual scroll position.

Before:
- main thread scroll update
- refresh driver tick
- scroll listener runs
- layout/paint
- transaction to main thread
- visual scroll position update by APZ

Now:
- main thread scroll update
- scroll offset update to compositor
- refresh driver tick
- visual scroll position update by APZ
- scroll listener runs
- layout/paint
- transaction to main thread
- effects of scroll listener visible to user

Comment 2

[Kartikaya Gupta (email:[e-mail])]

To fix this I tried moving the scroll-offset-update message to run after the scroll event was dispatched (synchronously after the call to mHelper->FireScrollEvent() but that didn't quite fix the problem either. It helps, but there's still occasionally a lag between the offset update message arriving, and the updated painted content arriving in the compositor. If we composite between those two then the lag is user-visible.

I'll see if disabling the scroll-offset-update feature on pages with scroll-linked-effects solves the problem. It's analogous to how we had to disable it for windowed plugins.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Attachment: Disable main-thread paint-skipping on pages with scroll-linked effects [functionally backed out in comment 12]

Yeah this does the job

Comment 4

[Markus Stange [:mstange]]

I guess we could turn the scroll-offset-update message into a layer transaction message. So if we don't have a paint, we'll send an empty transaction with just that scroll-offset-update message, and it will be sent in the stage of the refresh tick that matches existing behavior.

Comment 5

[Markus Stange [:mstange]]

Comment on attachment 8731741 [details] [diff] [review]
Disable main-thread paint-skipping on pages with scroll-linked effects [functionally backed out in comment 12]

Review of attachment 8731741 [details] [diff] [review]:
-----------------------------------------------------------------

But this is a fine short term workaround.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

(In reply to Markus Stange [:mstange] from comment #4)
> I guess we could turn the scroll-offset-update message into a layer
> transaction message. So if we don't have a paint, we'll send an empty
> transaction with just that scroll-offset-update message, and it will be sent
> in the stage of the refresh tick that matches existing behavior.

Yeah that seems like it would be better. I'll need to properly understand how empty transactions work in order to implement that. Will file a follow-up for it, and land this for now.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Filed bug 1257641 for it.

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/59a1ca7d784c

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/59a1ca7d784c

Comment 10

[arni2033]

Fixed on:   Win7_64, Nightly 48, 32bit, ID 20160319030558

(there was a typo in AR in comment 0: "...twitches A LOT")

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Now that bug 1257641 is landed and seems to be behaving well, I'm going to back this out and dupe this bug to that one, since that is the proper fix for this issue, as mentioned in comment 4.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc424788afd8

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/cc424788afd8