Re: Video subsystem draft

[Marco Gerards]

Vesa Jääskeläinen <address@hidden> 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.

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

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

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

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.

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

> - When bitmap is loaded, it would be converted to device compatible bitmap

Sounds sane.

> - If there is a need to generate bitmap data, it should be done in
> emulated pixel buffer (something like R8G8B8A8) and then converted to
> device compatible bitmap.

Ok.

--
Marco