Closed Bug 1460495 Opened 6 years ago Closed 6 years ago

Paints are delayed until the next paint, sometimes (when a canvas is on the screen?)


(Core :: Graphics: WebRender, defect, P1)




Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- unaffected
firefox62 --- fixed


(Reporter: mstange, Assigned: kats)




(Keywords: regression)


(1 file)

Steps to reproduce:
 1. Open and wait for it to load completely.
 2. Move your mouse over one of the tree rows.
 3. Make sure everything has settled and nothing in the browser is painting.
 4. Move your mouse over a different tree row.

Expected results:
The arrow button at the end of the hovered tree row should appear immediately.

Actual results:
It takes about half a second until the arrows shows up.

Similar things can be seen when pressing Ctrl+Shift+1 to start/stop the profiler: While is on the screen, and nothing else is causing paints, the button highlight doesn't update when the profiler state changes, or it updates to show the previous state that you just left, as if it was painting the previous paint.
It might be similar to Bug 1460432.
Yeah it sounds like bug 1460432. I'll look into it.
Assignee: nobody → bugmail
Depends on: 1460432
mozregression --good 6f52281bccaa9f7624ec5bfac9e85e41f1928547 --bad 7c83ceac4be6d055bebd870a82b78b76de14b9d7 --pref gfx.webrender.all:true startup.homepage_welcome_url:''
> 8:03.79 INFO: Last good revision: 9554a93583058c35d86878d398d7d4688a3eb86f
> 8:03.79 INFO: First bad revision: 25652d08b28edca783e238dcce7bbad52fc545e1
> 8:03.79 INFO: Pushlog:

> 25652d08b28e	Kartikaya Gupta — Bug 1459686 - Include async image updates in the displaylist transaction. r=sotaro
> b27eadf1b8de	Kartikaya Gupta — Bug 1459686 - Refactor to have the ApplyAsyncImages callsite provide the transaction. r=sotaro
> 4869243efd9c	ffxbld — Bug 1459686 - Remove WebRenderCommandBuilder::mParentCommands which is always empty. r=sotaro
Blocks: 1459686
Has Regression Range: --- → yes
Has STR: --- → yes
OS: Mac OS X → All
This is a result of the second patch from bug 1459686. In that patch, CompositeToTarget ends up sending a transaction and then reusing the TransactionBuilder. But the async-scene-build flag doesn't get set on the new transaction properly. i.e. when we create the TransactionBuilder for the first time, it correctly sets the flag based on [1]. But after sending the transaction the new transaction is created and swapped in at [2] without setting the flag.

The patches on bug 1457466 should actually fix this, but would leave this footgun-ny behaviour in place. So I'll fix it here.
I was able to repro this more easily than bug 1460432 so the STR on this bug are what I used to test. Inverting dependency relationship; I'll put the patch here and we can see if it fixes bug 1460432 as well.
Blocks: 1460432
No longer depends on: 1460432
Comment on attachment 8974799 [details]
Bug 1460495 - When sending a transaction, ensure the new transaction that takes its place has the same async-scene-build flag set.

Looks good.
Attachment #8974799 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by
When sending a transaction, ensure the new transaction that takes its place has the same async-scene-build flag set. r=sotaro
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in before you can comment on or make changes to this bug.