webkit: elements disappear when scrolling page

[humdinger]

This is hrev55476, 64bit, HaikuWebKit 1.8.2

If you go to ​https://download.haiku-os.org/ there are two folder icons, the first an SVG, the second a PNG. Now, click on the vertical scroll bar arrow down (or use the scroll wheel of your mouse, one noth at a time:

• first click: leaf and shadow disappear
• second click: the folder disappears completely

The PNG is not affected.

[nephele]

Excelent test case: ​https://pytouhou.linkmauve.fr/ , the images are SVG here aswell

[thebuck]

To summarize the testpage.zip (see attachment in #17397) behaviour:
An element of a SVG in an img-tag on a page is visible exactly when its bounding box intersects with (both two / the intersection of two) seemingly independent rectangles:

1. the unscrolled (initial) page viewport (attached fix to the page)
   
2. the img-box, offsetted relative to the page by page scroll, i.e. offsetted relative to the viewport by doubled page scroll
   

How the rectangles should behave:

1. move relative to the page as you scroll, i.e. be the viewport.
   
2. be constant offsetted to the page by its position only, i.e. be the img-box.

[nephele]

Yes, This is an issue similar to the button rendering stuff. For that I do have a fix (waiting on the haiku patch for controllooks first).

Buut, for this issue i have no idea where webkit deals with SVG in the haiku port at all. That is, i can't really find the code which is related.

Maybe someone has a pointer for me?

[thebuck]

@nephele Play around with <style>*{opacity:.99}</style> on somewhat complex pages, it produces the same behaviour with HTML elements. I'm trying to isolate a testcase.

Meanwhile, there is ?another? clipping/bounding box problem in #12511 with transformations and "layers".

[thebuck]

HTML triggering the same behaviour (but really clipping), with nested opacity<1 elements, unless the outer has a background (enable that to fix the issue)

[pulkomandy]

There is nothing specific in the Haiku port for SVG. All the cooe is cross platform and eventually uses GraphicsContextHaiku.cpp to do the drawing (just like html and everything else that can be drawn by webkit)

[nephele]

thebuck: did you have luck isolating a testcase?

[thebuck]

The testcase attachment is named 'opacity-scroll.html'. It only proves that your updated bug title is appropriate (not SVG-specific). Most likely location of the bug is in /haikuwebkit/Source/WebCore/platform/graphics/haiku/GraphicsContextHaiku.cpp or in that folder or its parent. Because WebKit itself is not that buggy and the app_server does not decide that much about clipping and rather not about optimizing away (presumably) off-view elements, I think.

[madmax]

For the SVG cases the problem is in GraphicsContextHaiku::clipBounds(). In converting the clipping region to drawing space it doesn't take into account that BView::Transform() returns the transform for the current state, not the compound transform with the stacked ones. Keeping a stack of compound transforms in GraphicsContextHaiku::save()/restore() and using it in clipBounds seems to work. It doesn't solve the opacity-scroll test, though, but that may be due to the opacity and more for #17665.

[nephele]

Keeping a stack of compound transforms in GraphicsContextHaiku::save()/restore() and using it in clipBounds seems to work.

Hey madmax, do you have a patch for this? maybe a WIP one?

Other than that I have now put my contributions on the haikuwebkit github repo in the pr thing aswell, since you also have experience with haikuwebkit I would be happy if you can review some patches occasionally aswell if you have time.

[madmax]

Replying to nephele:

Keeping a stack of compound transforms in GraphicsContextHaiku::save()/restore() and using it in clipBounds seems to work.

Hey madmax, do you have a patch for this? maybe a WIP one?

I used ​this for testing, but:

• My first time with that stuff, I just wanted something that looked like a stack for a proof of concept and didn't bother to read the documentation and check the objects lifetime and ownership, so there may be leaks, dangling pointers and whatnot.
• The combined transform may be also needed in other places, like set/getCTM.
• It is possible that it gets out of sync: if the view passed to the graphics context already has stacked states, if clipBounds is called between other internal operations that push states...
• I think The Right Way would be for BView to provide the combined transform instead of the apps having to track it. I had a look when I played with this and I think that needs an API addition (which I may do), so no webkit patch to use it merged until after beta4.

[madmax]

The SVG cases should work after ​d75a84f4. Shall we move the opacity ones to #17665?

[humdinger]

Appears to be fixed with hrev56578+31, 64bit - HaikuWebKit 1.9.0 - WebKit 615.1.10
Close as fixed?