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
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
