Re: [AD] Changes to aWiki

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2006-02-15 at 17:48 +0000, Peter Hull wrote:
> Now I'm confused. Does it return AL_DISPLAY or AL_BITMAP? If the
> former, why is it called al_create_display_bitmap?
> 
> My own view is that the destination for all drawing should be implicit
> (so, for example, putpixel would be al_putpixel(x, y, colour) ) with a
> function to select a particular bitmap as the destination. This is
> because most drawing is done to the same bitmap (especially now that
> the details of double buffering etc are handled by Allegro) and it
> would also get rid of the strange parameter ordering between blit and
> draw_sprite.

I like this. An Allegro program could look like this:

----
AL_DISPLAY *display = al_create_display(640, 480, 0, 0, 0);
al_line(0, 0, 100, 100, RED);
AL_BITMAP *bitmap = al_create_bitmap(100, 100, 0, 0, 0);
al_select_bitmap_display(bitmap);
al_line(0, 0, 100, 100, BLUE); 
al_select_display(display); 
al_blit(bitmap, 50, 50);
al_refresh_display();
----

al_create_display would make the newly created display the selected one,
and subsequent commands could access it. This also applied to
al_create_bitmap, in case it needs to display (e.g. for video bitmaps).
al_select_display would implicitly de-select the previous display, for
example if a modified bitmap needs a texture upload, or maybe to
gl_flip() on the OpenGL context of the bitmap..

With the original proposal, the same would be like:

----
AL_DISPLAY *display = al_create_display(640, 480, 0, 0, 0);
al_line(display, 0, 0, 100, 100, RED);
AL_BITMAP *bitmap = al_create_bitmap(display, 100, 100, 0, 0, 0);
al_line(bitmap, 0, 0, 100, 100, BLUE); 
al_refresh_bitmap(bitmap)
al_blit(display, bitmap, 50, 50);
al_refresh_display(display);
----

Here, we always need the extra parameter (which can be confusing for
al_blit), and also need to pass it to al_create_bitmap, just in case.
And we need an explicit command to tell we are done with updating a
bitmap, in case its driver needs an action performed. (Mere memory
bitmaps is something which will still exist in 4.3, but e.g. for the
OpenGL driver, hardly would be used at all.. so must think in a new
pattern here I guess.)

So, summarized:

Advantages:
 - saves repeating the same parameter all the time
 - allows to use things like OpenGL textures or OpenGL render targets in
an elegant and completely transparent way

Disadvantages:
 - "explicit is better than implicit" - although I don't think this
applies here personally..

Other thoughts:
 - Would need to take special care for threading. Probably each thread
should have its own active display (put the _current_display global into
thread local storage, or something like that, hopefully easy to do with
pthreads). If two threads both select the same display, then they of
course need to do additional locking, just like with the other API. But
two threads could work on different displays independently.

-- 
Elias Pschernig