[GSoC 2024] Can I get discuss.haiku-os.org to work? | Haiku Project

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 a companion discussion topic for the original entry at https://www.haiku-os.org/blog/zardshard/2024-08-13_gsoc_2024_can_i_get_discusshaiku-osorg_to_work
9 Likes

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?

So, option 1 works, and it’s not too hacky.

Show me the diff!

Alright, here you go :slight_smile:

diff --git a/Source/WebCore/dom/Document.cpp b/Source/WebCore/dom/Document.cpp
index b96b4210cc..e724709480 100644
--- a/Source/WebCore/dom/Document.cpp
+++ b/Source/WebCore/dom/Document.cpp
@@ -1149,7 +1149,9 @@ public:
 
 RefPtr<NodeList> Document::resultForSelectorAll(ContainerNode& context, const S
tring& selectorString)
 {
-    ASSERT(context.hasValidQuerySelectorAllResults() == m_querySelectorAllResults.contains(context));
+    //ASSERT(context.hasValidQuerySelectorAllResults() == m_querySelectorAllResults.contains(context));
     if (!context.hasValidQuerySelectorAllResults())
         return nullptr;
     auto* results = m_querySelectorAllResults.get(context);
 
diff --git a/Source/WebCore/rendering/RenderLayerCompositor.cpp b/Source/WebCore/
rendering/RenderLayerCompositor.cpp
index 4c3098a169..7804af9690 100644
--- a/Source/WebCore/rendering/RenderLayerCompositor.cpp
+++ b/Source/WebCore/rendering/RenderLayerCompositor.cpp
@@ -46,6 +46,7 @@
 #include "LocalFrameView.h"
 #include "Logging.h"
 #include "NodeList.h"
+#include "NotImplemented.h"
 #include "OffsetRotation.h"
 #include "Page.h"
 #include "PageOverlayController.h"
@@ -2058,6 +2059,16 @@ bool RenderLayerCompositor::updateBacking(RenderLayer& layer, RequiresCompositin
         requiresCompositingForPosition(rendererForCompositingTests(layer), layer, queryData);
     }
 
+#if PLATFORM(HAIKU)
+    if (backingRequired == BackingRequired::Yes) {
+        notImplemented();
+        backingRequired = BackingRequired::No;
+    }
+#endif
+
     auto repaintTargetsSharedBacking = [&](RenderLayer& layer) {
         return backingSharingState && layerRepaintTargetsBackingSharingLayer(layer, *backingSharingState);
     };

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)

(source)

6 Likes

This is related to this ticket:

https://review.haiku-os.org/c/haiku/+/8011

Great work! :smiley:

Maybe this is a bit naive, but shouldn’t this bypassed, when you turn it off during configuration?

I just had a quick look at the recipe and the patch of WebkitGTK. I’m not an expert, but it looks like they just activated OpenGL?

Definetely not


 static const char* hardwareAccelerationPolicy(WebKitURISchemeRequest* request)
 {
 #if PLATFORM(WPE)
     return "always";
+#elif defined(__HAIKU__)
+	return "never";
 #elif PLATFORM(GTK)
     auto* webView = webkit_uri_scheme_request_get_web_view(request);
     ASSERT(webView);
@@ -155,6 +157,8 @@ static const char* openGLAPI(bool isEGL)
     if (epoxy_is_desktop_gl())
         return "OpenGL (libepoxy)";
     return "OpenGL ES 2 (libepoxy)";
+#elif defined(__HAIKU__)
+	return "OpenGL";
 #else

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.

Show me the diff!
diff --git a/Source/WebKit/UIProcess/API/haiku/WebView.cpp b/Source/WebKit/UIProcess/API/haiku/WebView.cpp
index 1a6ba8a88c..370e38704d 100644
--- a/Source/WebKit/UIProcess/API/haiku/WebView.cpp
+++ b/Source/WebKit/UIProcess/API/haiku/WebView.cpp
@@ -55,6 +55,7 @@ BWebView::BWebView(BRect frame, BWindow* myWindow)
 
     RefPtr<WebPreferences> prefs = WebPreferences::create(String(), "WebKit2."_s, "WebKit2."_s);
     prefs->setDeveloperExtrasEnabled(true);
+    prefs->setAcceleratedCompositingEnabled(false);
     config->setPreferences(WTFMove(prefs));
 
     RefPtr<API::ProcessPoolConfiguration> apiConfiguration = API::ProcessPoolConfiguration::create();
diff --git a/Source/WebKit/UIProcess/API/haiku/WebViewBase.cpp b/Source/WebKit/UIProcess/API/haiku/WebViewBase.cpp
index 68a9519988..434ec2a8dd 100644
--- a/Source/WebKit/UIProcess/API/haiku/WebViewBase.cpp
+++ b/Source/WebKit/UIProcess/API/haiku/WebViewBase.cpp
@@ -52,7 +52,6 @@ WebViewBase::WebViewBase(const char* name, BRect rect, BWindow* parentWindow,
 {
     auto config = pageConfig.copy();
-    auto preferences = config->preferences();
-    preferences.setAcceleratedCompositingEnabled(false);
 
     WebProcessPool& processPool = config->processPool();
     fPage = processPool.createWebPage(*fPageClient, WTFMove(config));
diff --git a/Source/WebCore/dom/Document.cpp b/Source/WebCore/dom/Document.cpp
index b96b4210cc..e724709480 100644
--- a/Source/WebCore/dom/Document.cpp
+++ b/Source/WebCore/dom/Document.cpp
@@ -1149,7 +1149,9 @@ public:
 
 RefPtr<NodeList> Document::resultForSelectorAll(ContainerNode& context, const S
tring& selectorString)
 {
-    ASSERT(context.hasValidQuerySelectorAllResults() == m_querySelectorAllResults.contains(context));
+    //ASSERT(context.hasValidQuerySelectorAllResults() == m_querySelectorAllResults.contains(context));
     if (!context.hasValidQuerySelectorAllResults())
         return nullptr;
     auto* results = m_querySelectorAllResults.get(context);

diff --git a/Source/WebKit/WebProcess/WebPage/WebPage.cpp b/Source/WebKit/WebProcess/WebPage/WebPage.cpp
index 0a9968cf7d..cf521f8189 100644
--- a/Source/WebKit/WebProcess/WebPage/WebPage.cpp
+++ b/Source/WebKit/WebProcess/WebPage/WebPage.cpp
@@ -4683,7 +4683,7 @@ void WebPage::updatePreferences(const WebPreferencesStore&
 store)
 
     updateSettingsGenerated(store, settings);
 
-#if !PLATFORM(GTK) && !PLATFORM(WIN) && !PLATFORM(PLAYSTATION)
+#if !PLATFORM(GTK) && !PLATFORM(WIN) && !PLATFORM(PLAYSTATION) && !PLATFORM(HAIKU)
     if (!settings.acceleratedCompositingEnabled()) {
         WEBPAGE_RELEASE_LOG(Layers, "updatePreferences: acceleratedCompositingEnabled setting was false. WebKit cannot function in this mode; changing setting to true");
         settings.setAcceleratedCompositingEnabled(true);

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.

9 Likes