Re: [AD] al_convert_bitmap

[Trent Gamblin <trent@xxxxxxxxxx>]

This is getting extremely complicated for something that was supposed to make things easier. I don't even follow exactly what all of these flags and options entail.

Trent

On 2011-06-14, at 2:29 PM, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:

> On Tue, 2011-06-14 at 09:27 +1000, Peter Wang wrote:
>> On 2011-06-13, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
>>> 
>>> The goal with all that is simply to make it work how people expect it
>>> without much fuss or complication. If somebody really wants full
>>> control, then can simply disable auto conversion, mark things as
>>> MEMORY and manually call al_convert_bitmap() later.
>>> 
>>> VIDEO|ANY doesn't mean much to me. It could be a distinction between
>>> destroying a bitmap upon display creation or not.
>> 
>> That's a good idea.  Right now there is no way to express to Allegro
>> that you don't care about a video bitmap after its display is destroyed,
>> so the most efficient way to clean up a display and its bitmaps is to
>> let al_uninstall_system() do it.
>> 
>> VIDEO (without ANY) would tell al_destroy_display() to destroy the
>> bitmap (as far as possible) instead of converting it.  It would probably
>> need to leave behind a zombie bitmap so that it does not crash when the
>> user calls al_destroy_bitmap().  Zombie bitmaps can simply have neither
>> VIDEO or MEMORY flags set.
> 
> Makes sense. So al_destroy_display simply would go through the display
> bitmaps and remove the VIDEO flag from any bitmaps without the ANY flag
> - meaning the only operation allowed on them from now on is calling
> al_destroy_bitmap.
> 
>>> The absence of VIDEO and MEMORY would indicate to try video first then
>>> fall back to memory. None of those three flags would mean try video,
>>> then memory, and set auto convert. That would mean there would be no
>>> way to say "I want a video or a memory bitmap but don't auto convert",
>>> but I don't think that's a useful combination.
>>> 
>>> If the flags work together like that, then I think it makes sense that
>>> VIDEO bitmaps without AUTO_CONVERT would be destroyed upon a displays
>>> destruction.
>> 
>> Yes.
>> 
> 
> We should avoid using the term "destroyed" in the documentation though
> since unless you actually destroy those zombie bitmaps with
> al_destroy_bitmap you still would create a huge memory leak on display
> re-creation. Completely destroying them actually might be more
> convenient - even if it does another bad thing of invalidating pointers
> the user might still hold...
> 
> On Mon, 2011-06-13 at 11:55 -0500, Matthew Leverton wrote:
>> Well, I suppose that's additional rationale for having it be an
>> option:
>> 0 => do nothing at all
>> 1 => auto upgrade tagged bitmaps
>> 2 => auto downgrade tagged bitmaps
>> 3 => auto upgrade & downgrade tagged bitmaps (default)
>> 
>> ... just throwing out some possibilities.
> 
> We could provide bitflags instead of numbers:
> 
> NO_AUTO_MEM_VID = 1
> NO_AUTO_VID_MEM = 2
> NO_TRANSFER = 4
> 
> and then:
> 
> 0: Auto-convert AUTO_CONVERT both ways and on destroy_display try to
> transfer any bitmaps to another display (else either convert or zombify
> depending on AUTO_COVNERT flag).
> 
> 1: Same as 0 but never convert AUTO_CONVERT in mem->vid direction.
> 
> 2: Same as 0 but never conert vid->mem (zombify instead).
> 
> 3: Same as 0 but completely ignore AUTO_CONVERT.
> 
> 4,5,6,7: Same as 0,1,2,3 but in al_destroy_bitmap never try transferring
> to another display, instead behave as if it was the last display being
> destroyed.
> 
> I'm not actually sure we need NO_TRANSFER, I guess it depends a lot on
> the reason why you have multiple displays. If it's some game launcher
> where you may want to open 4 windows with completely different games you
> wouldn't want transfers for example (if the displays are not compatible
> transferring many textures would be very slow)... but not sure that's a
> very likely scenario.
> 
> -- 
> Elias Pschernig <elias.pschernig@xxxxxxxxxx>
> 
> 
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> -- 
> https://lists.sourceforge.net/lists/listinfo/alleg-developers