[cairo] Road to 1.10

[Kristian Høgsberg]

On Mon, Feb 16, 2009 at 4:42 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Mon, 2009-02-16 at 10:11 +0100, Alexander Larsson wrote:
>> This is more of a feature request, since I've no time to implement this
>> myself as things stand. But, after Gtk+ 2.16 is released (should be
>> shortly now) we will try to merge the client side windows branch. The
>> client side windows branch of gtk virtualizes all drawing to GdkWindows
>> such that we can emulate the effects of subwindow clipping on the client
>> side.
>
> I agree that a form of device clipping is necessary to safely expose a
> sub-surface to a direct rendering client, in particular I've been
> thinking about this with regards to wayland.
>
> So at the moment my thought is basically to add a clip extents to a
> surface which may be smaller than its true extents. The biggest
> difficultly lies in applying source clipping. Not too difficult for
> cairo-drm where we can set up a sampler to a subset of a surface, but
> for xlib support, I fear we may need to make a copy of the sub-surface
> for the source.
>
> Has anyone else had any thoughts about sub-surfaces?

In the context of wayland, I've been thinking that we can just always
allocate a temporary surfaces for the clipped rendering.  We typically
need to do that for double buffering anyway, but in the case where
we're emulating a sub-window during the off-screen rendering, we'd
need to allocate an extra surface.  Having a device clip would remove
the need for that surface, but I don't know that that's something that
is worth adding API for.  How often is this needed after all, and how
big are these sub-windows?  Isn't it mostly gtk+ menus that still use
child windows?  And of course this could be done for cairo xlib too by
just allocating a pixmap for the child window.

cheers,
Kristian