1877153 - Canvas flicker on the profiler UI when a scrollbar appears in the timeline

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Florian Quèze [:florian]]

Here is a profile where the screenshot track shows the problem pretty well: https://share.firefox.dev/3vVRlaE

Steps to reproduce:

1. Load a profile with few enough visible tracks that there's no vertical scrollbar on the timeline (eg. https://share.firefox.dev/49ebxD4). Ensure the last visible track is a memory track where the chart touches the bottom.
2. Mouse the mouse around into and out of the area where the memory graph touches the bottom of the track.

Expected result:
When the mouse hovers a sample of the memory track that touches the bottom of the chart, a dot appears, and that makes the vertical scrollbar of the timeline appear. The dot and the (animated) scrollbar are the only things moving on screen.

Actual result:
All the canvas on the page become white for a split second.

The profile I was looking at when I noticed the bug is pretty large, and requires a large screen to see the bug, but a reduced version of it shows the bug too, even on the macbook's internal screen.

Comment 1

[Florian Quèze [:florian]]

mozregression said https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=dd2a416c0c76b4cc9f6161d6be89aa7356e4eae5&tochange=5da1e842ef70c74d8ed72128e460f75b633fae95 -> bug 1839425

A local backout of https://hg.mozilla.org/mozilla-central/rev/5da1e842ef70 fixes the bug locally for me.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1839425

:bradwerth, since you are the author of the regressor, bug 1839425, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Brad Werth [:bradwerth] | Out until Feb 2025]

That's wild. I'm trying to reproduce but I'm not successful at getting the same results as you. In my case, through some careful pointer work near the intersection of the memory graph and the horizontal splitter, I can sometimes get the memory graph to flicker, sometimes get the bottom half of the page (with the Marker Chart) to flicker, but never the whole page. I'm also not using the Profiler enough to know what's a "normal" level of Canvas flicker -- I guess none at all.

Anyway, Bug 1839425 is a surprising regression candidate for this issue because it should only affect the type of layer created to host video. Is there any video content used in the Profiler? That seems odd.

One way to confirm this regression would be to set the "gfx.core-animation.specialize-video" pref to false. Does that fix the issue for you? If so, then it's definitely Bug 1839425, somehow.

Comment 4

[Brad Werth [:bradwerth] | Out until Feb 2025]

I've confirmed that the Profiler is using video content. This is my Bug to fix. Wow!

Comment 5

[Markus Stange [:mstange]]

These things are canvases so they should be BGRA buffers, not YCbCr or NV12 or anything like that. So I would suspect canvas to not benefit from a video layer.

Comment 6

[Brad Werth [:bradwerth] | Out until Feb 2025]

Indeed all the horizontal graph images are processed by WebRender as external/native surfaces, passed to the macOS layers as TextureHost which NativeLayerCA treats as a video source. The change Bug 1839425 made was to always use a specialized video layer for video source. Florian, you probably would've see this issue before this regression if you were viewing the profiles in a fullscreen window, because the logic in NativeLayerCA was already using AVSampleBufferDisplayLayer for video in fullscreen windows.

Several solutions I can think of:

1. Make WebRender not elevate these surfaces given that they are static images that won't benefit from being made external/native to the GPU. This would likely improve our tiling outcomes -- less layers sent by WR.
2. Make WebRender reuse surfaces better in this situation. Nothing is changing size, just changing content, so why is the old surface being destroyed and a new one being created?
3. Make NativeLayerCA detect these weird sort of TextureHost layers that don't get regular updates and prevent them from getting treated as video. This would be some kind of heuristic and therefore fallible.
4. Make NativeLayerCA "warm up" the AVSampleBufferDisplayLayer with initial content so that there is no flicker when they are added to the screen.

Idea 4 is most within my abilities, and would be a fine solution, so that's what I'll try to accomplish.

Comment 7

[Brad Werth [:bradwerth] | Out until Feb 2025]

Glenn, what's the value in WebRender treating BGRA surfaces as external/native? Is this just something we have to do because we can't composite them properly with other layers?

Comment 8

[Markus Stange [:mstange]]

Non-external surfaces have to be copied into the texture cache. On macOS, our canvas surfaces are already backed by an IOSurface per canvas "frame" on macOS, so if we treat them as external / native we can put them on the screen without a copy.

