DFB 1.6.1. I am running into an interesting layer release issue that also involves the window manager. In my application, it appears that when my layer is released it releases the second context, but not the first. When the first context is activated, it activates the window manager and creates a surface. It seems strange that after the layer has been released a context still exists with a full surface.
Here is the process with more information: 1 - When GetDisplayLayer is called, an initial context for the layer is created and activated. 2 - I need the surface. So, I call IDirectFBDisplayLayer_SetCooperativeLevel and set it to Exclusive. This creates a new context and activates it. So now I have two contexts. 3 - I grab the surface, render, flip, all is good. 4 - I'm now done with the surface and layer and I call release on both. a) When the layer is released, it invokes region_destructor which eventually calls context_destructor. b) context_destructor's job is to release the specified context and activate the next one if it exists. It sees the inactive context and activates it by calling dfb_layer_context_activate. c) While activating the context, it activates the window manager. d) When the window manager activates, it repaints, creating a surface and flipping it. In my systems driver, this reactivates the layer so that the layer isn't destroyed/released. There now exists a ghost/orphaned layer with no interface. e) Call IDirectFB_Release, it hits dfb_core_shutdown and calls fusion_object_pool_destroy( shared->layer_region_pool, core->world ) and this releases the context, but this happens after fusion is stopped and other cleanup gets missed. So after calling IDirectFBLayer_Release, a context is activated that creates an active layer with no way of releasing the final active context. I can't seem to find where the final context is also released when the layer is released. Any ideas on where to go next? Thanks, Bryce -----Original Message----- From: directfb-dev-boun...@directfb.org [mailto:directfb-dev-boun...@directfb.org] On Behalf Of Denis Oliver Kropp Sent: Friday, June 08, 2012 5:36 AM To: directfb-dev@directfb.org Subject: Re: [directfb-dev] Window Manager deferring creation in DFB-1.6-pre On 06/07/12 22:30, Poole, Bryce wrote: > During DirectFBCreate the "default" window manager is instantiated and > initialized. As part of this process, it will create a surface and > flip it onto a layer regardless of whether the app will eventually use > windows or not. This interferes with the operating of other functions and > allocates memory for something that might be used. > > > > So the process that this goes through starts with DirectFBCreate calling > IDirectFB_Construct calling > CoreLayer_GetPrimaryContext/dfb_layer_get_primary_context. > This calls dfb_layer_create_context which creates the window manager stack > (the "default" windows manager is my case) and then calls > dfb_layer_activate_context. > In this function, it calls dfb_layer_context_activate which intern > calls dfb_wm_set_active. This calls the window managers SetActive API. > In this call, the "default" wm will end up activating itself and because > there are no windows, it draws the background. Drawing the background will > instantiate a surface and flip it, which is what I want to avoid until it is > needed later. > > > > In DFB 1.4.9, we modified default.c by adding a dfb_updates_reset in > process_updates() if the dfb_layer_context_get_primary_region returned a > failure which happened when it hadn't been instantiated. However this call is > no longer in 1.6. > > > > So, in DFB 1.6, how do I prevent only the first drawing operation > during the SetActive call until after the user initiates something that > requires the surface to get instantiated and flipped? > > > > For those that are already thinking about "no-init-layers" (a > directfbrc option), that is used later during IDirectFB_InitLayers. It > doesn't affect the window manager. The best way might be to avoid the CoreLayer_GetPrimaryContext() in IDirectFB_Construct. It could be done later when needed. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
