render improvements

[Owen Taylor]

On Tue, 2005-04-19 at 23:25 +1000, Keith Packard wrote:
> On Tue, 2005-04-19 at 07:15 -0400, Owen Taylor wrote:
> 
> > Possibly the most efficient thing to do is to simple, whenever you need
> > to read data back from a pixmap in the framebuffer for a composite
> > operation, is to simply kick the pixmap *out* of the framebuffer 
> > permanently.
> 
> That's really bad for my most common environment where text cannot be
> accelerated to windows which are about to be composited to the screen
> which can (and really should) be accelerated.

Well, no, it's just mildly bad, assuming that you have enough free
scratch space to copy the pixmap into video ram immediately before
compositing it... if compositing is just limited by system => video
bandwidth, that still is pretty good.

> We obviously just want things to go as fast as possible, and I don't
> think this is actually that hard to compute -- each compositing
> operation can be reasonably modeled by computing the number of pixels
> read/written to each object and assigning static scores to
> in-memory/on-card for each object, now we just figure out how a sequence
> of operations can be most efficiently executed for a range of objects
> and move each to the right side of the bus.

If we just want things to go as fast as possible, the fastest setup is
likely to keep space reserved for a copy in both places ... we can
always update the one in video ram cheaply. That of course isn't
necessarily compatible with a secondary goal of not using huge amounts
of memory.

Regards,
						Owen