[haiku-appserver] Re: Going "back" to partially hardware accelerated drawing

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 21 Apr 2005 11:21:34 +0200 CEST

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)


Other related posts: