On Thu, 22 Mar 2018 10:49:23 +0200 Ilia Bozhinov <[email protected]> wrote:
> Hello to all, > Some of you may know that I've been working on a wayland > compositor(primarily for the desktop), and I decided it was time to share > what I've done(although it still needs much more work), here is the link: > https://github.com/ammen99/wayfire > The most "novel" thing it does is implement the desktop cube in wayland :D > > It needs a patched libweston, so I'd like to raise another question: Is > there any interest in implementing custom rendering for libweston, and if > yes, how should it be implemented? > > A proof-of-concept implementation: > https://github.com/ammen99/weston/commit/1eefc1301bddf593fc994900996507ffc97ffa75 > > Is this even close to the design goals of libweston? Hi, I am glad to see your work, and that is a very good question. Below is my personal take on the matter. The idea for libweston so far has been to try and limit the API surface we would need to set in stone to be able to claim that libweston has a stable ABI. So backends and renderers were so far left as internal details, while stuff needed by shell plugins and main()s would be public ABI. The hope was that this would allow us to actually draw a clear line between public and private APIs during the coming years. Along that plan, we would aim to make the central huge structs like weston_compositor, weston_surface, weston_view, and weston_output opaque. A renderer will dip into most of these in ways that is outside of the imagined public API. Currently renderers also need specific code in the backends to initialize, but I suppose that could be abstracted to basically Pixman and EGL (until someone wants to make a Vulkan renderer). On one hand it would be nice to let people do what they want. On the other hand, upstream needs to maintain libweston, and it would also be in the external projects' interests if libweston gained a stable ABI. The more ABI surface, the harder it is to maintain, and most of the current ABI has not even been designed really, so it's leaking approximately all implementation details. Unfortunately, people (me especially) have been busy elsewhere rather than pushing forward the stable ABI dream. I think that if you simply proposed to add a few simple hooks to be able to load your own renderer module without thinking about the ABI stability issues, I would be inclined to say "no". However, I would warmly welcome you to join the effort to separate a stable ABI out from the current mess, and alongside that you could design a renderer ABI as well. Mind, along the course we would likely have to redesign big portions of libweston core, particularly around the scenegraph. Designing ABI without users is almost impossible to do sanely, so your input would be invaluable. Having a defined renderer ABI would also have a huge benefit: testing. If all renderers were behind the same'ish ABI, the renderers themselves could be unit-tested. Also libweston core could possibly be tested better with a mock renderer. Right now, we can only test the Pixman renderer, ironically, in integration tests. The GL renderer still has no automated tests. One more requirement is that whatever interfaces you need to have added, they should also be used in Weston upstream itself. If they're not used, they will break, and the urge to just remove them as clean-up will be great, because of the desire to reduce the API surface. As a summary, yes, I think it would be possible, but it would take a serious commitment to make it happen. You need to become part of the upstream rather than send your bits upstream. :-) A concrete suggestion would be to move the existing upstream renderers behind the renderer API you need. Thanks, pq
pgpnwrjAlkOrR.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
