Re: [AD] Progress report on Linux console Allegro

[George Foot <george.foot@xxxxxxxxxx>]

On Wed, Jun 23, 1999 at 04:20:04PM -0500, Jason Wilkins wrote:
> 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.

In Linux it's the same -- we catch a signal when our console is
switched to/from.  We then have to save the video mode state;
the main library code saves the VGA registers, but a video
driver may have (probably will have) other information to store,
in particular its extended registers.  These hooks in the
GFX_DRIVER struct are there for the switching code to call, if
non-NULL, to save/restore this extra information.

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

I'm fairly sure this was/is the case with WinAllegro too -- it's
partly what the acquire/release system is for.

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

The current Linux console version has this support almost
implemented -- completely untested though.  The old version had
the support but Marek overlooked subbitmaps of the screen, I
think -- remember that all their line pointers will need
updating if the screen bitmap moves in memory.

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

Yes, but the user shouldn't call the system driver directly I
think.  If the entry is NULL, assume switching is unnecessary or
uncontrollable.  This is closely linked with lost bitmap
callbacks...

> 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

Oh yes, good point.  Ah, except when two people extend the same
structure; but then one of them just has to put extra NULLs in.

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

No, it just tells you the bitmap has been lost.  It's called
after the event, next time you acquire that bitmap, IIRC --
that's from last year though, I'm not sure whether it's still
the same now.

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

Yes.  This is how it's done in Linux, too -- again, beware of
subbitmaps of the screen, though.  I can't see a trivial
solution.  It works fine if the app is just being suspended
though.

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

Quite, but I've still given the option to install a switch hook,
which will override the default saving routine, so you can turn
off the saving if you want to.  Any application that wants to be
portable to Windows has to be capable of redrawing like this
anyway, and for large virtual screens it could save a lot of
memory usage.

-- 
george.foot@xxxxxxxxxx

ko cilre fi la lojban  --  http://xiron.pc.helsinki.fi/lojban/