A barebone version of Weston?

[Mikalai Kisialiou]

Pekka,

Thank you for your response. To clarify it, I am not developing another
windowing interface that will compete with Weston or QT Compositor. My
application is completely different and the open source graphics driver
stack is the likely bottleneck. I'm not even sure that Mesa/Gallium can
give me the rendering speed that I need.

Based on the responses I've received so far I think I understand now that
the client interface is a much bigger concern for the Weston developers. I
will simply clone my own copy of Weston as it exists today and will commit
bug fixes only as needed. And yes, I want to keep it relatively "dead"
because one man's dead fork is another man's stable source. ;)

Thanks,
Nick


On Thu, Jul 12, 2012 at 5:20 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 11 Jul 2012 23:03:06 -0700
> Mikalai Kisialiou <kisialiou at gmail.com> wrote:
>
> > Juan, Jonas and Christopher,
> >
> > I appreciate your feedback! Small additions to shells are indeed not a
> > problem. It was not a right example to make my point. As it is now,
> Weston
> > can be considered barebone since the code base is small. The question is
> > how long it will stay that way, given some interest from Canonical to
> > integrate it into Ubuntu QQ or RR (hopefully QQ) and potentially other
> > distros.
> >
> > Please, let me give you another example of what I'm trying to do (without
> > going into application specifics that you are unlikely to be interested
> in).
> >
> > Suppose that you want to develop your own Wayland compliant server
> > (W-server) that can render in 3D. Due to renderer's complexity you
> > anticipate that the compositor will grow quite a bit and that will pose
> > significant problems for future testing.
> >
> > So, before you start out, you want to set up another very simple
> compositor
> > whose job is _not_ to composite but to _test_ functionality and speed of
> > the graphics driver stack, X as a client, some other hardware, client's
> > compliance to Wayland protocol, and so on. The purpose of such a W-server
> > is to have a regression system that checks dependent
> > _libraries_and_drivers_ rather than your 3D compositor. If something goes
> > wrong with client's rendering (e.g. too slow, visual artifacts) you can
> use
> > that "regression compositor" to quickly identify if the problem stems
> from
> > some upgraded or buggy drivers. This will save you a lot of debugging
> > effort and time.
> >
> > The barebone version of Weston is the perfect candidate for the
> "regression
> > compositor". It doesn't need several full featured clients or shells to
> > minimize risk of injecting bugs. It only needs to include the minimal
> > architecture plus a set of driver/library test codes. It does need to be
> > relatively stable and up-to-date with the latest Wayland protocol changes
> > and some critical bug fixes though.
> >
> > I hope the above example illustrates one of several potential
> applications
> > for the barebone compositor. The point here is not to get rid of useful
> > features from Weston. They are surely needed when I use Weston as a
> _user_.
> > The above example uses the compositor as a _tester_ with predefined
> > composite screen objects.
>
> End user features seems to be the ones that need most testing and are
> the hardest to test, especially interactions with the desktop-shell
> plugin.
>
> To get a bare-bone Weston, you simply don't load the desktop-shell
> plugin, but something else (granted, which doesn't exist yet). No need
> to fork anything, just write a new shell for testing the core features.
>
> Weston already has a testing framework, too. There are few tests, where
> an additional plugin is loaded into Weston, test clients interact with
> Weston, and then a fail/pass result pops out. It just needs a lot more
> and better tests. You run the tests by 'make check'.
>
> Once someone decides to make a software compositing version of Weston,
> they will probably abstract compositing into the backend or some new
> plugins. Then it's easy to add a dummy compositing plugin for testing
> everything but graphics.
>
> Forking Weston would only lead to an unsynchronized, dead fork, IMHO,
> if the only purpose of the fork is testing. And then, it wouldn't test
> Weston, it would test the fork.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120712/c71c89b2/attachment.html>