On Tue, 2004-05-18 at 10:10, Andy Ritger wrote:
> OK, thanks for the explanation. I'm not sure how applicable this
> is to the synchronization concerns I have, though. My biggest
> concern (new damage occuring inbetween when the composite manager
> decides what to recomposite, and when it does the composite)
> wouldn't be helped by this XSync mechanism.
>
One strategy is to recomposite *everything* on the screen...
Remember, we'll only actually do graphics operations on the damaged
part of the screen; the rest get clipped by the damage region.
> The other concern (how to make sure direct rendering has completed
> by the time the drawable is used as a source in a composite
> operation) conceptually would be solved as you describe, but I
> expect the implementation would be buried deeper -- either an X
> driver doesn't call into the core X server to notify it of damage
> until the direct rendered damage has completed, or the X server
> has to block, as Keith described, when it receives requests that
> uses the pending damaged drawable as a source. Either way, I think
> it makes sense to leave this up to each vendor; the implementation
> details will likely be influenced by their architecture, etc.
>
Yeah, we have to sweat through the details and see if this approach
all hangs together, and how DRI and the X server would interact.
The devil is in the details, as usual.
- Jim
--
Jim Gettys <[EMAIL PROTECTED]>
HP Labs, Cambridge Research Laboratory
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
