On Wed, May 10, 2006 at 01:00:12PM +0100, Jason BARSTOW wrote: > > > > > I am pursuing my research into directFB - I have some questions: > > Q. Is there any examples of providing DLCAPS_WINDOWS ?
I haven't seen any. I assume they are all closed... > My understanding is that normally dfb will render down all windows' > surfaces to the layer's surface and the gfxdriver will be requested to > present the new page (region). Yes. > What happens if DLCAPS_WINDOWS is set? Any caveats in using hardware > windowing? What happens is the hardware will take care of displaying the windows. I suppose one caveat might be alpha blending (ie. some hardware might not support it). > Q. Currently I am setting DLCAPS_SURFACE and using surfaces for my layer > content. How would I provide my own content to a layer? > i.e. I note this comment: "/* The layer has a surface that can > be drawn to. This may not be provided by layers that display realtime data, > e.g. from an MPEG decoder chip. Playback control may be provided by an > external API. */" > > Specifically, I am considering how I might architect the following using > directFB: > > DirectFB > --> Layer1 (Surface) --> GfxDriver --> Screen > --> Layer2 (Surface) --> GfxDriver --> Screen > --> Layer3 (Surface) --> GfxDriver --> Screen > > In this set up I have a GUI that composites 3 layers. But Layer2 is to > contain a DRM surface. How do I attach my private surface to a layer? > > To achieve this I'd (notionally) like to be able to create a CoreSurface > that represents a private allocation that is not managed by dfb's manager > and that is not valid for software read/writes. If it can't be accessed why does it need a surface? -- 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
