Stephan wrote: > I don't know hard facts about how the drawing implementation changed > in > Dano, but I would think it simply syncs drawing commands with the > refresh, as I can still observe "flickering" in some occasions. The > double buffering in our current implementation also has nothing to do > with preventing flickering. That's two different things actually. > I'm not against a double buffered screen update, but I would do it > differently from how it's done right now - in order to be able to use > hardware acceleration. This means the back buffer would have to be in > graphics mem. It would mean no change to an existing single buffered > design, only that there is an additional front buffer in the gfx mem, > which is updated during the screen retrace. That would avoid > flickering > to some extend. Blitting is _not_ synced to retrace in dano at all. Doing such a thing is probably a bad idea, because it will leave you with just a few percent of the engine's bandwidth slowing everything down (or just delaying: I will do some test for this someday). Stephan: please note that using a second buffer on the gfx RAM is _not_ supported by the drivers, hence you will _not_ be able to use acceleration for copying back-to-front! Doing that using a virtual screen whould be a hack solution (there was talk about this specific thing earlier here). This hack solution would mean you have to change BSCreen's public access to virtualscreens. Using this setup was ruled out I seem to remember. For R1 (later on you can change the driver-interface so you get support) Rudolf.