KitsunePrefecture

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 ;-))

1 reply

PulkoMandy Developer

[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.

nephele Developer

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.

1 reply

BlueSky

@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.

1 reply

Zardshard Developer

Progress! NetworkProcess is now also launching, and it is WebProcess that crashes instead of MiniBrowser (although MiniBrowser crashes soon afterwards).

Technical details

To get this far, I’ve enabled

• Coordinated graphics – explained in blog post
• Texture mapper – explained in blog post
• 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.

---

Not a bad idea. We shall see…

I thought Haiku only had software rendering?

Didn’t think about that. Will do.

3 replies