Hi Niels, Thanks for the response. Yes in the respect that the entire screen is "dirty" (or damaged) I can see the backsystem is faster. On my system VIDEO and SYSTEM RAM are the same so no speed difference.
If I only update the dirty rectangles, it appears the only way to update any faster is to uses DMA or in my case the DSP to do the copy to the framebuffer. Thanks, Craig On Thursday 01 October 2009 3:20:21 am Niels Roest wrote: > 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 -- 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-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
