On Mon, 2007-03-05 at 17:35 -0500, Robert Carr wrote:> On 3/5/07, David Reveman <davidr@novell.com> wrote:
> > On Thu, 2007-03-01 at 20:19 -0500, Robert Carr wrote:
> > > I've recently drafted a rough idea of a composite manager
agnostic
> > > protocol for leveraging the compositor for retained drawing in a
way
> > > suitable for highly interactive and flexible applications.
> > >
> > > It seems to be that for anything like this to be a success it
would
> > > have to be developed with the support of multiple window
managers, and
> > > I would appreciate any feedback, ideas, and contributions to the
draft
> > > on behalf of the Compiz crowd.
> > >
> > > The RFC is available at:
> > >
http://wiki.freedesktop.org/wiki/Standards_2fComposite_2dretained_2ddrawing
> > >
> > > PDF (much better formatting) at:
> > >
http://gitweb.beryl-project.org/?p=users/racarr/architecture/.git;a=blob_plain;f=cmrds.pdf;hb=HEAD
> > >
> >
> > >From reading the draft it's not obvious that it's a
retained mode
> > drawing interface. It looks more like an immediate mode drawing
> > interface to me.
> >
> > Anyhow, whatever we'll come up with for retained mode rendering, I
> > strongly believe that the retained model should be completely
separated
> > from the communication protocol.
> >
>
> Mm, I was a bit confused as to the definition of retained drawing,
> resarching this more, it is an immediate drawing setup, though it
> would be relatively easy to extend this. I planned to update the draft
> with a sort of way to get a handle on a drawing sequence and it would
> be repainted until a remove request was sent (Would obviously be very
> neccesary).
>
> This still wouldn't really be a retained drawing protocol but it seems
> like it would suffecient for a lot of needs.
>
> > I don't know what kind of retained mode drawing interface that
will be
> > good for the future and I'm not really interested in selecting
one. I'm
> > interested in coming up with a very general description that only
> > defines a loose hierarchical model which can be extended to fit
whatever
> > retained mode drawing that we want today and tomorrow.
> >
> > The current drawing code in compiz needs some work. It was originally
> > design for much less than what it's doing today, it still does a
decent
> > job today. We've been extending and tweaking it to make it work
for what
> > we want to do and we've been able to do this without making it too
messy
> > but it's far from good. I have some pretty exciting ideas for how
we can
> > re-design the drawing infrastructure in compiz and incrementally make
> > changes to get there. I'll send an outline for this to the compiz
list
> > sometime soon so it can be discussed more. However, the re-design of
the
> > compiz drawing framework relates very much to the need for being able
to
> > provide retained mode drawing interfaces and I look forward to
> > discussing this more.
> >
>
> I agree, one thing that I think would be helpful is compositing the
> screen (By screen I mean the nontransformed screen) to a texture (via
> FBO or pbuffer). I have a mostly working implementation of this. This
> could allow for a lot of interesting things.
Yes, this is useful but I've been avoiding this as much as possible to
use less memory resources and not require FBO support for some effects.
The changes I plan to make to the drawing infrastructure will allow you
to easily push some sub-tree of rendering into an offscreen surface. It
will require FBOs though.
>
> One thing that seems like it could be improved to me is the need to
> throw a lot of damageScreens in things like cube. With some sort of
> new screen painting function not tied in to paintScreen, cube (as an
> example) could use viewports composited to textures rendered on quads
> and any animation that would be causing damages under the new system
> could just be handled by moving the quads/modelview matrix (in the new
> function which would be seperated from actually painting the screen).
> If any actual damage occurs core would update specific regions of the
> textures just as it would repaint specific regions of the screen (and
> in the case of pbuffers glCopyTexSubImage the damaged regions).
>
> The biggest difficulty would seem to be texture memory, in the case of
> cube rendering viewports to a texture most (if not all) of the
> benefits would dissapear if only using one texture (updated before
> each quad is painting), but hsize s->width*s->height textures is a
bit
> of a hog.
>
> Another problem is plugins like 3D but this could be solved pretty easily.
Plugins will be able to do this easily but by doing so they'll also
raise the hardware requirements significantly. Hence, avoiding it when
possible is still going to be a good idea.
- David