[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)
Rudolf.
Other related posts:
