I determined another change was needed as well, in the IDirectFB::CreateSurface
function for the primary single buffered display layer surface to be
automatically flipped (like the IDirectFB::GetDisplayLayer function which
already does this). In the src/idirectfb.c module's IDirectFB_CreateSurface
function for the DFSCL_FULLSCREEN/DFSCL_EXCLUSIVE case block after successfully
calling dfb_layer_region_get_surface add the following:
// Make a single buffered primary display layer visible
// since the IDirectFB::GetDisplayLayer automatic flip
// defect fix prevents flipping when the region is frozen.
if (config.buffermode != DLBM_BACKVIDEO &&
config.buffermode != DLBM_TRIPLE) {
// If a window stack is available, give it the
// opportunity to render the background (optionally
// based on configuration) and flip the display layer
// so it is visible. Otherwise, just directly flip
// the display layer and make it visible.
D_ASSERT( region->context );
if (region->context->stack) {
dfb_windowstack_repaint_all(
region->context->stack );
}
else {
dfb_layer_region_flip_update( region, NULL,
DSFLIP_NONE );
}
}
For this to compile successfully the following include statement needs to be
added:
#include <core/layers_internal.h>
Sorry, for not sending patch files for these (I do not have a pure/clean file
set setup and wanted to provide the solution in a timely manner)!
Regards,
Timothy
-----Original Message-----
From: Strelchun, Timothy
Sent: Friday, September 04, 2009 5:08 PM
To: 'directfb-dev@directfb.org'
Subject: [directfb-dev] Fix developed for layer surface buffer being flipped
too early and related questions
I implemented a fix for DFB 1.2.x (it appears to apply to 1.4.x as well), for
when the directfbrc command no-init-layer[n] is used, to prevent a display
layer surface buffer from being automatically flipped and made visible when the
IDirectFB::GetDisplayLayer function is called.
This behavior occurs when the default display layer buffer mode is
frontonly/backvideo/triple. There is a specific FIXME note related to this
defect in src/core/layer_context.c in dfb_layer_context_set_configuration when
the dfb_windowstack_repaint_all function is called.
As a solution, I have had success by wrapping the window stack repaint call as
follows:
if (context->primary.region &&
!D_FLAGS_IS_SET(
context->primary.region->state,
CLRSF_FROZEN ))
{
dfb_windowstack_repaint_all( stack );
}
As far as I could tell CLRSF_REALIZED appeared to be mutually exclusive with
CLRSF_FROZEN.
Further, I think that most calls to the dfb_windowstack_repaint_all function in
the src/core/windowstack.c module should be similarly wrapped - including
dfb_windowstack_set_background_mode/image/color/color_index and
dfb_windowstack_background_image_listener (probably just for the CSNF_DESTROY
notification). By doing this, when the related display layer background
configuration functions are called prior to an explicit user requested flip (or
GetSurface if buffer mode is frontonly/single), an early flip is NOT performed.
Does this make sense to extend the CLRSF_FROZEN usage here? Would such changes
in windowstack.c break any common usaage models or the intent?
Any other places missing come to mind?
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
