RE: [AD] No more video/system bitmaps

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2005-05-31 at 20:42 -0700, Robert Ohannessian wrote:
> > 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.

In that case, it would be better to have a command to explicitly change
the usage. Instead of:

tmp = create_bitmap(DYNAMIC_DRAW);
// do the drawing to tmp
real = create_bitmap(STATIC_DRAW);
blit(tmp to real)
destroy_bitmap(tmp)
// now use real

I would rather have:

real = create_bitmap(DYNAMIC_DRAW)
// do the drawing to real
change_usage_pattern(STATIC_DRAW)
// use it

Or, the very same happens when I load it from disk. Initially, it must
be a memory bitmap, which then gets promoted to a video bitmap once all
data are loaded.

> > 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.

Or a per-display list? Maybe each AL_DISPLAY would have its own OpenGL
context as well.

> 
> > 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"

Just for reference, this is the VBO spec:

http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt 

>         STREAM_DRAW_ARB    The data store contents will be specified once
>                            by the application, and used at most a few
>                            times as the source of a GL (drawing) command.
>         STREAM_READ_ARB    The data store contents will be specified once
>                            by reading data from the GL, and queried at
>                            most a few times by the application.
>         STREAM_COPY_ARB    The data store contents will be specified once
>                            by reading data from the GL, and used at most
>                            a few times as the source of a GL (drawing)
>                            command.
>         STATIC_DRAW_ARB    The data store contents will be specified once
>                            by the application, and used many times as the
>                            source for GL (drawing) commands.
>         STATIC_READ_ARB    The data store contents will be specified once
>         		   by reading data from the GL, and queried many
>                            times by the application. 
>         STATIC_COPY_ARB    The data store contents will be specified once
>                            by reading data from the GL, and used many
>                            times as the source for GL (drawing) commands.
>         DYNAMIC_DRAW_ARB   The data store contents will be respecified
>                            repeatedly by the application, and used many
>                            times as the source for GL (drawing) commands.
>         DYNAMIC_READ_ARB   The data store contents will be respecified
>                            repeatedly by reading data from the GL, and
>                            queried many times by the application.
>         DYNAMIC_COPY_ARB   The data store contents will be respecified
>                            repeatedly by reading data from the GL, and
>                            used many times as the source for GL (drawing)
>                            commands.

In your proposal, you only left out the COPY usage hints:

> "Static" means the image does not change after being defined.
> 
> "Dynamic" means the image does change often.
> 
> "Stream" means the image will not be used often after it was defined
> (for example, for temporary bitmaps).
> 
> "Read" means the application will perform reads on the bitmap via
> al_acquire_region().
> 
> "Draw" means the application will not perform reads on the bitmap via
> al_acquire_region() (other reads are OK).

Now, of course, I wonder why the COPY is missing. It would be in your
list, from what I see:

"Copy" means the application will not perform writes to the bitmap via
al_acquire_region() (other writes are OK)

But then, I'm somewhat confused by it all right now :P

So, when this goes into Allegro, we should have an entire chapter for
it, with a lot of concrete usage examples..

-- 
Elias Pschernig