Hi Craig.
This is correct, if you do a full-screen-flip.
If you are aware which area is "damaged", and provide a dirty rectangle
to the flip, than it will only do a partial flip -> it will copy just a
piece from the backbuffer to the frontbuffer and will not do a flip. A
third option is, if your dirty rectangle is nearly screen-size, to first
"fill" the empty bits by copying from the front to the backbuffer and
then do a flip using pan.
So these three scenarios: pan, back-to-front, front-to-back-then-pan,
all have their own performance sweet spot depending on the dirty rectangle.
It looks like you assume the flips are always full-screen, in that case
BACKSYSTEM is slower than BACKVIDEO. This can however be negated if your
application performs a lot of rendering/blending/reading with the
backbuffer before you do a flip ( WHEN video memory is slower then
system memory).
hth
Niels
Craig Matsuura wrote:
Hi Niels,
So from what I could tell when using BACKVIDEO, say on fbdev the pan
which is like a page-flip (change location of memory we are display)
would be fastest than the BACKSYSTEM which appears to copy to the
VIdeo Memory.
So you eliminate a DRAM Write --> DRAM READ --> VRAM WRITE
(BACKSYSTEM) vs VRAM Write (offscreen) --> flip (address change for
video memory) to visible screen (BACKVIDEO).
In the case of a SOC with video built in the DRAM is the VRAM in the
above example. So I assume the BACKVIDEO is faster.
I wanted to be clear as I have a specific application that renders to
the surface pointer an than does a flip. (Unfortunately most of the
rendering is being done ins this software app and it may or may not be
using any drawing primitives in DirectFB.
So an implementation where I can minimize the copy of the offscreen to
visible memory (without using a memcpy) is ideal.
I think your information helps.
Thanks,
Craig
On Wednesday 30 September 2009 7:46:36 am Niels Roest wrote:
> (forwarded to users list only)
>
> Hi Craig,
> just as a clarification to the thread on the dev-list.
>
> The general explanation is as follows.
> A layer, if you want to display it, must at least have one buffer in
> video memory.
> FRONTONLY has 1 buffer in video memory.
> BACKVIDEO has 2 buffers in video memory.
> BACKSYSTEM has 1 buffer in video and 1 buffer in system memory.
>
> a buffer is an area of memory as big as the layer.
>
> "video memory" and "system memory" are concepts which are not fixed in
> their implementation; in general, "video memory" relates to the RAM on
> your video card, and "system memory" to the DRAM on your motherboard.
> However, for e.g. unified memory architectures (such as are often seen
> in embedded systems) there is no need for a difference, although some
> implementations might do it anyway, e.g. for memory bookkeeping.
>
> If you have a unified memory architecture, there is no performance
> distinction between BACKVIDEO and BACKSYSTEM. If you have to perform a
> lot of software operations (such as software blending) before calling
> Flip(), BACKSYSTEM might be best, while if you normally perform
> accelerated operations BACKVIDEO will be the better choice.
>
> The explanation that you give below, is the way that the dfb-system
> implements the above rules.
>
> hth,
> Niels
>
> Craig Matsuura wrote:
> > I want to get some clarification on the BACKSYSTEM, BACKVIDEO and
> > FRONTONLY.
> >
> >
> > Here is my understanding:
> >
> >
> > BACKSYSTEM uses a virtual framebuffer of the screen (Some place in
> > RAM) and DirectFB draws on this screen (surface), once a Flip is
> > called the virtual framebuffer is copied to the Real/Visible
framebuffer.
> >
> >
> > BACKVIDEO use the off screen video memory and draws in the screen
> > (surface) that is off screen. When a Flip is called the framebuffer
> > starting position is changed to the off screen position to make the
> > screen visible. The next frame is draw on the off screen and the
> > process is repeated.
> >
> >
> > FRONTONLY, draw directly to the visible framebuffer.
> >
> >
> >
> > Thanks,
> > Craig
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> >
> > Craig Matsuura - Principal Engineer
> > Control4
> > 11734 South Election Road - Suite 200
> > Salt Lake City, UT 84020-6432
> > PH: 801-523-3161
> > FX: 801-523-3199
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > directfb-dev mailing list
> > [email protected]
> > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
------------------------------------------------------------------------
Craig Matsuura - Principal Engineer
Control4
11734 South Election Road - Suite 200
Salt Lake City, UT 84020-6432
PH: 801-523-3161
FX: 801-523-3199
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
