Tweet
Originally posted by farnz
View Post
Exactly that. If you do it right, you can implement a proxy Wayland server that just passes things through unmodified if your upstream compositor supports the "RenderManager" extension internally, and that renders to a wl_buffer (using Cairo, or EGL/OpenVG, or EGL/OpenGL ES 3, or magic fairies, or whatever) if it doesn't.
Then, I only need to implement core Wayland in my compositor to work with apps that need your RenderManager; the app uses your proxy to convert svg_render_buffers to wl_buffers that I can use. If I see advantages to rendering svg_render_buffers myself, I can do that, too).
Note that one of many reasons to not provide a rendering protocol in Wayland is to avoid the pain X11 can get into where a client asks it to spend lots of time rendering something - X appears to take lots of CPU, while the client takes very little, because X is doing all the rendering work on behalf of the client. A separate RenderManager proxy helps with this, especially if you layer it as client->per-client RenderManager->compositor, as it's a specific client's RenderManager that starts to eat CPU, and you can thus identify the culprit.
It's also true here that (because of the way Wayland IPC is designed), you can experiment with extensions like a RenderManager without having to make the compositor aware that such an extension even exists- just write a proxy that translates your extension back into core Wayland protocol (e.g. by doing the rendering work needed to transform a svg_render_buffer to a standard wl_buffer). If the extension turns out to be incredible, many compositors will implement it internally, with no need for the RenderManager proxy. If it's useful, people will run it where it's needed, and eventually, it'll be an extension that people just assume is available.
Then, I only need to implement core Wayland in my compositor to work with apps that need your RenderManager; the app uses your proxy to convert svg_render_buffers to wl_buffers that I can use. If I see advantages to rendering svg_render_buffers myself, I can do that, too).
Note that one of many reasons to not provide a rendering protocol in Wayland is to avoid the pain X11 can get into where a client asks it to spend lots of time rendering something - X appears to take lots of CPU, while the client takes very little, because X is doing all the rendering work on behalf of the client. A separate RenderManager proxy helps with this, especially if you layer it as client->per-client RenderManager->compositor, as it's a specific client's RenderManager that starts to eat CPU, and you can thus identify the culprit.
It's also true here that (because of the way Wayland IPC is designed), you can experiment with extensions like a RenderManager without having to make the compositor aware that such an extension even exists- just write a proxy that translates your extension back into core Wayland protocol (e.g. by doing the rendering work needed to transform a svg_render_buffer to a standard wl_buffer). If the extension turns out to be incredible, many compositors will implement it internally, with no need for the RenderManager proxy. If it's useful, people will run it where it's needed, and eventually, it'll be an extension that people just assume is available.
Comment