Paul Eipper wrote:
2009/2/23 Niels Roest <[email protected]>:
Hi Paul.
For moving:
you can use lite_set_window_bounds(), which will do MoveTo if width/height
are unchanged.
In principle, need to call DirectFB-functions is a hole in the LiTE API.
For performance:
every LiTE window has a back buffer, so if you move the window, it will not
generate a 'client redraw'.
However, DirectFB does not do a bitblt internally on the display layer, but
requests a new copy of this back buffer to the display layer. This avoids
complex updates when you e.g. move a covered window. The update speed
depends a bit on how this copying is done, depending on your system this
might be hardware or software, and again depending, you might avoid this by
changing the memory allocation scheme (e.g. increase the video buffer size,
if available).
Running with verbose-fallbacks, I get these kind of debug messages
when moving a window:
dfb_gfxcard_blit: no hardware accel (5,23-300x100 -> 458,476), using
software fallback:
source: flags/policy/storage/health (system/video): 02/02/00/01/00
destin: 02/03/01/00/01
format src/dst: 'ARGB8565'/'RGB24'
draw/blit: 00000000/00000000 blend src/dst:
5(DSBF_SRCALPHA)/6(DSBF_INVSRCALPHA)
If I set the pixelformat to RGB24, I get a more acceptable
performance, since then it does not fallback, but there is still some
flickering and fallback when drawing fonts (A8 format).
Ok yeah, supported configurations depend on your graphics acceleration
driver; you may need to experiment a bit if this hasn't been properly
documented.
Also, flipping seems to be using DLBM_BACKSYSTEM and not backvideo:
Normally, this should happen when you have double buffered layers (the
default) and defined something like "backsystem" in your directfbrc, or
if you havn't got enough video memory, but that seems a bit odd. You may
want to check the output of "dfbdump" in a running system to check the
memory allocations, do "-h" to get the options.
Core/Layers: dfb_layer_region_flip_update( 0x43d9d8, 0x43d7f0,
0x00000002 ) <- [142, 142 - 315x141]
Core/Layers: -> Going to copy portion...
Core/Layers: -> Waiting for pending writes...
Core/Layers: -> Copying content from back to front buffer...
That looks good, on first sight;
partial updates are always 'copied'. This might be implemented with a
DMA copy.
Which, looking at your screen size, would be advantageous..
I am running with 25mb of video memory allocated, on 1920x1080-60i
screen resolution.
hth,
Niels
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
LiTE mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/lite
