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()
And then release_drawable_lock()?
What semantics are you hoping for from the drawable lock in your scenario above? Just that the cliprects won't change while it is held?
Keith
------------------------------------------------------- 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_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
