Hi, to add my 2 cts.
All on the latest DirectFB.
My idea on how this should work, I can say it works on the latest driver
I've worked on.
If you create a buffer, it is not cleared by default.
The only clearing mechanism present is the background clearing, but this
is not to be relied on, since this is not active if you claim the
context privately, I think. It also costs performance.
Normally, if you have an off-screen buffer this is not an issue, since
you can have a Clear immediately following the CreateBuffer, or you can
just start drawing the stuff before Blitting or Flipping it to the screen.
If you do a GetSurface of a layer, this should not show the layer; it
will merely return a surface object, and not even allocate the (first
only 1, also if double or triple, allocate on demand) buffer. When you
do a Lock it will allocate the buffer, but still not show it. Only when
you do a "flip" for the first time (this also holds for single-buffered
implementations) it will "enable" the layer in the graphics driver and
show the already "correct" buffer. From then on, any second or third
buffer in the surface will need no special attention. Not that
RemoveRegion should "reset" the mechanism, so the disabled layer will
only show again after a flip.
I don't know how it should work without a correct driver though (fbdev
operation)...
Hope it's "clear".
Greets
Niels
Strelchun, Timothy wrote:
I just realized a behavior change in our new DFB 1.2 based systems driver as
compared to our previous 1.0 based driver...
Newly created visible and non-visible surfaces do not appear to be cleared
after they are allocated (previously done by default window stack I believe).
Is it an expectation of a CoreSurfaceBuffer Pool Manager to clear newly
allocated raw pixel buffers?
>From what I can determine, it is-- at least for external (CSTF_EXTERNAL)
surfaces used for DSCAPS_VIDEOONLY surfaces (visible/non-visible). Maybe however
it is not necessary for video low/high because the initial system memory based
surface is cleared by the DFB core when created based on the associated pixel
format?
Any insights into the design intentions here would be helpful and appreciated.
Thanks,
Timothy
--
Timothy Strelchun
CE Software Engineering
Digital Home Group
Intel Corporation
The views expressed above are my own and not those of Intel
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
