So I’ve implemented mouse support. It also turned out to be really easy to fix text rendering. So, what’s next? Well, some websites like https://discuss.haiku-os.org cause WebKit to crash. This crash also seems to affect other websites. Really, it seems to occur anytime WebKit decides to use multiple bitmaps (actually, in WebKit lingo, backing stores) to render a web page. Rendering a single bitmap is easy, just display it! But when you have multiple, you need to composite them together. It seems like WebKit currently requires EGL and maybe OpenGL to do this.
This is conjecture on my part, but when I saw in another thread this morning that you said it was compositing related and only happens on certain sites (like this one) I did wonder if it’s when transform is used in CSS. It definitely used to be true that use of transform would force browsers to use hardware rendering in some circumstances, seems like that would line up with the creation of a new surface and then the bail you’re seeing.
Given it’s likely to be the lightest of OpenGL usage (i.e. not going into shaders etc.) hopefully option 3 works out. The “hack” for option 1 might be to try and filter out any transform CSS rules and see if the issue still occurs?
Waddlesplash pointed out that WebKitGTK’s MiniBrowser can render discuss.haiku-os.org, and it wouldn’t be able to use EGL either. So I think there’s a cleaner, more official way of doing what I did.
Yes, that’s one reason. Here’s some more:
Layer has 3D or perspective transform CSS properties
Layer is used by <video> element using accelerated video
decoding
Layer is used by a <canvas> element with a 3D context or
accelerated 2D context
Layer is used for a composited plugin
Layer uses a CSS animation for its opacity or uses an animated webkit transform
Layer uses accelerated CSS filters
Layer has a descendant that is a compositing layer
Layer has a sibling with a lower z-index which has a compositing layer
(in other words the layer overlaps a composited layer and should be rendered
on top of it)
Now I got it working in a way similar to what WebKitGTK does. It’s no longer hacky. This method has better performance than the other method. IIRC, the old method rendered discuss.haiku-os.org around 2 fps. Now it’s around 15 fps. For reference, WebPositive renders it around 30 fps.
One thing remains to do. There’s an assert that I had to comment out. This seems to come from a bug in WebKit which probably is fixed by now. Maybe I can find the commit that fixes it, or else revert the commit causing it.