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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel