Using Servo as an application design tool when it becomes embeddable?

Support
1

Hi,

I was wondering - we could technically use the Servo engine as a frontend tool if it becomes embeddable (for frontend design of GUI applications, such as Mail, Word processing, etc.). This excludes the Javascript engine, which is written in C++ and has been known for memory attacks. Servo is more optimized than stuff like Electron. Once we get Servo to run on Redox, we could have both a good browser (let’s face it: we can’t make our own browser) plus a RAD tool. Especially as a layout engine.

This could reduce the effort for maintaining OrbTK. Not saying that is should go away, but writing an own layout / rendering engine that can handle advanced features such as layout / animation / etc. is a huge undertaking, simply from the structural part (architecture, etc.). We should really not focus on making yet another rendering library, especially when a good solution (like Servo) already exists.

Currently, the problem is that Servo handles only Javascript events. It would maybe be feasible to make a custom fork of the Servo project and write a wrapping API that can accept Rust events instead of Javascript and expose that as an API in a shared library. This is still less work than writing a full rendering engine. Other operating systems use someting like GTK or KDE for drawing - in Redox this could be libservo.

The goal would be that everthing including the compositor would be written in HTML + CSS - even the window styling could be done. Servo has very good frame times so far, performance and memory usage should not be an issue.

For this to work, the following support would be needed:

  • Graphics drivers - an OpenGL implementation. Servo can go as low as OGL 2.1, so that would be the minimumn that has to run.
  • Multithreading that works with rayon.
  • Windowing system - Sevo uses glium as an underlying driver (which is a safer wrapper around OpenGL than sdl2). Redox should be able to open a glium window and reduce the dependency on a C-based library such as SDL2.

If that isn’t possible, we should at least look into webrender as a rendering engine. It does not have layouting capabilites, but at least things Redox is missing, such as gradients / animations, etc. The goal is to let Mozilla do the heavy lifting of writing all the rendering code.

What do you think about this?

4 Likes
2

I have thought this is the way of the future for quite some time! I’d love to work full-time on making this a reality. If anyone wants to sponser me, let me know! :wink:

1 Like
3

I really like this idea because web-based applications (de-facto independent on hosting system) should be the future. Do I understand correctly that embedding Servo would bring native-like run for the web apps?

4

I’ve looked into it. There are a few requirements necessary before this can be done.

  1. The video driver has to be refactored (currently working on it). In the end, everything that is needed is a Vec<u32><u32> with the pixel data that is copied into the display. How this is drawn is up to the compositor.
  2. We need a software renderer for OpenGL 2.1. This could be done with existing crates like softrender and then write an interpreter for GLSL. Later on we could maybe write Intel HD Graphics drivers.
  3. We’d need servos stylo and layout and webrender crates and then write a Rust API for it. There is a CEF API, but that doesn’t suit us - it includes unnecessary parts like bluetooth, audio and whatnot. We don’t need those.
  4. We need dynamic linking to work (it currently doesn’t). The idea is to compile Servo into a libservo.so, then load them from various applications (including the compositor).

The performance would be essentially native, since there’s no JavaScript, only compiled Rust. It would be faster than anything OrbTk would produce. Plus, the resulting applications are more portable.

2 Likes
5

Uh, if we are serious about applications we will very much need those in the future. Naturally, Redox doesn’t support all of that yet, but the missing parts can be stubbed out for now.

As of my experience software renderers are impractically slow. This has been tried with GNOME Shell - the idea was to require OpenGL and fall back to a fairly advanced software implementation (Gallium3D LLVMpipe) when it’s unavailable. And this has never, ever worked fast enough to be usable.

1 Like
6

This architecture is somwhat similar what I had in mind for NodeOS GUI apps :slight_smile:

Disclaimer: I’m lead developer of NodeOS :wink:

7

Well, GL4ES runs OpenGL 2 contexts on top of OpenGL ES 2. That should be quicker than software rendering.

8

Tangentially related: