[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Video subsystem draft
Re: Video subsystem draft
Sat, 10 Dec 2005 22:01:53 +0100
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
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
> - 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.