Ville Syrjälä wrote: Thanks Ville! I'm just adding some more info.
> 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. Initially after AddRegion() there's always a SetRegion() following. >> Must the area covered by all of a layer's regions be non-overlapping? > > They can overlap. Usually hardware with regions does not allow overlapping. The driver can check it and return failure. The application would get an error from IDirectFBWindow::MoveTo() or others. In the worst case windows are not even allowed to be side by side, i.e. max. one window per horizontal line. >> 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. There's one thing that should be managed automatically, but has not been implemented in DirectFB. Windows usually require only one buffer as it is offscreen anyhow, because the window manager blits it to the layer buffer for updates (Flip). With DLBM_WINDOWS these single buffer surfaces are onscreen and can cause flickering when graphics are updated. The application currently needs to know about DLBM_WINDOWS and use DWCAPS_DOUBLEBUFFER for all windows to have the Flip feature again. >> 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. True, I was thinking about fixing this several times. >> 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). If there is a mixer driver implementation, IDirectFBScreen::SetMixerConfiguration() could enable/disable layers independent from layer contexts. But resources will stay allocated. If resources would be allocated on GetSurface() or CreateWindow(), they could be deallocated when the surface or windows are released. >> 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. Yes, it's quite close to the hardware. Some mixers support selection of individual layers (DSMT_SUB_LAYERS), some only support extraction at a specific blending stage (DSMT_SUB_LEVEL), e.g. don't show graphics on secondary mixer for VCR. >> 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. True :( But it's quite trivial. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
