Clarifying scope and goals for weston

[Kristian Høgsberg]

On Fri, Apr 19, 2013 at 11:03:16PM -0700, Kenneth Graunke wrote:
> On 04/18/2013 12:04 AM, Sam Spilsbury wrote:
> >On Wed, Apr 17, 2013 at 1:34 PM, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> [snip]
> >2. Re-use of weston functionality
> >
> >Weston has a lot of really great functionality that would be useful to
> >lots of different desktops. I'm thinking about some of the core-stuff
> >like geometry / texture clipping, opaque region calculation, video
> >capture, damage handling, gbm etc.
> >
> >This stuff is really hard to get right, and its a big ask for people
> >to deliver new shells on top of the wayland protocol when they have to
> >get all the groundwork right first. Also, the main goals of renderers
> >and display managers don't really differ at that much, you just want
> >to get it a) right and b) fast. To that end, encouraging code sharing
> >makes a lot of sense.
> [snip]
> 
> I couldn't agree more.  A lot of work has gone into Weston to handle
> these things correctly and efficiently.  I don't see any benefit to
> making each desktop environment reinvent this code in their
> compositor.
> 
> Today on X, we have inconsistent performance between KDE/GNOME
> Shell/Unity/XFWM and so on.  That seems like a tangible downside to
> reinventing the wheel.
> 
> I can't comment about the feasibility of weston-as-a-library or
> DEs-as-shell-plugins, but finding a solution that takes this burden
> off of DE authors and gets it done right/fast for everybody seems
> like a fantastic feature in a new window system.

I agree too, but the problem is that it's hard to reuse weston as
without also reusing the scene graph and renderer.  The mess that is
all the input helpers in libwayland-server is from trying to split out
input code without the scene graph.  It's really hard to extract any
meaningful, reusable logic without being able to transform events and
do hit-testing.

On the output side, the weston scene graph is really simple - it's
really just a stack of 2D surfaces - to facilitate easy analysis when
trying to map KMS pageflips and overlays.  Toolkit type scenegraphs
(QML, Clutter) has a lot of flexibility that tend to get in the way
when trying to reason about occlusion and coverage.  Bandwidth saving
optimizations such as clipping obscured damage or splitting the
surfaces into opaque and transparent primitives just seem out of reach
when you have to deal with general 3D objects and punch through
several layers of abstractions.

However, most existing desktop compositors are integrated with and
invested in their current scene graphs.  GNOME Shell isn't going to
ever drop clutter.  I could imagine a split where libweston is a lower
level scenegraph and handles top level windows from wayland clients
and GNOME Shell just uses clutter for UI elements, which in turn are
just wayland clients.  That way we can share the input stack between
weston and GNOME Shell as well as other weston plugins such as the RDP
backend, remote rendering, fbdev and android backends.

There are weston backends out there that off-load all rendering to
custom, fixed-function 2D blender hw, or even all scanout-time
compositing (each surface is a sprite) backends.  I wish there was a
way to use that with GNOME Shell and other real desktops.

Kristian