RE: [AD] Changes to aWiki

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

> Well, in the OpenGL driver, we will need to:
> 
> - use textures to store bitmaps, for efficient rotated scaled alpha
> bitmaps (i'm not sure you can get that with something like
CopyPixels..)
> 
> - allow to update those bitmaps, also with OpenGL
> 
> So, my assupmtion was, "pbuffers" is what we need. Is there something
> else? 

Yes! This is what FBOs are for.
http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.t
xt



> But the current AllegroGL way of doing the operation on a memory
bitmap,
> then re-uploading a texture, really is bad. So if it is at all
possible
> to do it in an OpenGL way, we should try to put that in.


I totally agree, but FBOs (nor pbuffers) are available everywhere. So we
do need to have a codepath for the case where we need to draw into a
memory bitmap and reupload a texture.


> It wouldn't
> need to be in the initial driver, but the API should allow the
> possibility.

Allegro currently gives us this possibility. Or perhaps I misunderstand?


> 
> If my view of the issue above is correct (and quite likely it's not,
I'm
> not an OpenGL expert at all) - how much extra complexity would it be?
I
> was assuming it's rather simple, something like:
> 
> al_opengl_driver_create_surface(w, h, format, flags) {
>    ...
>    if (flags & BITMAP_NEEDS_TO_BE_UPDATED_A_LOT) {
>       opengl_data->context = glx_create_context() // or whatever is
needed
>       surface->vtable->blit = al_opengl_driver_blit
>    }
>    else {
>       surface->vtable->blit = slow_memory_blit_then_texture_upload
>    }
>    ...
> }


I don't see why you'd need this. Always construct an FBO if you can.
Avoid pbuffers (they're evil).