Hi!
Keith Whitwell wrote:
get lock while (timestamp mismatch) { release lock request new cliprects and timestamp get lock }
Note that is the contended case only. What's the worst that could happen - somebody's wizzing windows around and our 3d client sits in this loop for the duration. Note that the loop includes X server communication so it's not going to suck up the cpu or anything drastic.
This is basically what I'm doing right now. The problem is as the code continues:
get lock while (timestamp mismatch) { release lock request new cliprects and timestamp get lock } wait_for_device() render_to_scale_buffer() wait_for_device() render_to_back_buffer() wiat_for_device() blit_to_screen() release_lock()
And, to avoid holding the lock while waiting for the device, since that blocks use of the decoder while I'm doing scaling operations, I'd like to
mark_scaling_device_busy()
get_drawable_lock()
get lock
while (timestamp mismatch) {
release lock
release_drawable_lock()
request new cliprects and timestamp
get_drawable_lock
get lock
}
release_lock()
wait_for_device()
get_lock()
render_to_scale_buffer()
release_lock()
wait_for_device()
get_lock()
render_to_back_buffer()
release_lock()
wait_for_device()
get_lock()
blit_to_screen()
release_lock()
mark_scaling_device_free()/Thomas
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
