RE: [AD] No more video/system bitmaps

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

> The situation I was envisioning was this: say I want to allocate a
> bitmap, clear it to some colour, do some drawing operations on it, and
> thereafter the bitmap won't be changed.  I suppose the only use for it
> would be as a source image.  What should the initial usage hint be?

AL_STATIC_DRAW. We probably want users to pick the long-term intended
usage of the bitmap. If the initial definition of the bitmap isn't
intensive in operations that are slow w.r.t the bitmap's current
residence, then it doesn't really matter where the bitmap is initially:
it likely won't be moved then.

If you really need to do lots of render operations, you may actually
want two bitmaps: One that's DYNAMIC_DRAW, and one that's STATIC_DRAW.
Do the rendering into the dynamic one, then copy it over to the static
one.



> 
> 
> I wonder if it would be simpler to have an explicit call like
> al_define_bitmap().  Promotion/demotion would only happen at those
> calls, and only to the bitmap for which it was called.  Otherwise I'm
> afraid al_flip_display() may have too much work to do on some frames.


How about making bitmap operations update the usage counters of that
bitmap, Then, if they're above some threshold, register it in some
fixed-size (32?) list of bitmaps to promote/demote. al_flip_display()
can then just look at those bitmaps and move them around in memory.



> I also wonder what would happen if there were multiple threads, each
> calling al_flip_display() on its own display.  Would each thread be
> wanting to traverse a global list of bitmaps?

We could probably get away with a single list of bitmaps to move around.


> PS.  The word "static" is misleading if "you *never* restrict usage".
> You wrote:
> 	"Static" means the image does not change after being defined.


I just used the terminology from the VBO extension spec. STATIC is not
used in the strict sense there. 

Maybe if "usage" were renamed to "usage_hint"


> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers