GTK+

[antoyo]

Hello.
I forked this repository and adapted the example to work with GTK+:
you can see my current work here.
There are some minor issues (documented at the top of src/main.rs) and I'm not sure on how to fix them, but it works nevertheless (if you see a black window, just move the mouse over it).
This uses my fork of epoxy that is yet to be merge upstream.
I hope you find this interesting and I wanted to tell you that I'm interesting to contribute to make a gtk binding for servo.

To make it work, I had to comment this line when doing the epoxy gl generator.
Otherwise, the application aborted with an error about glPushGroupSomething.

Also, I had to fix some dependencies to specific versions and I don't know why.
Without that, cargo complained about not being able to choose between different versions of the crates.

Do you know how to fix these issues?
Thanks.

[paulrouget]

if you see a black window, just move the mouse over it

This looks like it's because you don't call handle_events when the event loop is awaken by the EventLoopWaker. Is it what gtk::idle_add supposed to do? Or maybe present() doesn't do an immediate buffer swap.

To make it work, I had to comment this line when doing the epoxy gl generator. Otherwise, the application aborted with an error about glPushGroupSomething.

I have no idea why that's necessary. But likely related to WebRender. You might want to file a bug under servo/webrender.

Also, I had to fix some dependencies to specific versions and I don't know why.

It's because both Servo and epoxy use gl_generator. I think it's fine to update Cargo.lock and target a higher version.

I hope you find this interesting and I wanted to tell you that I'm interesting to contribute to make a gtk binding for servo.

Yes! Probably what would help us the most would be a gtk port to https://github.com/paulrouget/servoshell (see under src/platform).

Also - you work on Titanium right? I'd love to hear more about what would be necessary for you to fully support Servo. Titanium is a perfect example of what we want to achieve with Servo in term of embedding.

[antoyo]

Thanks for your answer.

Yes, I currently use idle_add() since I don't know if there's an event for the wakeup method.
I planned to fix this issue.

Also, I'm not sure if queue_render() immediately swap buffers: I'll see what I can do.
(Edit: I don't think it's actually an issue as the glutin example has a similar issue. It's probably caused by some window event not sent to servo in both cases.)

My plan was to port the servoshell to gtk-rs when I'm done with this example.

And yes, I'm the maintainer of titanium.
I mentionned here what would be needed for me to use servo.
When I'll be done with porting servo to gtk-rs, I'll probably be able to help you with this stuff.

[antoyo]

Also, do you know why the rendering is not the same in my gtk version?
Here's a screenshot:

As you can see, there's a glitch with the button.
Thanks for your help.

For your information, using queue_render() seems to be okay (same issue with not repainting when moving the window to another screen in the glutin version).
My mouse position issue is also present in the glutin version.
So I think my only remaining issues to fix are using the awake event and the framebuffer size.
Does glutin automatically repaint with the good size when resizing the window?

[paulrouget]

As you can see, there's a glitch with the button.

Using the same version of servo?

For your information, using queue_render() seems to be okay (same issue with not repainting when moving the window to another screen in the glutin version).
My mouse position issue is also present in the glutin version.

By glutin version, you mean the glutin version of servo-embedding-example, right?

So I think my only remaining issues to fix are using the awake event and the framebuffer size.

Ok.

Does glutin automatically repaint with the good size when resizing the window?

Usually, you need to tell the owner of the OpenGL buffer to resize the buffer on resize.

My plan was to port the servoshell to gtk-rs when I'm done with this example.

Cool! Can you do it in a multiplatform way?

And yes, I'm the maintainer of titanium. I mentionned here what would be needed for me to use servo.

We would be very interested to help making it possible to embed Servo in Titanium. We might not match the Webkit2GTK API, but it would be great to be able to build a wrapper around libservo that exposes the Webkit2GTK API, for a drop-in replacement.

[antoyo]

I think it's the same version of servo because I forked this repository to create the gtk version.
I'll check tomorrow to be sure.

By glutin version, I indeed mean the version of servo-embedding-example.
I'll check again tomorrow, but I think I also saw the black window glitch in servoshell (glutin version), but I think I didn't see the mouse issue.

Yes, my gtk version of servoshell will be multiplatform.

I'm not sure that matching the webkit2gtk is appropriate: we can probably do simpler.
What might be even more interesting would be to create the gnome-class for the servo gtk widgets that I'll create in order to be able to use servo in gtk applications written in other programming languages.

[paulrouget]

I'm not sure that matching the webkit2gtk is appropriate: we can probably do simpler.

Sure. I'd like to understand what you need exactly to make the port possible. Feel free to file a servo/servo issue, or a titanium issue (and cc me) with a list of feature that you need.

[antoyo]

I fixed the remaining issues in my gtk version of this project.
The only remaining thing that I can see is this.
It looks like some mouses can scroll horizontally as well.
Is horizontal scrolling supported by servo?

I use the same revision of libservo, still, the rendering is different for my gtk version.
Any idea why?

For titanium, I need the usual browser events (history forward, backward, load URL, …), but also the ability to change the DOM from Rust.
I'll open issues as I need them.

[paulrouget]

I fixed the remaining issues in my gtk version of this project.

\o/

Is horizontal scrolling supported by servo?

Yes. It's the dy value here:

servo-embedding-example/src/main.rs

Line 138 in e7f0c33

let scroll_location =

I use the same revision of libservo, still, the rendering is different for my gtk version.
Any idea why?

Maybe the way you initialize OpenGL?

I'll open issues as I need them.

Thanks . cc me when you do.

[antoyo]

I've fixed the rendering issue by enable the depth buffer.
Do you know if I also need to enable the stencil buffer?

[paulrouget]

I don't know. I know that on macos we set NSOpenGLPFAStencilSize to 8 by default.

[antoyo]

I now have a gtk binding and an application similar to servoshell that works with gtk-rs (as far as I know, only the debugging features are not in my version).
There are some things I'd like to improve in the API like not having to call this method.
Also, I wonder how to handle multiple windows.
Finally, I also wonder if there's something to fix or improve in this binding before I add more features.
Thanks.

[paulrouget]

There are some things I'd like to improve in the API like not having to call this method.

SelectBrowser? You're supposed to call it only when you switch tabs.

If you have to call it for every call, that means you're not flushing the GL buffers correctly.

Also, I wonder how to handle multiple windows.

Not supported yet. I'll get to this asap.

[paulrouget]

Finally, I also wonder if there's something to fix or improve in this binding before I add more features.

Can you explain more in details what your binding does?
Is it a webview that can be used in any gtk window or does it create its own window?

[antoyo]

Yeah, I know that SelectBrowser should only be called when switching tabs, but it is not convenient for the user of the API: is there something we can do to avoid having to send this message?
In webkit2gtk, we don't have to do such a thing.
That might also explain why creating a new tab in servo-gtk is slow (I'm creating a new object instead of reusing the same).

The WebView struct can be used in any gtk::Window.

Also, I wonder if you could test the examples on a Mac.

Thanks for your comments.

[paulrouget]

Yeah, I know that SelectBrowser should only be called when switching tabs, but it is not convenient for the user of the API: is there something we can do to avoid having to send this message?
In webkit2gtk, we don't have to do such a thing.

I'm not sure to understand this. Why do you have to use this message if it's not for tab switching?

That might also explain why creating a new tab in servo-gtk is slow (I'm creating a new object instead of reusing the same).

A new object? As in, a new GL surface every time?

[antoyo]

I'm not sure to understand this. Why do you have to use this message if it's not for tab switching?

It is needed to switch tab, but I mean that in the webkit2gtk API, we don't need to do that which is convenient and I try to reproduce this API.

Yes A new GL surface is created every time.

Thanks.

[paulrouget]

It is needed to switch tab, but I mean that in the webkit2gtk API, we don't need to do that which is convenient and I try to reproduce this API.

Yes A new GL surface is created every time.

This is where things differ here. In Servo, we only have one GL surface used by all the browsers.

I'm actually surprised it is working for you :)

As of now, Servo doesn't support multiple compositors (multiple gl surfaces for one instance of servo).

[antoyo]

So, I guess we will need this feature in Servo to support multiple windows?
Thanks for your answers.