Bug 135840 – [gtk] Gaps between synchronised CSS-animated images at 50% Zoom

• Component: Animations
• Status: NEW

[Simon St James]

Created attachment 236446 [details]
Test-case

We at Samsung have run into some sub-pixel layout issues with the attached test-case; it shows a white border composed of 8 corner and edge pieces all animated in tandem with css transitions, and as it moves between the two red rectangles, there should be no visible "joins" or "seams" between the edge and corner pieces, but unfortunately there are - although this happens only at certain Zoom levels (notably: not at multiples of 100%).  50% Zoom usually shows the bug.

On upstream-GTK, there seem to be a few contributing factors:

1) In RenderLayerBacking, the computation of the "anchor" in updateGeometry is slightly off for most of the frames: I think it's supposed to always be (0,0,0) in this example, but usually ends up  fractionally different - and this "fraction" is blown up when the 9-patch pieces are laid out into about a pixel's worth of misalignment, leading to a visual gap between the pieces.  This seems to be due to different rounding being used between enclosingRelativeCompositingBounds() and layerOffset().
2) Again in updateGeometry, the m_graphicsLayer->setSize(contentsSize); eventually results in the 9-patch pieces being rendered with slightly incorrect sizes, again leading to a visible gap between the pieces: setting it to the size of compositingBounds() seems to be more correct for this test-case, but I'm sure it breaks others :)
3) The BitmapTextures that are are ultimately rendered by TextureMapperGL have their contents offset slightly, again leading to visible (but this time "gradiented") gaps between the pieces: see the attached picture, which shows a dump of one of the BitmapTextures with a gap at the left edge.

We are especially interested in #1, as we are using Coordinated Graphics and do not suffer from #3 there, though we have an analogue of #2 that is causing us some grief :) I'm betting #1 affects all platforms.

I've been using the attached patch to aid diagnosis: it dumps out the coordinates of the pieces that are rendered out; snaps  the zoom to 50% whenever it is manually changed; and also freezes the animation progress at 100% which makes the bug(s) slightly easier to analyse.

I think the general question that I'm getting stuck on is the  following: it is obviously useful & correct in the majority of cases to snap to pixels during layout, but this should not be done (ever?) when dealing with CSS transitions: how is  this conflict supposed to be handled by WebKit?

Zalan: I hope you don't mind me CC'ing you, but I'm keen to hear anything thoughts you have, especially on 1) and 2) :)

[Simon St James]

Created attachment 236447 [details]
Small set of diagnostic helpers for this issue

[Simon St James]

Created attachment 236448 [details]
BitmapTexture with contents incorrectly offset

[Simon Pena]

Martin: I suggested Simon St. James to CC you, in case you can make any comment from WebKitGTK point of view.