(In reply to Brad Werth [:bradwerth] from comment #6)

3. Make NativeLayerCA detect these weird sort of TextureHost layers that don't get regular updates and prevent them from getting treated as video. This would be some kind of heuristic and therefore fallible.

I think this would be the right solution. Conceptually we have three types of layers: "tiled surface" layers (bound and painted by webrender during rendering), "external BGRA" layers (for canvas), and "video" layers.

4. Make NativeLayerCA "warm up" the AVSampleBufferDisplayLayer with initial content so that there is no flicker when they are added to the screen.

I wonder if we need to do something for video layers because there might still be a flickering problem with those.

Comment 9

[Brad Werth [:bradwerth] | Out until Feb 2025]

(In reply to Markus Stange [:mstange] from comment #8)

3. Make NativeLayerCA detect these weird sort of TextureHost layers that don't get regular updates and prevent them from getting treated as video. This would be some kind of heuristic and therefore fallible.

I think this would be the right solution. Conceptually we have three types of layers: "tiled surface" layers (bound and painted by webrender during rendering), "external BGRA" layers (for canvas), and "video" layers.

Great, then I will modify NativeLayerCA::IsVideoAndLocked and possibly NativeLayerCA::AttachExternalImage to check the format of external images and conclude that BGRA stuff is not video.

4. Make NativeLayerCA "warm up" the AVSampleBufferDisplayLayer with initial content so that there is no flicker when they are added to the screen.

I wonder if we need to do something for video layers because there might still be a flickering problem with those.

It would be nice if I could figure it out because it would forestall any future problem where we re-generate AVSampleBufferDisplayLayer in place. We don't want to do that, re-generating same-size surfaces is wasteful, but we don't want to have flickering when and if we do that.

Comment 10

[Markus Stange [:mstange]]

Easier steps to reproduce:

1. Load https://share.firefox.dev/49ebxD4
2. Press Cmd+Opt+K to open the Web Console.
3. Make sure the devtools are displayed in "dock to bottom" mode.
4. Focus the text box in the console so that you have a blinking cursor.

When the cursor flashes on and off, some canvases disappear or reappear. Profile with screenshots: https://share.firefox.dev/4bf2nHY

I find this a bit concerning because the invisible canvases remain invisible until the next composite, and not just until the WindowServer has caught up or something like that.

Comment 11

[Brad Werth [:bradwerth] | Out until Feb 2025]

Attachment: Bug 1877153: Make NativeLayerCA check the colorspace of TextureHost to determine if it is video.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ed526ee3de75
Make NativeLayerCA check the colorspace of TextureHost to determine if it is video. r=mstange

Comment 13

[Serban Stanca [:SerbanS]]

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

Comment 14

[Daniel Holbert [:dholbert]]

(In reply to Markus Stange [:mstange] from comment #10)

When the cursor flashes on and off, some canvases disappear or reappear.

This^ sort of canvas-disappearing-issue seems to have manifested during reftest test-runs as well -- see bug 1877305, which appears to have the same regression range per bug 1877305 comment 19.

Given the similarity, I'm hoping that it was fixed by the patch that landed here; I'm waiting on some treeherder backfill-tasks to confirm.

Comment 16

[Intermittent Failures Robot]

5 failures in 3952 pushes (0.001 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-central: 1
• autoland: 3
• try: 1

Platform and build breakdown:

• macosx1100-64-shippable-qr: 4
  • opt: 4
• linux1804-64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1877153&startday=2024-01-29&endday=2024-02-04&tree=all

Comment 17

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a9db5ebd04a7
Backed out changeset ed526ee3de75 as a follow-up to 1839425 for causing os build bustages. CLOSED TREE

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Backed out from Beta for 125.0b9 along with bug 1839425.
https://hg.mozilla.org/releases/mozilla-beta/rev/1704ba05b8d441100a2f8dbd172eb4c2f7e039ec

Comment 19

[Serban Stanca [:SerbanS]]

Backout merged in central: https://hg.mozilla.org/mozilla-central/rev/a9db5ebd04a7120c548cc79a07ffc1b470caae76.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e06d20ad693a
Make NativeLayerCA check the colorspace of TextureHost to determine if it is video. r=mstange

Comment 21

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 22

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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