Vesa Jääskeläinen <[EMAIL PROTECTED]> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
