| Re: [AD] acquire_bitmap weirdness |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] acquire_bitmap weirdness
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Sun, 1 Jan 2006 13:20:02 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=Jw8KXpVYoGB02+ylHqSb/0D9zwWWLcD2YW8YlG+bJQfiwXJnttLryweR/lpFnSHk3bBNZWbGTggMyvHAjQEKLRoHHIXS5l7s8QwyNQwmCGWN+lTtwfuZYT4YG7NSH/qbvrbn4hiHI/tAnapoJEN7MxUBBP10qbjItFPwuoRaZgg=
On Sunday 01 January 2006 12:06, Robert Ohannessian wrote:
> The real solution is d): deprecate acquire/release_bitmap, make them do
> nothing in Windows (what about on X11?), then implement all the Allegro
> functions using the DDraw portion of the API that does not require
> locking.
In X, acquire/release_bitmap on video bitmaps map to mutex's. This is needed
because the X input stuff is done from a different thread from the X graphics
stuff and can cause Xlib async errors if two calls happen at the same time.
When it was first implemented, it was shown to provide a significant
performance boost to lock once during multiple drawing operations on the
"video" surface (which is really a memory bitmap but with special vtables to
draw to the real X surface at the same time).