Thanks for the info! More thoughts/comments below... >>> In response to what DFB API usage are individual >>> layers intended to be enabled and their surfaces >>> made visible by the driver? I expect not >>> until after an associated surface has been >>> flipped or a video provider playback has been >>> initiated on the associated surface. Correct? >> >> IIRC the layer will get enabled as soon as someone >> does a GetDisplayLayer(). That might not be such a >> good idea since the layer's default config might not >> be what the user wants.
That's how I had previously thought the layer should be enabled and disliked it for that very reason. When looking through the examples and other source, I found several applications which call GetDisplayLayer() for every layer received by the enumerate callback function until the desired one is found via a successful call to the TestConfiguration(). This style of usage implies that calling GetDisplayLayer() should not make the layer visible at all (default settings or otherwise). Currently, I am thinking that for my double/triple buffered layers I will not enable them until FlipRegion() is called on the associated surface, and for those configured as single buffered layers not until UpdateRegion() is called (since Flip() is not used). Does that make sense? Or would it be problematic for some common usage or applications? > True, I was thinking about fixing this several times. What approach did you have in mind? >>> What is the intended DFB API usage to disable and >>> hide a layer that was previously visible (besides >>> changing the opacity to zero if it is supported)? >>> There doesn't appear to by any layer functionality >>> to do this (aside from changing the opacity to zero >>> if it is supported), so the only way that I am >>> aware of doing this is to release the all >>> outstanding references to the layer that were >>> obtained. >> >> Right. If allocating resources and showing the layer >> would be delayed then maybe there should be a way to >> release the resources as well without releasing the >> layer completely. Maybe a new cooperative level >> DLSCL_DISABLED? >> I'm not really sure this would be worth anything >> though (the user could just release the layer). I can imagine that providing that type of approach might be useful if transitioning back-and-forth between two or more layers when configuration is necessary because the defaults are not sufficient. I like the cooperative level approach better than something else I had considered-- adding a new flip "disable" flag since I do not believe that Flip can be called on single buffered layers. > If there is a mixer driver implementation, > IDirectFBScreen::SetMixerConfiguration() could > enable/disable layers independent from layer > contexts. But resources will stay allocated. Based on what I've heard about mixers, I'm not going to support them so this approach is out. :( > If resources would be allocated on GetSurface() > or CreateWindow(), they could be deallocated when > the surface or windows are released. I believe this is another approach you're proposing besides DLSCL_DISABLED (sorry... still trying to spin-up on DFB). It requires a little more user work in the use case I mentioned however. Thanks, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation +1 503-677-4841 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
