949561 - The VariablesView and SideMenuWidget should use hardware acceleration when possible

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Comment 1

[Victor Porof [:vporof][:vp]]

Attachment: dbg-widgets-no-jank.patch

Activates turbo mode :)

This makes the variables view buttery smooth when scrolling, around 3-4x faster than what it used to be on my machine, when the window scope is expanded.

The sources list in the browser debugger is also buttery smooth.

Nick, if it works, maybe you should try using it for the FastList widget as well, if scrolling is janky.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Comment on attachment 8346663 [details] [diff] [review]
dbg-widgets-no-jank.patch

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

::: browser/themes/linux/devtools/widgets.css
@@ +437,5 @@
>  
>  /* VariablesView */
>  
> +.variables-view-container:not([empty]) {
> +  /* Hack: force hardware acceleration */

Nitttttttttttttttt: Typically we use XXX for comments explaining hacks.

@@ +438,5 @@
>  /* VariablesView */
>  
> +.variables-view-container:not([empty]) {
> +  /* Hack: force hardware acceleration */
> +  transform: translateX(1px);

Why 1px here and 0px above?

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Maybe someday we'll have something like "will-animate" (bug 940842) in chrome at least...

Comment 4

[Victor Porof [:vporof][:vp]]

(In reply to J. Ryan Stinnett [:jryans] from comment #3)
> Maybe someday we'll have something like "will-animate" (bug 940842) in
> chrome at least...

That would be much better!

Comment 5

[Victor Porof [:vporof][:vp]]

https://hg.mozilla.org/integration/fx-team/rev/76105555b203

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/76105555b203

Comment 7

[Benoit Girard (:BenWa)]

Typically on the desktop browser for simple content there's a slight delay in activing the layer (read ~5ms) but after that it should be smooth. If that's not the case then having a reduced test case is useful so we can have the browser layerize it properly is best. Hints should be our last solution.

Comment 8

[Alfred Kayser]

Can someone explain the use of transform: translateX(1px) here? 
The discussion will-animate and corr. bugs is about translateZ.
And by the way on my machine I don't detect any performance differences between these all.
Why will translateX(0) also do the trick?

Comment 9

[Victor Porof [:vporof][:vp]]

(In reply to Alfred Kayser from comment #8)
> Can someone explain the use of transform: translateX(1px) here? 
> The discussion will-animate and corr. bugs is about translateZ.
> And by the way on my machine I don't detect any performance differences
> between these all.
> Why will translateX(0) also do the trick?

A translate of any kind speeds up scrolling performance considerably in the Debugger (at least on my machine).

We ended up with translateX(0px) and translateX(1px) instead of translateZ(1px) to reduce artifacts, like having a 1px white line on the edges of the container.

Using any apparently benign transform, like translateX(0px) or even scale(1, 1), would make the container not line up exactly as before.

(In reply to Benoit Girard (:BenWa) from comment #7)
> Typically on the desktop browser for simple content there's a slight delay
> in activing the layer (read ~5ms) but after that it should be smooth. If
> that's not the case then having a reduced test case is useful so we can have
> the browser layerize it properly is best. Hints should be our last solution.

That depends on how you define simple content :)

The VariablesView typically contains a lot of text, icons, different backgrounds and borders. Removing all the styling didn't seem to do a whole lot of difference.