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.
Thanks for letting us peeking in a little bit … into this project’s flow ! 
Appreciated if you could share - later - this Haiku native Minibrowser – if completed – via repo/depot - it will be awaited ;-))
[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:
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).
To get this far, I’ve enabled
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.
Not a bad idea. We shall see…
I thought Haiku only had software rendering?
Didn’t think about that. Will do.
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.)
ANGLE is supportable on Haiku I - it is an OpenGL ES implementation for use with WebGL for WebKit… I demoed that with the other browsers…
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).
Even if there is a performance impact using opengl, the benefits far far far exceed it, and that is what matters.
Annnddd it’s a push to get hardware rendering working
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 : )
That is a good idea in any case.
The benefit is that the rendering pipeline is now opengl, and this seems unlikely to change.
And when hardware acceleration is deployed, then it’s accelerated, and that catches haiku up to the reat if the market
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.
Good to know. Though, for now, I’ll continue with it enabled until I’m in a position to be able to test changes to it.
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.
Eh, it’s not the runtime cost I’m worried about, but more about how much time it would take to get running, because, according to waddlesplash
Edit: Oops, EGL != OpenGL. EGL is more related to creating and drawing on windows as opposed to 3d graphics.