Re: [AD] Progress report on Linux console Allegro

[Jason Wilkins <fenix@xxxxxxxxxx>]

On Wed, 23 Jun 1999, Shawn Hargreaves wrote:

> I presume your new stuff consisted of the console save/restore hooks?

You were replying to me, but I must comment.  In BeOS, switching
'consoles', called 'workspaces' here, did not require new hooks because I
could register a callback (read, implement a virtual function) that is
called when the console switches and just acquire the screen before the
switch, thus resulting in any code that uses acquire/release bitmap
working properly.

My big question is, does the library cache the information from the screen
bitmap anywhere, the reason is that there is no guarantee that the screen
bitmap will be at the same address when you acquire it again later. Or,
worse yet, modify or use any information without first acquiring it.  
This is because it is possible that I may have to reinitialize the screen
stucture when I get it back.  So, if anything from this structure is
cached and used outside of acquire/release blocks then it will be the
source of much frustration.

I was going to make the behavior configurable as well, so it can either
suspend when you switch, or just let it draw into a hidden buffer (which
is needed anyway to store the contents of the framebuffer during the
switch).

If we added a general function to control background behavior, it would
probably be added to the system driver.

There is no reason to break out builds, just add the functions to the end
of the structure and they will automagically be set to NULL. (am I wrong?)
Then, make us all put them in a pretty order sometime before we release
4.0

> The lost bitmap callback system is still in place, although I'm not sure if 
> the code currently implements it. It would almost certainly be better to 
> save the image automatically, though: that is the Right Thing to do, and the 
> only reason we don't on Windows is because DirectDraw is incapable of it.
> 
> I like your idea of saving the image automatically if no handler has been 
> installed, or letting the program deal with it if they've set up a lost 
> bitmap callback.

What exactly does the lost bitmap callback do?  Does it give you a chance
to save the bitmap, or just to know that it was lost and it needs
restoration?

I was just going to create a be_hidden_screen, that I saved everything to,
and that could even be drawn into if the user selected not to suspend
went they switched consoles, if they did suspend then it just won't be
drawn into when they are hidden.  In anycase I just restore the screen
when they switch back.  Easy.

I guess the Be implementation never loses the bitmap, I always have a
chance of saving it before I lose my connection to the screen.  The
question is, why change this behavior if the user registers a lost
bitmap callback?  If BeOS and Unix never lose the bitmap, we should
continue on and just ignore it because the lost bitmap callback isn't
needed.

> --
> Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
> "A binary is barely software: it's more like hardware on a floppy disk."

--
         The Phoenix - President of The Artistic Intuition Company
    Caelius * Zen-X * Mirror Reflex * Runica * X-Domain * Infinite Realms
                          http://www.io.com/~fenix