On Wed, 2005-10-19 at 22:44 +0200, Denis Oliver Kropp wrote:
> It also depends on the buffer mode. If the back buffer is in system memory,
> it always copies the content. Flipping a sub region always copies, too.
> Usinf vesafb without panning results in a system back buffer, unless you
> use single buffer mode. You can force a system back buffer by setting
> DSCAPS_SYSTEMONLY, if you're using DSCAPS_PRIMARY. If you're setting the
> layer configuration you can choose the buffer mode directly.
Well I setup the system the same way for both as follows.
DFBCHECK (DirectFBInit (&argc, &argv));
DFBCHECK (DirectFBCreate (&dfb));
DFBCHECK (dfb->SetCooperativeLevel (dfb,DFSCL_EXCLUSIVE));
DFBCHECK (dfb->SetVideoMode(dfb,1024,768,16));
dsc.flags = DSDESC_CAPS | DSDESC_WIDTH | DSDESC_HEIGHT;
dsc.caps = DSCAPS_PRIMARY | DSCAPS_FLIPPING;
dsc.width = 1024;
dsc.height = 768;
// Surface Creation
DFBCHECK (dfb->CreateSurface(dfb, &dsc, &primary));
DFBCHECK (primary->GetSize(primary, &screen_width, &screen_height));
DFBCHECK(primary->SetBlittingFlags(primary,DSBLIT_BLEND_ALPHACHANNEL));
For both vesa and the driver (which there is no DFB gfxdriver for)
return this from dfblayer:
Width 640
Height 480
Format RGB16
BufferMode BACKSYSTEM.
The only difference between that and when it was running on a CLE266 was
BufferMode BACKVIDEO.
So the cyblafb driver, which has no DirectFB gfxdriver right now, has
the same settings as vesa, however I get this same behaviour. I'm not
saying DirectFB is at fault, however, how I understand the Flip and all
that is obviously not quite right as it worked before, and now I'm
confused.
Let me explain how I saw it working, and perhaps you can explain why
that is wrong?
When under vesa, I would clip simply to make sure I didn't overwrite
(draw over) something in the background in the area I was drawing. So
for example, when doing the animation, I clip an area, Fill it with a
color, blit some images, and blit the moving images into a new place.
Then I flip (and flipped using NULL). When I did this, the area that I
had clipped was the only thing to change. Without a change to the code,
when I do this I see everything that doesn't get drawn to from the
previous screen because of the clip, and my new moved images. What is
the difference between these two behaviours?
I'm a little confused by what you mean in flipping a subregion always
copies. Meaning that it copies that region from the back buffer to the
front, instead of swapping like when you do a flip without a region?
If that is the case, then my program should then follow this:?
DrawMainMenu (flip using NULL)
input request NextScreen
NextScreen()
Blank background, draw all static content & FLIP using NULL
Iterate animation with clipping & FLIP region.
So Flipping with NULL swaps the buffers meaning that in my current
program, when I first start going from the DrawMainMenu function I'm
drawing to the back buffer, and when I flip, the main menu is now the
back buffer. but because I draw clipped, it draws that clipped portion
to the back buffer (which is/was the main menu image) and then flips
between that, alternating between drawing on the background, and on the
old background (main menu).
So my question is why didn't this happen before? Especially if it says
that it is using the BACKSYSTEM instead of BACKVIDEO? I'm just
confused... Any thoughts on this behaviour?
> I'd suggest to only flip the updated region anyways. Only flip the whole
> surface if you really rendered to the whole surface.
I'll be modifying it to do this, however I'm still uncertain of the behaviour
so need a little more info...
As this is my first DirectFB app, I would love it if someone could
critique my source. It is all in one file, however it is 1400 lines
before main & event loop. Lots of that is fluff I guess SQL/Font setup
and tear down. I realize you and most people here are extremely busy,
but if someone can take a look that would be great.
And again, thanks for all the time put into DirectFB and helping its
users. I hope to become a competent developer of DirectFB apps and be
able to offer this same type of support and suggestions to other once I
get it myself.
--
Nathanael D. Noblet
Gnat Solutions, Inc
http://www.gnat.ca/
T 250.385.4613
C 250.383.4613
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
