On Fri, Aug 31, 2007 at 08:11:30AM -0700, Strelchun, Timothy wrote: > Hello, > > I have been studying the DFB API and examining the source code to try > and determine what layer functionality to implement in a driver that we > are going to develop for some CE hardware. I am uncertain about the > intent of the ability for layers to support regions and have some > questions about them and related topics. > > What does it mean for a layer if it supports one region vs. multiple > regions?
1 region = no hardware windows n regions = hardware windows > How are regions (not clip regions) intended to be used and hardware > accelerated? Both by the DFB API user and in the driver. The driver will need to implement the region related display layer funcs. - AddRegion() will be called when the window is first displayed - TestRegion() and SetRegion() are called when the configuration changes eg. the window is moved or resized. - RemoveRegion() will be called when the window is destroyed. > What impact does the driver having layer support for regions have on the > DFB API user? Maybe some if the hardware has limitations. I've never actually used hw which supports hw windows so I haven't studied this part of the code so much. > Must the area covered by all of a layer's regions be non-overlapping? They can overlap. > Regarding support for windows, is their usage related to the region > support provided by a layer? Yes, as I've hopefully explained above. > What does it mean for the usage of a layer if a driver has a layer that > supports windows (cap bit DLCAPS_WINDOWS is set)? That buffer mode > DLBM_WINDOWS can be used? Anything else? Nothing. > Likewise if the layer does not support windows (the cap bit > DLCAPS_WINDOWS is not set)? That buffer mode DLBM_WINDOWS cannot be > used? Right. > Can the IDirectFBDisplayLayer::CreateWindow function still be > used Yes. > (the windows are then just not-accelerated)? Anything else? They can be accelerated in the sense that the blit operations needed to compose the final image are accelerated. That is a job of the window manager module. With hardware windows the compositing part is completely handled by the hardware so the wm doesn't need to do so much. It should also be more efficient since less data has to be copied around. > 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. > 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). > Regarding layer IDs, it appears the DFB API user receives sequential > layer IDs (literally 0 - 31) in the DFBDisplayLayerCallback function and > uses those in IDirectFB::GetDisplayLayer. And then when dealing with > mixers structure, the user convert to/from them using the > DFB_DISPLAYLAYER_IDS_* macros. Is this correct? It seems the macros are there just to manipulate the bitmasks in the mixer description and config. > I am also curious about screen mixers and what functionality they are > intended to allow the DFB API user (when supported) to perform/configure > on a screen. It seems like they might allow the ability to > define/override what layers are exposed by the screen when layers are > enumerated (maybe thus controlling what ones will potentially be > blended/composited if they're eventually enabled or made visible), but I > am not sure and need more info about them. What's the intent of this > functionality? Full-mode layers vs. sub-mode layers? I suppose the idea is to model some hardware features closely to allow the software to control them. > What does it mean > for the driver that supports them? Maybe this topic should be another > thread. :) Unfortunately the open drivers don't really exercise the mixer/output/screen APIs so there are no good examples on this stuff. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
