Re: Video subsystem draft

["Vesa Jääskeläinen" <chaac@nic.fi>]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
> 
>>> First of all I'd like to see some double buffering feature.  Will that
>>> be somehow possible?  In that case we need functions like:
>>>
>>> - Switching to a buffer, making it visible.
>>> - Selecting which buffer is used for output.
>> Yes, double buffering is possible of course ;) It's not even hard one.
>> There are some issues that must be decided.
>>
>> Most important one is, what you want to do with double buffer, do you
>> want access to actual pixel data? Should this access be hidden or
>> emulated. What happens when there are different graphics modes. Do we
>> need to implement pixel data conversion layer.
>>
>> Or do you want only to hide some possible artifacts? Eg. having many
>> changes to whole screen per refresh cycle? Current idea was only draw to
>> screen when there is something new to draw.
> 
> Right, but in that case you can draw to another buffer and just
> switch.  Usually that switch changing a pointer or offset in a
> register of your video card.

Offset in video card might not be accessible. With VBE it is hidden from
coder and there is optional function to setup screen starting position.

>> Now if we assume that there will be double buffering then there is
>> problem where the actual data is stored. As we don't have fancy drivers
>> for each video card there, we must use provided features of VBE (or
>> similar interface).
> 
> If double buffering is not available we have to make a copy of the
> buffer to the video memory.

Ok.

>> In banked modes, switching the bank can be slow, and if we require that
>> double buffer is store on video memory, accessing (read&write) can be
>> slow. It could also limit some modes from user as there is no room for
>> double buffer. And worst case is here that some implementations of VBE
>> can be buggy in this case... Ever seen div by zero from video bios ;) ?
> 
> AFAIK you can access all video memory from protected mode without bank
> switching.  Please correct me if I am wrong.  Anyways, we can always
> implement double buffering in software or make it optional or so.

Only when there is complete frame buffer available. It's not case with
banked only video cards :). Fortunely those are starting to be rare, but
there are some still left. I noticed that someone added to TODO list (in
wiki) to support banked modes in VBE, there might be a reason for this.

Oh btw. That crashing thing was when setting up frame buffer dimensions
(and it failed quite badly). And this is needed when supporting hardware
double buffering.

But we can emulate this in software to ease it out as you suggested.

>> If we store this memory to host memory, then accessing it is fast, but
>> swapping the whole screen can be slow. We could of course implement some
>> dirty regions to optimize transfer time. Now if you want direct access
>> to frame buffer data (read&write) then who is responsible to make sure
>> pixel data is correct for the display? Do we need to convert pixel data
>> on transfer?
> 
> In that case the pixel data should be correct for the display so it
> can be directly copied.

Ok.

> Anyways, if the hardware is capable of doing double buffer, I would
> prefer that to avoid flickering.  It could be optional or so.  But it
> would be nice if the option is there.

I think this must be standard feature from coders point of view.
Otherwise there might be mistakes on handling it correctly.

>> My idea was following in current implementation:
>> - Supply basic operations on video driver
>> - If there is complex graphics needed, use bitmap (it would have
>> transparency support)
> 
> How would it support transparency?

Using "alpha" component of the colors in bitmap. If it is zero, it is
completely transparent (no need to draw a thing), if it would be 255 it
is completely opaque. And between those, it would require some calculation.