1612922 - Paint flashing DevTools for WebRender

Status: NEW

(DevTools :: General, enhancement, P3)

Description

[:Harald Kirschner :digitarald]

Paint layers are not a concept in WebRender, so paint flashing is not working.

Collected from the #gfx channel I would propose that paint flashing enabled 2 prefs that are useful for debugging but in different ways:

1. Picture caching: webrender.debug.picture-caching
   Shows which regions were invalidated, though slightly differently to paint flashing.

2. Blob paint flashing: gfx.webrender.blob.paint-flashing
   The fallback path we use for content WebRender can't render, so we use gecko to paint it.

These would be different from paint flashing as layers are something devs optimize for; but rather "slow paint regions". This means we should probably rename the tool when WebRender is on, so devs don't get wrong impressions – or we add some in-tool help to explain the concepts and how to use this information.

Another trade-off to consider is that DevTools' paint flashing could be limited to content; while WebRender prefs might be parent/content-agnostic.

Comment 1

[Markus Stange [:mstange]]

The blob paint flashing pref is probably easy to make tab-local. But the picture cache paint flashing would require a fair amount of work if we want to make it only apply to tab contents and look presentable.

Comment 2

[Alexandre Poirot [:ochameau]]

Oh, so DevTools paint flashing feature is becoming a no-op now that WebRender get enabled.

DevTools is having a "Toggle paint flashing" option, which show a little paint flashing button on the toolbox's header.
This button ultimately toggles nsIDOMWindowUtils.paintFlashing boolean.

There is also nglayout.debug.paint_flashing preference which some may still use?

Both are no longer doing anything anytime WebRender is enabled. (You might still only see paintflashing in browser chrome UI).

It sounds like we should either:

• grey out devtools button with helpful tooltip when webrender is enabled
• remove this feature entirely
• implement something else.

The current state is confusing.

(You immediately get paint flashing working back by toggling gfx.webrender.force-disabled to true)

Comment 3

[Nicolas Frandeboeuf]

Hi,

Regarding:

”These would be different from paint flashing as layers are something devs optimize for; but rather "slow paint regions". This means we should probably rename the tool when WebRender is on, so devs don't get wrong impressions – or we add some in-tool help to explain the concepts and how to use this information.”

I find this tool particularly useful in Chrome to detect things that are updated in the DOM: I have an app that updates the DOM constantly based on values received through websockets. This is mostly updating table cells. However I might sometimes receive new values that should not trigger DOM updates (as the value displayed remains the same). This tool becomes really useful to detect DOM nodes that are repainted where as they should not have been (ie. I did a bad job at detecting whether a DOM update is needed or not).

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

Since there are some work happening to remove the paint flashing feature in Bug 1743310, we should investigate in a proper, WebRender-compatible replacement for it. That's a (useful) feature Chrome does have and we shouldn't lag for too long.
Maybe former DevToolers could help here? Jim, Brad, would you know if/how we could implement such thing with WebRender, or know someone that would know? Thanks!
Asking Emilio as well since he's the one working on Bug 1743310 :)

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I'm not familiar enough with WR to know if paint flashing is implementable in webrender. My (possibly outdated) understanding of WR is that it divides the screen into tiles and then it repaints those when dirty. So we might be able to flash the tiles themselves, but that'd be a bit weird...

Nical probably has a more up-to-date model of how this works?

Comment 6

[Brad Werth [:bradwerth] | Out until July 8]

Will discuss in our triage meeting.

Comment 7

[Glenn Watson [:gw]]

We're thinking we should have an option to enable the picture cache debugging overlay at the per-tab level. We could have Gecko supply which pipeline(s) to enable this on, which could be controllable by devtools.

Comment 8

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Glenn Watson [:gw] from comment #7)

We're thinking we should have an option to enable the picture cache debugging overlay at the per-tab level. We could have Gecko supply which pipeline(s) to enable this on, which could be controllable by devtools.

Do you have any update on this Glenn?

Comment 9

[Glenn Watson [:gw]]

Not yet - this might be a good task for ahale to look at though. The work inside WR is minimal, the bulk of the work would be updating the WR debug APIs to allow specifying values in addition to flags, and possibly hooking up the gecko side (though that bit might be best left to someone who knows the devtools code well).