Composite drawing issue with animated CSS transforms

[SylvainGarrigues]

Hello,

I am using a RPI3 with latest buildroot. When trying to load the following page:
https://www.sylvaingarrigues.com/CladBox/index.html

the animation is very smooth (I am using simple 2D translatations) but only a part of the div which has the css transform property is animated. The full div appears only when the animation is done. Sometimes it's a square part of the div, sometimes a rectangle...

The issue is maybe best explained in the movie I made of the webkit browser on my TV connected to the RPI3:
https://www.sylvaingarrigues.com/tv.mp4

This is how it appears on my Mac:
https://www.sylvaingarrigues.com/mac.mp4

[SylvainGarrigues]

Is that a webkit bug or a backend bug? I have the dispmanx default rpi backend, shall I try with the VC4 Westeros backend? Any direction appreciated.

[magomez]

It's an already known webkit bug. It's on the process of being fixed upstream, but the fix belongs to a bigger refactor and it will take a while. In the meanwhile, it you're in a hurry to make it work properly, you can use the patch I paste below, but bear in mind that the performance using that patch will be worse.

diff --git a/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp b/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp
index a05733367a5..c82fe62a5cd 100644
--- a/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp
+++ b/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp
@@ -73,6 +73,7 @@ void CoordinatedGraphicsLayer::didChangeLayerState()
 void CoordinatedGraphicsLayer::didChangeAnimations()
 {
     m_shouldSyncAnimations = true;
+    setNeedsDisplay();
     notifyFlushRequired();
 }
 
@@ -1013,7 +1014,10 @@ void CoordinatedGraphicsLayer::updateContentBuffers()
 
     if (m_pendingVisibleRectAdjustment) {
         m_pendingVisibleRectAdjustment = false;
-        m_mainBackingStore->createTilesIfNeeded(transformedVisibleRect(), IntRect(0, 0, size().width(), size().height()));
+        if (selfOrAncestorHasActiveTransformAnimation())
+            m_mainBackingStore->createTilesIfNeeded(IntRect(0, 0, size().width(), size().height()), IntRect(0, 0, size().width(), size().height()));
+        else
+            m_mainBackingStore->createTilesIfNeeded(transformedVisibleRect(), IntRect(0, 0, size().width(), size().height()));
     }
 
     m_mainBackingStore->updateTileBuffers();

[SylvainGarrigues]

Thanks Miguel for your prompt feedback! Any reference to the upstream webkit bug so that I can track and follow it? Is that https://bugs.webkit.org/show_bug.cgi?id=181757?

[SylvainGarrigues]

Also, do you believe I can rearrange the HTML code to fix this bug by using a different HTML layout which may not trigger these webkit artifacts? Is there any specific combination that trigger it, like an <img> inside a <div>, etc. I simply want to slide an image over another one...

[SylvainGarrigues]

@magomez The patch you added in the webkit bug fixed my issue. The animation is smooth except when it start to ease-out. Here is the video:
https://www.sylvaingarrigues.com/tv-patched.mp4

[SylvainGarrigues]

@magomez Can you provide me with the link to the "bigger refactor in webkit" discussion or patch so that I can follow its progress? As the patch you propose introduce some performance penalty, I am looking forward to it.

Also you mention this bug happens "when animating a layer that has a backingStore and an animation that causes the visible rect of the backingStore to change": is there a way for me to rearrange the HTML layout structure so as not to fall in this case?

[magomez]

The refactor is handled in https://bugs.webkit.org/show_bug.cgi?id=187385

There's no way to avoid it currently, no matter how you rearrange your code. The problems happens because you're moving an element from out of the visible rect into the visible rect. As the element it initially invisible, it's not really rendered (if it's partially visible then only the visible part is rendered). When the element is moved into the visible area, the part that becomes visible should be rendered, but that's not happening until the animation is over.

What my patch does is forcing the element to be fully rendered, even if it's not visible, when an animation is added to it, assuming that the animation will cause an invisible part of the element to become visible. But that's why it has a performance problem, as maybe not the whole element needs to be rendered. BTW, for the example you're doing, where the the whole element ends being completely visible, there's no performance penalty.

[SylvainGarrigues]

Thanks @magomez. I was thinking there was a penalty due to the patch because the animation becomes jerky in the last ease-out part, and I don't know why :( Maybe the RPI3 GPU/CPU is not powerful enough?

[albertd]

Closing issue for now, new graphics port is ongoing.

[woutervanh]

Closing issue for now, new graphics port is ongoing.

Is there an issue to track this ongoing graphics port?

[SylvainGarrigues]

@albertd can you please point at where this new graphic port resides so that I can follow commits and progress?