Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <address@hidden> writes:
>> I thinked that selecting the bpp is not important and I optimized it out
>>  :), but if this is wanted feature I think guiding is better option.
>> There are many different RGB modes and I think that it would be most
>> reasonable to ask generally a RGB mode and then select best one.
> 
> It's relevant when someone made a 16bpp background image.  I am quite
> sure he doesn't want to use 8 bpp. :-)

I will try to add some optional flags there that can be used to guide on
mode selection. Or help on selecting actual video mode.

>>>>> How would scrolling work if a background picture was used?
>>>> I was planning that terminal would implement background picture
>>>> handling. And if there is a background picture that would scroll when
>>>> the screen is about to scroll. That area must be redrawn. Fanciest
>>>> option here would be that there would be graphical layers, but that is
>>>> more a "window manager issue" than a video driver issue.
>>> If you use double buffering, you can use a few buffers:
>>>
>>> 1) the background
>>> 2) the text and whatever the console needs for output
>>> 3) some buffer to which #1 is copied and #2 is copied (using 0 as
>>>    transparancy or so)
>>> 4) The visible buffer
>>>
>>> In that case you draw to buffer 2, prepare buffer 3.  When you want to
>>> show buffer 3 you switch it with buffer 4.
>>>
>>> What do you think of that?
>> That's not exactly double buffering :). It's more like a layering
>> combined with double buffering.
> 
> That is right.
> 
>> But your idea of layers with data can be used and is most likely good
>> approach. But should this be implemented in video driver or elsewhere. I
>> have tried to make video drivers simple to implement. Rest of the
>> graphics system would then implement fancier functions.
> 
> I also think video drivers should be easy to implement.  So this stuff
> has to be done by the framebuffer I think.  Or someplace else.
> 
>> In here I would see this as a job of "window manager". In grub's case
>> this is more like a responsibility of the terminal :).
> 
> Yeah, window manager support is something we should focus at, at
> first. ;-)
> 
>> There are two approaches that I see here:
>>
>> 1) Terminal's responsibility
>>
>> Rendering sequence would be:
>>
>> - Zero out back buffer (optional)
>> - Terminal would draw background bitmap
>> - Terminal could use multiple additional bitmaps layers and upper layers
>> could include transparency information
>> - Terminal must use font manager in order to draw text, unless glyph
>> drawing is implemented elsewhere.
>> - Swap front/back buffers
>>
>> Now good thing here is that video driver is not bloated. Bad thing here
>> is that handling of those bitmaps would most likely need same
>> functionality as is provided in non-bitmap video driver.
> 
> I am not sure if I understand you.  Can you give two practical
> examples of where it is better and where it is worse?

Biggest difference here is that in this case, video drawing functions
can only be used on frame buffer. Drawing functions doesn't support on
drawing to bitmaps. There would be immediate need to add code to render
data bitmaps, or this must be done by coder. So this could duplicate
some code.

Pro's of using this is that it doesn't require so much memory as there
is no need to store multiple layers in memory. This is better option
when there is no so much memory available.

Con's of using this is that you must to draw ALL text on screen again on
when scrolling screen or if there is some animation on other layers
(assuming that it happens over/under of the text). You most likely need
additional functions to modify bitmaps if same functionality is wanted
as on case 2.

>> 2) Partially video drivers responsibility
>>
>> Add support for rendering targets. Caller could create virtual screens
>> that can be used to render with normal drawing functions. This would
>> shift some of the jobs to video subsystem.
>>
>> Rendering sequence could be something like:
>>
>> - Zero out back buffer (optional)
>> - Render background from render target 0 (or from bitmap)
>> - Render additional layers from other render targets (or from bitmaps)
>> - Render text layer using font manager or another render target
>> - Swap front/back buffers
> 
> You want this so hardware layering features can be used?  Did you look
> at some systems like XFree already?

I was more thinking of implementing this on software. Xfree is a bit too
advanced project and I am not familiar with it's licensing, how well it
will fit in this case. So far I haven't used hardware layering
techniques? Or I think so :).

>> In order to use render targets, they must be created and they should be
>> based on the actual screen properties. Eg. Same color order and so on.
>> Resolution of the render targets could be different. This is to fasten
>> blitting process. There is also possibility to "lock" render target in
>> order to do pixel buffer modifications.
> 
> What does locking mean in this context?

This is a term from DirectX, in there locking means that certain memory
area is being allowed to be altered. By locking you specify that this is
being modified and that cannot be moved around by driver framework. When
you are ready and unlock that memory then data is transferred to it's
preferred location and possible conversions is also performed.

>> Con's of the render targets is that eats quite lot of more memory than
>> then first idea. But with them we can get prettier output more easily.
> 
> Isn't the output just the same?

Output can be made same. This is more a conceptual problem. It is more
like a what functions can be used to do what operations. If this case,
there would not be so many functions to be implemented. But it would
shift some more code to video drivers. But at same time it would make
usage more streamlined.

I will point out the word _easily_ over there ;)

>> This render target could be a viable solution, even though it shifts
>> some more work to video subsystem. It's not too hard to implement render
>> target support. So if this is a route we take it's Ok for me.
> 
> I am not yet sure if I understand it completely, I should re-read it
> when I am not that tired. ;)

I'll hope we can come up with decision what we want before next version
deadline comes :)

>> But now comes the important question :)... How advanced we want this
>> video subsystem to be in GRUB ?
> 
> As I see it we need some killer feature to compete with GRUB Legacy.
> Some neat graphics support can be that killer feature.  Especially if
> it is cross-platform.

Well.. We haven't even started to think about theming and scripting of
the GUI's :)

There are even more things to think... Some of those can cause some
headache, like timer events... How those are good to be implemented...
But there probably should be some limit at some point. Or we have
complete graphical API interface with RTOS and no need to have actual
OS... Think about that :)