[haiku-appserver] Re: drawing thread

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 01 Nov 2004 09:04:35 +0100 CET

Hi again,

Sorry for the delay once again: I was out on a short vacation last 

>       I don't really see why that is useful. maybe you can explain more 
> clearly. Thanks.
Why what is usefull? A proof of concept just for my personal joy, or 
the whole concept of this double buffering described below?
I'll try to answer both.

1. The proof of concept simply proves that the concept works :)
Of course, in order to convince _you_, you'll also need to experience 
trouble without such a solution. Well, what can I say. Just experience 
it if you need to: I can imagine you need to, as I myself need these 
things also (I don't like to just believe, I want to see proof). 
There's no better proof than to just try and see for yourself at some 

2. I can talk a bit more about why simply syncing to retrace will get 
you into trouble at some point. Say, you have set a nice screen of 
1024x768x32. It's running at 60Hz refresh. Let's say that the duration 
of the retrace is 1mS. This means that any drawing has to be done in 
this mS or you will get artifacts onscreen. Let's say an app is running 
updating a window. The update takes 0.9mS. Maybe it's accelerated, 
maybe it's just software based drawing, that doesn't matter.
OK. Now, the user decides he or she wants to run the workspace at 120Hz 
refresh. This automatically means that the retrace time will drop to 
0.5mS. The app drawing will still need 0.9mS. In fact, it is going to 
need just a tad more time, as the graphics RAM is less available to the 
system now as the card is accessing it twice as often in order to 
generate the output to the monitor.
While there were no distortions possible while running at 60Hz, you 
will now see distortions more or less clear (or: often) depending on 
the factors I described in another mail.

The retrace time is a 'constantly' varying time, you can conclude. It 
depends on the refreshrate, modeline timing: relative time needed for 
sync pulses compared to active output time; which depends on the brand 
of monitor in the end... It also depends on the resolution set.
This means you'd better not make assumptions about the retrace other 
than the fact that it occurs.


> Rudolf wrote:
> > Hi, 
> > 
> > a small update on that 'other' doublebuffering:
> > 
> > 
> >>Only good solution: double buffering entire screen and blit to 
> >>offscreen memory only, then switch offscreen onscreen during 
> > > retrace, 
> >>then blit now onscreen memory to now offscreen buffer. Repeat when 
> >>needed. 8-)
> > 
> > I would say make it triple buffering so things keep transparant to 
> > existing apps and BDirectWindow for example.
> > 1. have a normal screen, that's never shown. Here everything is 
> > drawn 
> > into, so also by apps.
> > 2. have the pageflipping doublebuffering in place, that gets its 
> > content from 1.
> > 
> > Maybe I'll try to tweak the NV driver (outside CVS) at some point 
> > to 
> > see if I can manage to set this up as a proof of concept: I think, 
> > with 
> > some limitations, it might be possible. I should probably just try.
> > 
> > ->I think it would be nice if such a feature, if ever implemented, 
> > should preferably also be an option. Just ask driver if it can do 
> > this, 
> > and if not, fallback to single buffering as it is now. (Depends on 
> > graphicsRAM available, and engine capabilities for virtual height)
> > 
> > Rudolf.
> > 
> > 
> > 

Other related posts: