Bug 188840 – webkitgtk+ on ARM doesn't play hardware-accelerated CSS animations

• Status: NEW
• Component: Layout and Rendering

[Martin]

Created attachment 347785 [details]
Output of glxinfo

Hi,

I'm using WebKitGTK+ on a machine with an ARM CPU. Everything seems to work okay, except that CSS animations which use hardware acceleration (i.e with a 'transform: translateZ(0)' property) just don't run. If I disable hardware acceleration, either by removing translateZ, or by defining WEBKIT_DISABLE_COMPOSITING_MODE=1, the animation plays (albeit choppily). Canvas also doesn't work properly, again unless I disable hardware acceleration.

On my Intel laptop, animations run just fine with hardware acceleration.

The ARM machine uses WebKitGTK+ 2.20.3, compiled from the meta-webkit yocto layer (https://github.com/Igalia/meta-webkit). The hardware is a DART-SD410 from Variscite, running a Snapdragon 410. It's running Linux 4.9.39+linaro. It has a GPU which supports OpenGL, "3.0 Mesa 17.3.8" is the OpenGL version string. Here's the output from glxinfo: https://pastebin.com/mZEMe7Gx. Here's a test page which runs fine with webkitgtk on my Intel laptop, but not with webkitgtk on ARM: https://s.mort.coffee/hwaccel-css (source: https://pastebin.com/2KTALmYW)

Here's a line printed by bitbake when compiling the recipe which includes the build options:
+ cmake -G Ninja -DCMAKE_MAKE_PROGRAM=ninja /data/martin/yocto/build/tmp/work/aarch64-poky-linux/webkitgtk/2.20.3-r0/webkitgtk-2.20.3/ -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_BINDIR:PATH=bin -DCMAKE_INSTALL_SBINDIR:PATH=sbin -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/etc -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=../com -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=/var -DCMAKE_INSTALL_LIBDIR:PATH=lib -DCMAKE_INSTALL_INCLUDEDIR:PATH=include -DCMAKE_INSTALL_DATAROOTDIR:PATH=share -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_TOOLCHAIN_FILE=/data/martin/yocto/build/tmp/work/aarch64-poky-linux/webkitgtk/2.20.3-r0/toolchain.cmake -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 -DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DENABLE_INTROSPECTION=OFF -DENABLE_GTKDOC=OFF -DENABLE_CREDENTIAL_STORAGE=OFF -DENABLE_MINIBROWSER=ON -DENABLE_DRAG_SUPPORT=OFF -DUSE_REDIRECTED_XCOMPOSITE_WINDOW=OFF -DENABLE_SPELLCHECK=OFF -DENABLE_GEOLOCATION=OFF -DENABLE_GLES2=ON -DUSE_GSTREAMER_GL=ON -DENABLE_PLUGIN_PROCESS_GTK2=OFF -DUSE_LIBHYPHEN=OFF -DUSE_LIBNOTIFY=OFF -DUSE_LIBSECRET=OFF -DENABLE_OPENGL=ON -DENABLE_VIDEO=ON -DENABLE_WAYLAND_TARGET=ON -DENABLE_WEB_CRYPTO=ON -DENABLE_WEBGL=ON -DUSE_WOFF2=ON -DENABLE_X11_TARGET=ON -DUSE_LD_GOLD=OFF -Wno-dev

[Carlos Bentzen]

I can reproduce this on the Raspberry Pi 3 as well.

I tested with:
- core-image-sato (X11)
- WebKitGTK+ 2.20.3
- Mesa VC4

Setting WEBKIT_DISABLE_COMPOSITING_MODE=1 made the animation work here too.

[Carlos Bentzen]

(In reply to Carlos Eduardo Ramalho from comment #1)
> I can reproduce this on the Raspberry Pi 3 as well.
> 
> I tested with:
> - core-image-sato (X11)
> - WebKitGTK+ 2.20.3
> - Mesa VC4
> 
> Setting WEBKIT_DISABLE_COMPOSITING_MODE=1 made the animation work here too.

Running with core-image-weston, on the other hand, I hit another case:

WARNING **: GDK is not able to create a GL context, falling back to glReadPixels (slow!): Unable to create a GL context.

Then the animation runs, but pretty slowly, to the point that with WEBKIT_DISABLE_COMPOSITING_MODE=1 it is faster.

Running with Mesa VC4 as well.

[Miguel Gomez]

Carlos, is this reproducible with WPE as well?

[Carlos Bentzen]

(In reply to Miguel Gomez from comment #3)
> Carlos, is this reproducible with WPE as well?

I've had some trouble with building a WPE image using wpebackend-fdo for RPi. I'm building with dispmanx now. As soon as I have the results for using the userland stack and open-source stack I'll post it here.

[Carlos Bentzen]

(In reply to Miguel Gomez from comment #3)
> Carlos, is this reproducible with WPE as well?

Could not reproduce it with WPE.

Tested with:

1) WPE 2.22.0 + wpebackend-fdo + vc4 + yocto master

2) WPE 2.20.2 + wpebackend-rdk + dispmanx + yocto rocko

[Carlos Bentzen]

Comparing log of "compositing" channel when the animation in running on https://s.mort.coffee/hwaccel-css.

- Repeating log on ARM (RPi3):

RenderLayerCompositor 0x70a88a00 updateCompositingLayers after style change root (nil)
 checkForHierarchyUpdate 1, needGeometryUpdate 0
 
- Repeating log on X86_64 Intel:

RenderLayerCompositor 0x7fee69d6b178 updateCompositingLayers after style change root (nil)

(S)tacking Context, (N)ormal flow only, (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, (C)omposited
Dirty (z)-lists, Dirty (n)ormal flow lists
Descendant needs overlap (t)raversal, Descendant needs (b)acking or hierarchy update, All descendants need (r)equirements traversal, All (s)ubsequent layers need requirements traversal, All descendants need (h)ierarchy traversal
Needs compositing paint order update on (s)ubsequent layers, Needs compositing paint (o)rder children update, Needs post-(l)ayout update, Needs compositing (g)eometry update, (k)ids need geometry update, Needs compositing (c)onfig update, Needs compositing layer conne(x)ion update
S--------C -- tb--- ------ 0x7fee69da4500 (0,0) width=800 height=564
S--------- -- tb--- ------   + 0x7fee69da4a00 (0,0) width=800 height=35
S-----T--C -- ----- -lg---     + 0x7fee69da4b40 (400,8) width=392 height=19


Update 138 of main frame - compositing policy is normal
0x7fee69da4500 computeCompositingRequirements
0x7fee69da4a00 computeCompositingRequirements
  0x7fee69da4b40 computeCompositingRequirements
  0x7fee69da4b40 computeCompositingRequirements - willBeComposited 1
0x7fee69da4a00 computeCompositingRequirements - willBeComposited 0
0x7fee69da4500 computeCompositingRequirements - willBeComposited 1

RenderLayerCompositor::updateCompositingLayers - mid

(S)tacking Context, (N)ormal flow only, (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, (C)omposited
Dirty (z)-lists, Dirty (n)ormal flow lists
Descendant needs overlap (t)raversal, Descendant needs (b)acking or hierarchy update, All descendants need (r)equirements traversal, All (s)ubsequent layers need requirements traversal, All descendants need (h)ierarchy traversal
Needs compositing paint order update on (s)ubsequent layers, Needs compositing paint (o)rder children update, Needs post-(l)ayout update, Needs compositing (g)eometry update, (k)ids need geometry update, Needs compositing (c)onfig update, Needs compositing layer conne(x)ion update
S--------C -- -b--- ------ 0x7fee69da4500 (0,0) width=800 height=564
S--------- -- -b--- ------   + 0x7fee69da4a00 (0,0) width=800 height=35
S-----T--C -- ----- --g---     + 0x7fee69da4b40 (400,8) width=392 height=19

0x7fee69da4500 id 10 (0.000,0.000-800.000,564.000) 1762.50KB (root) [opaque] RenderView - updateBackingAndHierarchy
  0x7fee69da4b40 id 8 (400.000,8.000-792.000,27.000) 29.09KB z-index: 0 (3D transform)  <div> id='a' - updateBackingAndHierarchy
Total layers   primary   secondary   obligatory backing (KB)   secondary backing(KB)   total backing (KB)  update time (ms)
       2           2         0              1791.59                   0.00                1791.59               0.29
RenderLayerCompositor::updateCompositingLayers - post

(S)tacking Context, (N)ormal flow only, (O)verflow clip, (A)lpha (opacity or mask), has (B)lend mode, (I)solates blending, (T)ransform-ish, (F)ilter, Fi(X)ed position, (C)omposited
Dirty (z)-lists, Dirty (n)ormal flow lists
Descendant needs overlap (t)raversal, Descendant needs (b)acking or hierarchy update, All descendants need (r)equirements traversal, All (s)ubsequent layers need requirements traversal, All descendants need (h)ierarchy traversal
Needs compositing paint order update on (s)ubsequent layers, Needs compositing paint (o)rder children update, Needs post-(l)ayout update, Needs compositing (g)eometry update, (k)ids need geometry update, Needs compositing (c)onfig update, Needs compositing layer conne(x)ion update
S--------C -- ----- ------ 0x7fee69da4500 (0,0) width=800 height=564
S--------- -- ----- ------   + 0x7fee69da4a00 (0,0) width=800 height=35
S-----T--C -- ----- ------     + 0x7fee69da4b40 (400,8) width=392 height=19

RenderLayerCompositor::updateCompositingLayers - GraphicsLayers post
(GraphicsLayer 0x7fee69d05780 "content root"
  (anchor 0.00 0.00)
  (bounds 800.00 564.00)
  (primary-layer-id 2)
  (client 0x7fee69d6b178)
  (backingStoreAttached 1)
  (paintingPhases
    GraphicsLayerPaintBackground
    GraphicsLayerPaintForeground
    )
  (children 2RenderLayerCompositor 0x70a88a00 updateCompositingLayers after style change root (nil)
 checkForHierarchyUpdate 1, needGeometryUpdate 0

    (GraphicsLayer 0x7fedffdf7780 "RenderView"
      (bounds 800.00 564.00)
      (contentsOpaque 1)
      (primary-layer-id 10)
      (client 0x7fee69dca9a0)
      (backingStoreAttached 1)
      (paintingPhases
        GraphicsLayerPaintBackground
        GraphicsLayerPaintForeground
        )
      (children 1
        (GraphicsLayer 0x7fedffdf9780 " <div> id='a'"
          (position 400.00 8.00)
          (bounds 392.00 19.00)
          (drawsContent 1)
          (primary-layer-id 8)
          (client 0x7fee69dca840)
          (backingStoreAttached 1)
          (paintingPhases
            GraphicsLayerPaintBackground
            GraphicsLayerPaintForeground
            )
        )
      )
    )
    (GraphicsLayer 0x7fedffdfb780 "Document overlay Container"
      (primary-layer-id 6)
      (client 0x7fee69d93c80)
      (backingStoreAttached 1)
      (paintingPhases
        GraphicsLayerPaintBackground
        GraphicsLayerPaintForeground
        )
    )
  )
)

[Carlos Bentzen]

Created attachment 355333 [details]
Layers

Running the MiniBrowser with "--draw-compositing-indicators=true" looks like the layers are created correctly on the RPi3 too though. It looks the same as in the desktop. The layers just don't move.