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).
Also, flipping seems to be using DLBM_BACKSYSTEM and not backvideo:
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...
I am running with 25mb of video memory allocated, on 1920x1080-60i
screen resolution.
--
Paul Eipper
_______________________________________________
LiTE mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/lite
