[meta] embedding

[delan]

• WRY port with raw libservo
  • servo-wry-demo
• Multiple webviews in one window
  • Multiple concurrent top-level browsing contexts #30648
  • constellation: notify embedder when events are hit-tested to browsers #30841
  • constellation: focusing and closing webviews #30842
  • Initial internal support for multiple webviews #31417
  • Opening a new window occasionally yields a blank page #31539
  • Add multiview feature flag in libservo and servoshell #31541
  • servoshell: multiple document interface #30785
  • servoshell: add support for tabbed browsing #31545
  • send Show/Hide/Raise messages to the compositor directly (as well as to the constellation)
  • fix the confusing use of ConstellationMsg for compositor-to-embedder return communication
    • ReadyToPresent and WebViewPaintingOrder are the offending variants
    • maybe we can just use WindowMethods?
  • per-webview desktop-style page zoom
  • support for transparent or translucent webviews
  • batching for messages like ShowWebView and HideWebView
  • if too many webviews are shown at once, the compositor can get stuck in a laggy state with pending epoch warnings (to reproduce, try #31545 with 4.html and click “_blank” six or seven times)
• Offscreen rendering
  • Add initial support for offscreen rendering #30767
• Precompiled mozangle
  • Shared object for macos and linux mozangle#71
  • Windows support
  • Use shared object in Servo
• Precompiled mozjs
  • feat: add a feature flag to build from source mozjs#439
  • Move rust-mozjs's build script to mozjs-sys mozjs#409
  • feat: add MOZJS_MIRROR and MOZJS_CREATE_MIRROR env variables mozjs#443
  • [WIP]: Shared object mozjs#432
• Webviews in multiple windows
  • [WIP] Optional compositor #21808
• Tabs or subwindows in servoshell
• libsimpleservo?
  • Adapt wry to Rust libsimpleservo as proof of concept
  • Build a Rust wrapper around C libsimpleservo
  • Migrate from Rust libsimpleservo to the new Rust wrapper
• other patches
  • constellation: clean up logging of pipelines and browsing contexts #30657
  • Add multiview feature flag in compositing and constellation #30840
  • Rework “visible” to “throttled” in embedder-to-constellation + jniapi #31815
  • Rework “visible” to “throttled” in constellation + script + compositor #31816

---

• Main thread complexity #23899
• Discussion: lifetime of compositor vs. constellation, and potential compositor refactoring #23179
  • [Meta] multi windows support #13997
  • [multi window] Constellation should not assume there's one and only one compositor #13993
  • Do not run embedding code in the same thread as the compositor code #19679
• Improve the embedding API #27579

[fabricedesre]

What's the benefit of going Rust -> C -> Rust ?

[mrobinson]

What's the benefit of going Rust -> C -> Rust ?

The main benefit of this approach is the ability to ship a shared object.

[fabricedesre]

But wry is already pure Rust so it doesn't need that, right?

[mrobinson]

But wry is already pure Rust so it doesn't need that, right?

Since Servo takes so long to build, being able to ship a shared object version of Servo will make it easier for embedders to use it.

[wusyong]

We are trying to update our entry method to use raw window handle recently.
Wry itself doesn't handle other things but wrap around webview instance only. I just need to make sure Servo and other related types can work. I'll try the approach similar to servoshell first and then explore multiwindow next.

A shared object isn't that urgent IMHO. Defining a C API that is ergonomic enough is another challenge as well. I tried to deal with CEF's C API before, and the experience didn't go that well. What I think is better are shared objects for huge C++ dependencies like mozangle and mozjs. These are always the first blocker in fresh environment. Maybe we could just download and link to built shared libraries if users only want to compile servo itself. Another benefit is developers can dive into servo codebase and hack it directly. I found I often need to refactor some servo code too.

[sagudev]

Here is interesting blog post about dylib: https://robert.kra.hn/posts/2022-09-09-speeding-up-incremental-rust-compilation-with-dylibs/
I think something like that would be the best way for mozjs. mozangle is a bit more complicated on windows as we need it's produced dlls (libEGL.dll & libGLESv2.dll).

[delan]

@sagudev interesting! I didn’t realise it was possible to build a lib crate as a dylib unless we used the C ABI. I wonder if it will break monomorphisation or break if type layout changes between runs.

[sagudev]

Hm, I'm not entirely sure on stability of dylib, but thinking about it again maybe that's not the best way as we still need rust code generated by bindgen. We could just cache libmozjs static, but we might still need to run configure for bindgen so we cannot really eliminate it's build sys requirements.

[wusyong]

@sagudev It's okay to still running bindgen for build script as long as there's a static lib like deno's v8 wrapper did IMHO. People usually have trouble with C++ building setup instead of rust. Does spider monkey published their binary release already?

[sagudev]

@wusyong SpiderMonkey does offer prebuilds as artifacts on taskcluster, but we are patching SM in mozjs, so we would need to this for ourself. I have rough idea how this could work via automated CI jobs.

[wusyong]

Btw I saw mozangle also has patches but it seems they are trivial. Maybe we can try to pull angle artifact and link it for mozangle's case.

[atbrakhi]

Just an update on shared object for mozangle, we are able create shared object for mozangle using crate-type: dylib. It is working with servo on mac! Yet to test on windows though, it will be interesting!

We are also exploring possible cons of dylib and cdylib, please share if you have any thoughts/suggestions. Idea would be to have same approach for mozangle as well as mozjs

[wusyong]

As long as the building process can be easier, I'm happy to see any attempt. I think the main concern for dylib is unstable Rust ABI. But right now servo also has to stick to certain nightly version anyway. So maybe this is not a big concern for developing purpose.