On Mon, 06 Oct 2008 22:02:46 +0300 Vesa Jääskeläinen <[EMAIL PROTECTED]> wrote:
> Andy Goth wrote: > > "Colin D Bennett" <[EMAIL PROTECTED]> wrote: > > Requiring full-screen repaints is an architectural design that > > might need rework to undo later. Or might not, depending on how > > you implement it. The interim approach you choose now should be > > informed by foresight. > [...] > Hi, > > I would like to thank Andy for his comments on the topic. I do share > the same concern about designing double buffering to work properly > without making hasty implementation first. We can use non-buffered > solution as a first stage "hasty implementation" and design good > enough solution to handle double buffering well. > > Dirty rectangles for every buffer (two in double buffer case) might be > the best approach here. I think there is some kind of dirty rectangle > implementation on gfxterm so that could be used as a base for this > work. After that it could be improved to increase performance but the > main point being that there has to be proper framework to make it > work properly. > > Usually the slowest step is to transfer image data from main memory to > video memory (and usually the slowest is to read from video memory to > main memory and then save it back to video memory). If we can optimize > memory copies between video and main memories we are on good track to > solve speed problem. I agree that a dirty region repaint management system will provide better performance, but I certainly do not have time to implement it now. IMO that would take a lot of work. I *am* interested in getting high performance, but (1) I simply don't have time to do it myself right now, and (2) gfxmenu seems plenty fast to me--I have run Lua-driven full screen animations as a desktop background for gfxmenu, and it worked fantastically. The menu system performs decently even on my ultra-low-power-but-low-performance-too Via C3 system. Granted, the gfxterm terminal is nearly unusable right now, but I think its performance can be improved significantly through a few relatively minor changes. Regards, Colin
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
