Re: [AD] Progress report on Linux console Allegro

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> Yes, it's possible in Linux.  It's sort of fundamental to how it ensures 
> that you don't switch consoles in the middle of a drawing operation if 
> it'll be running in the background afterwards -- you have to call a 
> function `block_vt_switch' before critical sections, then 
> `unblock_vt_switch' afterwards.

Those block and unblock calls can use the exact same mechanism as the 
Windows acquire/release. The user can call them directly for speed, or it 
happens automatically in the bank switch code. There are two flags in the 
bitmap->id field, BMP_ID_LOCKED, and BMP_ID_AUTOLOCK. When the user locks a 
bitmap, the lock count is incremented and the locked flag is set. When the 
user unlocks a bitmap, the lock count is decremented, and if it reaches 
zero, the locked flag is cleared and switches are renabled. Inside the bank 
switch function, it checks the locked flag, and if the bitmap is not already 
locked, it locks it and sets the BMP_ID_AUTOLOCK flag as well as 
BMP_ID_LOCKED. Then when the unbank switch routine is called, it can check 
for BMP_ID_AUTOLOCK, and if this is set, unlock the surface.

In other words, user locking maintains a nest count, while automatic locking 
is an on/off toggle (because a single drawing routine may switch banks many 
times, but only call the unbank switch once at the very end).

It feels like this code ought to be sharable across multiple platforms, but 
looking at the actual implementation (in wddraw.c), the autolocking logic 
is a very tiny piece of code: almost all the logic is for dealing with 
the DirectDraw side of things. We can certainly use a helper file to 
maintain the list of moveable bitmaps, and to adjust the line pointers when 
they change, but I think the logic for deciding when to call this should be 
left up to the individual platform. The moving code actually already exists 
in wddraw.c, so you might be able to turn that into a shared helper, but the 
Windows situation is somewhat different to most other platforms (multiple 
independent video surfaces rather than one large area), so it might be best 
left alone.

> I can't see any hidden traps, other than Shawn's comment that subbitmaps 
> aren't the only problem.

As long as you can make sure that switches don't happen in between a bank 
switch call and the next unbank switch, this won't be a problem. A true 
multitasking OS may not be too keen on the idea of your app telling it 
"don't switch now, I'm busy", though :-)

> The other question is whether this should be called from the vtable 
> callback or the system driver callback, but I think that's really up to 
> the author of whatever OS it is.

I imagine that most people would put it in the graphics driver (vtable). For 
example on Linux, the switching mechanism will be very different if we are 
using fbcon or GGI, since they already have some built in support that will 
do most of the work for us. But the system driver is there if anyone wants 
it. Actually, I imagine that the system drivers will always tend to have far 
more NULL methods than anything else. I added lots of hooks just for the 
hell of it, but the default behaviour is usually quite reasonable if you 
don't provide these.

> Should the vtable callback actually be in the graphics driver though?

The graphics driver already has control over what vtable is used for the 
screen surface, since it is the one that creates the screen bitmap. The way 
this works is that graphics.c contains a local, static vtable object. When 
the graphics driver calls _make_bitmap(), the system driver is asked to 
provide a default vtable for that color depth, which is then block copied 
into _gfx_vtable, which is used for the screen bitmap. The reason for this 
is that the graphics driver is automatically set up with a working set of 
drawing routines, but is then free to replace any vtable methods that it 
likes to add special behaviours over the top of this.

The default vtables have to come from the system driver, because they are 
needed for memory bitmaps, and people might create those even without any 
graphics driver being active at all.


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