On Fri, Jun 22, 2007 at 10:56:54AM -0500, Lloyd Sargent wrote:
> On Friday 22 June 2007 10:48, Ville Syrjälä wrote:
> > On Fri, Jun 22, 2007 at 08:30:24AM -0500, Lloyd Sargent wrote:
> > > On Friday 22 June 2007 03:28, Ville Syrjälä wrote:
> > > > On Thu, Jun 21, 2007 at 03:43:54PM -0500, Lloyd Sargent wrote:
> > Windows have their own backing store, ie. the window surface is always
> > in offscreen memory and it will be copied to the layer surface when you
> > flip the window surface.
>
> Okay, so assuming that DFB believes that I have hardware backing store, am I
> correct in believing that the FLIP copies it to the hardware backing store
> and then I have to do another FLIP on the primary surface?
No it is done automatically. The only thing you have to do is call
Flip() on the window. What will happen:
1. If the window is double buffered the changes are transferred from the
window's back buffer to the front buffer. If only a portion of the
window was changed, the changed region will be copied, if the whole
window was changed the buffers will simply be flipped.
2. The wm will update the layer's back buffer in the region that
was occupied by the changed region of the window. Note that there may
be multiple windows visible in that region (due to blending and color
keying), so the wm will combine the data from each windows' front
buffer to produce the final image.
3. The wm will then flip the layer's surface to make the changes
visible. It will only flip the changed region so typically this also
involves a copy operation instead of a real flip.
> Where I'm getting confused is when (and how) does DFB know when to FLIP the
> front<->back?
At least with the default wm it happens every time you flip a window, or
at least it used to (I haven't really kept up with the wm
developments). It might not be a very efficient way to handle it.
At one time I was thinking about changing the wm to have a separate thread
which would just do something like:
while (true) {
wait_for_vsync();
flip();
}
That should produce tear free screen updates. Of course there must be
some way to get the changes from latest front buffer to the previous
front buffer. Probably easiest would be to copy the whole front buffer
to the back buffer however that might be a bit too heavy, so it would
should probably only copy the changed regions back.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
