Better Embedding API proposal

[paulrouget]

These are just cosmetic changes, but that would make it easier from the perspective of the embedder to use libservo.

• WindowEvent should be functions. For example, servo.reload(id) instead of servo.handle_event(vec![WindowEvent::Reload(id)]).
• make it easier to include modules. See Too many use when using libservo #18475
• remove all the window layout related WindowMethods (scale_factor/framebuffer_size/size/client_window), use a shared structure, and let the embedder send these info to servo when the layout changes. Basically, remove the WindowMethod/EmbedderMsg, and use the equivalent of WindowEvent::LayoutChanged(LayoutStruct)
• WindowMethods related to navigation (load_start, load_end, …) should become events. And embedder has to deal with an event loop. It makes sense for Servo to provide events instead of callbacks. Maybe by just queuing EmbedderMsgs.
• WindowMethods:present and composite should have their own callbacks
• the event loop waker should be passed as an argument of the Servo::new function
• make it so we don't have to call Servo::handle_event(vec![]) all the time Can we make it so the embedder doesn't need to call Browser::handle_event() when there's no event? #15734

[paulrouget]

I will be working on this. But first, I'm experimenting with embedding Servo in an Android app, and I also need to understand the impact of multiprocess and sandboxing.

[antoyo]

I started to write a crate for a gtk binding to servo and there's one thing I'd like a better API.
Currently, we cannot create the Servo object before the view is shown, which made me used this weird trick to be able to provide a nice API to the users of the crate.
So, it would be nice to be able to create the Servo object before the view is shown (with perhaps having some method to call when it is shown) in order to simplify this code.

Also, I don't know what you meant by that:

WindowMethods related to navigation (load_start, load_end, …) should become events. And embedder has to deal with an event loop.

But if I had to manage a second event loop in my crate, it would become way more complex, for the creator of the crate, but also to the users.
Unless I misunderstood this sentence.
What is the idea behind this?

Thanks.

[paulrouget]

Currently, we cannot create the Servo object before the view is shown

Yes. I'm planning to fix that once I introduce multi-window support. We would initiate Servo first, then attach compositors.

Also, I don't know what you meant by that:

WindowMethods related to navigation (load_start, load_end, …) should become events. And embedder has to deal with an event loop.
But if I had to manage a second event loop in my crate, it would become way more complex, for the creator of the crate, but also to the users.

No, you won't need a second event loop. It's just a cosmetic change. Instead of having to implement the WindowMethods, the embedder would pull the available events from Servo and loop through them. The same way the ServoShell does.

Because 1) servo already have these events internally (EmbedderMsg) and 2) widgets toolkit use events internally, we should not use callbacks.

Then, any wrapper around Servo (ServoGtk, ServoQt, ServoWebview, …) would translate these events to widget specific callbacks.

[ghost]

Sorry, I hesitated to create a separate issue for my question but how can I embedded Servo in a Java/JOGL software? Of course, JOGL is able to create an OpenGL context, NEWT (its own windowing API) is able to drive the event loop to ensure rendering and input processing but is there a JNI binding for Servo?

I'd like to use Servo with JOGL to render web pages. I'd like to be able to write the UIs in HTML/Javascript with a mean to know which events are generated when the user clicks on a link, for example to build the menus in my first person shooter.

[paulrouget]

In theory, there's nothing blocking you here.
Would you need to render the page on a texture or would the page have its own gl buffer?

[ghost]

@paulrouget Do I have to write the JNI bindings myself? I try to evaluate the amount of time required to have something partially working. I saw somewhere that you're working on a tiny JNI binding targeting Android.

I was thinking about using a FBO to render to a texture as a first step. What do you mean exactly by "its own gl buffer"?

[paulrouget]

PR #20912 will provide a simple servo library for Android with the JNI bindings.

You can render on a texture. That will work.

[ghost]

@paulrouget Thank you. I understand that's a work in progress. If I need to use a larger subset of the Servo API, I might temporarily use jnr-ffi. Which methods do you plan to keep in libsimpleservo? I've looked at jniapi.rs, I see only a few methods to resize the browser, go back, load a URI, ...

[paulrouget]

I need to use a larger subset of the Servo API

What do you need?

[ghost]

What do you need?

Maybe I'm missing something obvious. I know that I have to call Java_com_mozilla_servoview_NativeServo_init first, it creates the context and JOGL can create an external context bound to this one. I understand that HostTrait.flush is called when the GL buffer has been updated but I don't know how to get the content of this GL buffer.

[paulrouget]

In Java, create a surface. When Servo calls present(), make the surface current. Servo will then draw on that surface. You have access to the surface in Java, so do whatever you need, like using it as a texture.

[camelid]

triage: is this still an issue?

[paulrouget]

triage: is this still an issue?

Yes. Still relevant.