RE: [AD] New graphics API, take 2

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Bob writes:
>> Bitmaps are already extremely polymorphic, and can only 
>> benefit from becoming more so if extra things need to be 
>> added to support them doubling up as display surfaces.
> 
> Yes, but I'd hate to see it turn into some huge object with 
> 20 more vtable entries.

How is putting things in the bitmap vtable any worse than 
in the display vtable? There's no cost from vtables being
huge (only one of them needs to exist per type, so it is
an insignificant space overhead).

Display-specific routines wouldn't even have to go in the
root vtable, if you adopted some sort of derived class
system (which would probably be a good thing anyway). eg:

void al_do_display_specific_stuff(BITMAP *bmp)
{
    ASSERT(bmp->vtable->subtype == AL_BMP_TYPE_DISPLAY);

    AL_DISPLAY_INFO *info = (AL_DISPLAY_INFO *)bmp->extra_data;

    info->vtable->whatever();
}

It would actually be really handy (and would have been in
the past for some drivers) if there was a way to attach
multiple independent bits of custom data to a bitmap. Not
sure quite how to do that, but it would be great if eg.
the framework code could attach a structure that was 
specific to the fact that it was a display bitmap or a
sub-bitmap or whatever, and the driver could attach a
different struct specific to the underlying device, etc.

At the ultimate level, perhaps the bitmap struct could
vanish entirely:

struct AL_BITMAP
{
    AL_BITMAP_VTABLE *vtable;
};

which would allow entirely different implementations to
add whatever data they wanted without having to drag
around unused baggage from other types, eg:

struct AL_2D_PIXEL_BITMAP
{
    AL_BITMAP_VTABLE *vtable;
    int w, h;
    int bpp;
    int clip_l, clip_r, clip_t, clip_b;
    void *line[];
};

struct AL_RLE_SPRITE_BITMAP
{
    AL_BITMAP_VTABLE *vtable;
    void *rle_data;
};

and then each vtable entry could cast the generic AL_BITMAP
type to their specific type before using it.

This system would work better if all the structures were a
fixed size, which would mean the line table being allocated
separately rather than tacked onto the end of the bitmap
with a variable sized allocation, as that would allow
drivers to create their own types by concatenating custom
data onto the end of one of the standard structures.

(yeah, going very C++ in concept here, but inheritance is
a nice thing. The current system handles polymorphic code
well, but is very poor at adding extra data to derived
classes)

> Finally, if we have multiple displays, then we need the 
> input mechanism to be aware of it. mouse_x() and mouse_y() 
> represent the mouse on which display? Should we pass them 
> a bitmap, or a display?

A bitmap. It would have to be, if there was no such thing
as a display type :-)

>> Consider the case where a GUI dialog manager has been 
>> written to render itself onto a display object
[...]
>> but then someone wants to change it to render onto a memory 
>> bitmap for whatever reason.
> 
> Well, I'd consider using the init_dialog/update_dialog/
> end_dialog loop for anything more complicated than a simple 
> dialog

Sure. But my point was that if there is a single polymorphic
type, it can be much more flexible than if there are different
types for slightly different things. In the former case, you
can make the same piece of code do quite different things just 
by passing it a different object, but if the types are 
different, you have to change code to get the same effect.

This is just an extension of how bitmaps can already be
anything from simple bits of memory to blocks of video memory
to sub regions of other bitmaps to potentially GL textures
or whatever (and people were talking about making RLE and
compiled sprites be special types of bitmaps as well, which
is an appealing idea).

I'm just not seeing what it is about display surfaces in 
particular that requires them to be a different type, when
a lot of the power of the current API comes from the fact
that so many different things can be accessed through the
same type. Pretty much everything you can do to a bitmap
also makes sense to do to a display, and every display
object must always have a bitmap associated with it, so
why maintain a difference between them?

I think part of what bothers me about having both is my
experience with D3D, which has a similar type distinction
between IDirect3DSurface8 and IDirect3DTexture8 (speaking
of which, al_* is a much nicer and less intrusive prefix
convention than IDirect3D*8 :-) D3D has a similar concept
to what you proposed in that different functions apply to
surfaces or textures, and you can query a texture to
access any of its mipmap levels as a temporary surface
object, but in practice this is a real pain: as soon as
you start doing render to texture operations, you end up
with huge amounts of code and hassle just for converting
between these types and making sure you've released all
your temporary objects at the right times and so on. It 
is a pain to work with, and would be much easier if you 
could just have a single pointer that would do for both 
types.

> Finally, there's the icky issue of sub bitmaps. If the user 
> declares a subbitmap of the 'screen', then passes that to 
> al_show_dissplay() (al_show_bitmap?), then what? Copy only 
> that sub-bitmap?
[...]
> What if the user passes a non-screen bitmap object?

Obviously, not all operations can be supported on all types
of bitmap. It is nonsense to try to page flip a memory bitmap,
but that doesn't mean you shouldn't be able to use the exact
same code to draw rectangles onto anything, be it a memory 
bitmap or a video bitmap or a display surface or whatever...


-- 
Shawn