Currently, MiniBrowser (the simple browser that we use to test WebKit2) crashes rather easily. It crashes when it is closed, but that’s not too bad. Unfortunately, it also crashes when trying to navigate to a website (shown above)! I will be working on fixing this crash first.
[This was originally a reply in Github code review for the blog article, but it seems it is better used as a comment, so, here you go]
Thanks for the writeup about this, it clarifies a few things, and repeats some things that you had told me but I already forgotten.
I think I should clarify why I’m trying to avoid OpenGL if possible.
It’s not necessarily a performance concern. In fact, for some operations, it may very well be faster than software rendering.
The problem is, it’s quite a lot of work to enable it because:
It uses an abstraction library (ANGLE) that does not know about Haiku
There is no knowledge of Haiku BGLView in the code. Some parts look hardwired to use EGL which is a more standardized way to do what BGLView does: “connect” OpenGL with actual windows and suffaces that can be shown on screen. Adding that may require some work
In addition to the complexity of interactions between WebProcess and MiniBrowser, there are also interaction with app_server to take into account. We need to implement this with bitmaps that are shared, not only between the two applications, but also with app_server who will be the one doing both the drawing (in one application) and the displaying (in another). I think I can understand how this would work with just BBitmap: app_server is the only one actually accessing the bitmaps, and the two apps are just passing them around, and sending drawing commands. But if OpenGL is involved, we add a new layer of problems, because OpenGL is running on the client side (not in app_server). This opens the possibility of many more synchronization problems.
That being said, if it turns out to be the simplest way, maybe we can go with it, see where it gets us, and work on the other parts of getting WebKit2 running. And if it turns out to be slow, or complicated, or have some other problem, we can always try to disable it later.
In the case of WebKitGTK (and, I think, all other WebKit ports), all the drawing is done client-side in WebProcess. There is no server-side drawing as app_server does. So we are in a bit of a different situation here.
I think for some things opengl in the browser is the right tool, but we also want to run on older hardware that may not have this capability, and if we stay in software rendering on those devices that seems quite bad performance wise.
I do wonder if it is possible to have both, as a best of both worlds thing : )
But that depends on the maintenance effort too, sadly. We‘ll see.
@Zardshard : Just a small general non-technical suggestion, I hope you don´t mind: It would be great if you could always include the name of the GSOC project in the thread name. This way it´s easier to follow the project and not mix it up with post from the other GSOC projects.
Progress! NetworkProcess is now also launching, and it is WebProcess that crashes instead of MiniBrowser (although MiniBrowser crashes soon afterwards).
Nicosia – from what I’ve heard, this is a wrapper around Cairo. I believe our drawing API is similar enough to Cairo for this to work.
IIRC, I wanted coordinated graphics, coordinated graphics wanted texture mapper, and texture mapper wanted Nicosia.
So now our code mirrors the things that WebKitGTK enabled:
SET_AND_EXPOSE_TO_BUILD(USE_TEXTURE_MAPPER ON)
SET_AND_EXPOSE_TO_BUILD(USE_COORDINATED_GRAPHICS ON)
SET_AND_EXPOSE_TO_BUILD(USE_NICOSIA ON)
SET_AND_EXPOSE_TO_BUILD(USE_ANGLE ${ENABLE_WEBGL}) // I want to avoid enabling this
PulkoMandy indicated that using ANGLE may be difficult. Luckily, I’ve avoided it for now. It seems from the above code seems to indicate that ANGLE is only required if you want support for WebGL, so it should be easy to avoid in the future too.
Unfortunately, I have had to allow WebKit to use EGL for now. I don’t know yet whether it works out of the box or how much work it will be to get working. I’ll first have to fix some other bugs before I can get an idea.
EGL on Haiku is still broken at present, you won’t be able to use it. (But as I noted on IRC, EGL isn’t enabled for GTK either, so WebKitGTK clearly functions without it; thus there must be some way to get WebKit to function without it, too.)
Yes, currently. As long as that is true I‘d definetely avoid opengl as it adds only overhead. But as soon as this does not hold true there may be merrit in having both implementations present.
I’m not so sure about that. The drawing in app_server is not very fast, especially for compositing bitmaps together, and OpenGL may actually be a good choice for that, even software rendered.
I don’t think we can decide based on performance until we have it up and running and we can measure it. My experience in other projects is that performance problems are rarely where developers think they are, and benchmarking is important.
Anyway, there are a lot of other problems to fix before we try to get something on screen, so let’s work on that part first. I asked WebKit developers and they confirmed that OpenGL is optional, both the GTK and WPE port can run without it, but they do this by a runtime flag, not a compile time one. So it’s possible that some parts of WebKit currently don’t build without OpenGL, but these parts can be disabled at runtime. And it’s also possible that this problem will go away “on its own” in one of the next updates to WebKit (by this I mean, someone else will fix it for us).
Which benefits are you talking about, besides (possibly) performance? I don’t see any. In the end, most of the drawing will still be done by app_server, with just the final step of copying the data on screen done by OpenGL. So, it wouldn’t change much, except being possibly faster, or possibly slower.
Well, app_server commands are an api and opengl is an api.
I think if we have performance problems in app_server compared to software rendered openGL we can likely improve this if needed.
Perhaps some parts of the openGL api are indeed a better fit than current app_server commands.
add to this the patchset that might allow app_server to use direct rendering in the future : )
The rendering is not OpenGL in any of the WebKit ports. It’s either Cairo or Skia in the Linux ports, and it is app_server commands in ourcase. This doesn’t change when you enable OpenGL, for the simple reason that OpenGL is a 3D API, and rendering a webpage is mostly a 2D work, with, for example, a lot of text rendering, that OpenGL has no idea how to do.
The OpenGL functions will be used only for compositing, and even then, only in some cases where the website requested it. Because setting up a whole 3D rendering stack for rendering a website is a lot of work, and only worth it for websites that do crazy transparency and rotation effects and animations.
I will point out that when you avoid OpenGL you are traveling the path less traveled… 99% of browsers out there are NOT running the codepath you are trying to enable. So… I’d suggest rethinking that and work on getting the underpinnings to be as much the same as everywhere else as possible.
A TON of websites require compositing so unless you want to render like its 2005… yeah do what everywhere else does.
Yes, there’s a cost to not enabling it and there’s a cost to enabling it. I still don’t know the exact costs to either path since I’m currently working on fixing another problem. Later I’ll need to measure the cost of both paths and make a decision.
At this point runtime cost is irrelevant… since it isn’t working, so saving yourself any pain points by making it work the same as everywhere else is probably what I’d aim for.
Also, hardware OpenGL needs to happen, adding one more motivation for that isn’t hurting anyone.