Re: Video subsystem draft

[Vesa Jääskeläinen]

Marco Gerards wrote:
> What is the emulation you talk about for set palette?

In order to support theming, there is most likely some predefined
colors. We could use palette to save those defaults. When certain color
would be needed then we just ask for color with grub_video_map_color ()
and it would access palette and return hardware compatible color value.
In indexed VGA modes there is possibility also to set palette, and user
could use special palette. Now if we emulate this behavior also in RGB
modes, it would make life easier for theme scripter/designer as in
indexed color modes and in RGB color modes behavior would be same.

Now what are the actual values for the grub_video_map_color, I haven't
yet decided. But I was thinking something like this:

Values 0-255 would be identical to the palette indices. If value would
be 256 or larger then it would be a theming alias for palette index and
it would be accessed thru theming framework that has not yet been
designed and then theming framework would either return index to palette
or actual RGB value depending on the active video mode.

Let's assume theme designer would like to have three colors of a blue
and there is no comparable colors in standard VGA palette. And he would
also like to specify those colors also in indexed color modes. So he
decides to configure those color to palette. Now if those colors would
be later requested by rgb mapping or by using those indices those colors
would be available and show correctly to end user both in RGB modes and
in index color modes. And what is most important, theme designer doesn't
need to bother whether end user has index color or RGB mode.

> Why are viewports needed?

Idea of the viewports was that if there is certain region of the window
that should be saved from editing. Let's assume C-64 style console ;).
You have border where there is one specific color and then different
area where the text is being drawn.

Now we first clear the whole screen with border color and then setup
viewport where the text would be displayed. Then all rest functions to
draw something to screen is being limited that viewport and border area
would be saved from modifications (no need to redraw those). Now if we
thinkg about scrolling screen up. On normal case whole screen would be
scrolled and borders would need to be redrawn, but with viewport only
place to need redrawing is the bottom area that is new.

Of course this would change a bit if there is background bitmap. But in
that case it would still make it easier to use the actual display area
as all coordinates are relative to viewport. Only hard problem would be
on scrolling. Now if you have animated background you must render
affected section all the time and depending on animation you most likely
would not need to setup viewport. If there is no need for viewport, it
will automatically be maximized to full screen, so if it is not set,
then user doesn't even notice it's limiting factor.

> 
> Have you thought about how to load bitmaps?

My idea for loading bitmaps would be that there would be different
functions to load bitmaps. And when bitmap is loaded the bitmap would be
converted automatically to display optimal format. Only disadvantage of
this is that if screen mode changes, the bitmap information would be
needed to be reloaded in order to be displayed correctly.

One option here would be that there would be that display driver would
be required to convert between different formats. This could create some
overhead and cause some slowdown.

I haven't thinked what would be best format to save those bitmaps, we
could support multiple formats by using modules to hide differences
between those and then have some wrapper function to walk thru all
bitmap loader modules.

> I don't like using grub_uint*_t for parameters.  Just use normal
> integers instead.  These types just have to be used for ABIs and
> network and disk access.  In the case of APIs such types should be
> avoided.
> 
> So better use "int height" instead of "grub_uint32_t height".  This is
> especially important for portability and it serves no purpose.

Ok... grub_uint32_t is unsigned version, so would it be reasonable to
use unsigned int instead of int and do we assume that int is normally
signed, or should I explicitly write signed int or unsigned int?

> Is it possible to pass parameters like depth to grub_video_setup?

Depth?... Are you thinking 3D-displays here :) ? Or are you building up
some kind of Z-buffering?

> Will it be possible for other users than the terminal to use these
> functions?  I think that would be nice.  But in that case a function
> should be used to redraw the screen.

Most of the functions could be used from scripts, only problem is that
scripts would need to handle different data types correctly (like bitmap
etc).

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