Denis Oliver Kropp wrote:
> Daniel Laird wrote:
>>> 1) Find out why the background is cleared at all, because
>>>     layers != PRIMARY should have no background color set,
>>>     or maybe it's black. The background mode for these layers
>>>     should be DLBM_DONTCARE to solve the issue.
>>>
>>> 2) Not create a window stack when the layer has a certain
>>>     capability, maybe add DLCAPS_NOWINDOWSTACK.
>>>
>>> 3) Allocate a dummy line of pixels in your surface pool and
>>>     keep the pitch at 0 :-)
>>>
>> Option 3 is probably the best but not the cleanest.  I had a quick go with
>> option 2.
> 
> Option 3 is at least the one with the least impact or risks.
> 
>> I modified  dfb_layer_context_init in layer_context.c.
>> I added 
>>      /* Create the window stack if the layer supports it. */
>>      if (!D_FLAGS_IS_SET( shared->description.caps, DLCAPS_NOWINDOWSTACK ))
>>      {
>>          context->stack = dfb_windowstack_create( context );
>>          if (!context->stack) {
>>              dfb_layer_context_unref( context );
>>              return D_OOSHM();
>>          }
>>
>>          /* Tell the window stack about its size. */
>>          dfb_windowstack_resize( context->stack,
>>                                  context->config.width,
>>                                  context->config.height );
>>      }
>> This seemed to do the job rather nicely.  Can you see any drawbacks? know of
>> any hidden issues I might encounter. 
> 
> 
> The issues could be wherever context->stack is assumed to be non-NULL,
> which should cause failing assertions, but some sites might just cause
> a segmentation fault.
> 
> So option 1 would be quite clean and somewhat safe, but at any time a
> user might request to create a window or render to the layer surface
> directly...
> 
> I think I'd go for Option 1+3 which avoids filling the dummy line
> multiple (height) times, but still has a fallback in case there's
> another access.

Ideally, option 2 would be the best, of course, but it also requires
the biggest effort and caution :-)

Denis

_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to