Le mercredi 29 décembre 2010 à 13:41 +0100, Krzysztof Sachanowicz a écrit : > On 12/29/2010 01:20 PM, Lionel Landwerlin wrote: > > Le mercredi 29 décembre 2010 à 12:41 +0100, Krzysztof Sachanowicz a > > écrit : > >> I am using DirectFB 1.4.3 compiled with multiple application core. > >> > >> I have many processes, each can have one or more off-screen surfaces and > >> a compositor, which must have access to these surfaces and does the > >> composition to the primary surface. There is also a dedicated IPC > >> mechanism to pass ints/pointers. > >> > >> I tried creating surfaces with DSCAPS_SHARED as is explained in this post: > >> http://mail.directfb.org/pipermail/directfb-dev/2009-November/005356.html > >> but IDirectFBSurface pointer returned is not created in shared memory. > >> Looking into the sources, it is allocated by DIRECT_ALLOCATE_INTERFACE. > >> However the structure contains a pointer to CoreSurface allocated by > >> dfb_core_create_surface() in shared memory pool. > >> Corresponding part from log: > >> (-) [ NO NAME 2.084] ( 3302) Fusion/Object: == Surface Pool > >> == > >> (-) [ NO NAME 2.085] ( 3302) Fusion/Object: -> added > >> 0x20018400 with ref [0x8] > >> (-) [ NO NAME 2.100] ( 3302) Core/Surface: -> 1920x1080 > >> (-) [ NO NAME 2.102] ( 3302) Core/Surface: -> RGB16 > >> (-) [Main Thread 2.024] ( 3304) Core/SurfBuffer: -> LAYER 0 > >> READ > >> (-) [ NO NAME 2.107] ( 3302) Core/Surface: -> caps > >> 0x00100000 > >> > >> I suspect addresses starting from 0x20000000 are in shared memory. > >> > >> So the question is: How to create a surface in another process > >> referencing given CoreSurface? Or is there any other way to have > >> surfaces accessed by multiple processes? > >> > > > > I don't think it's possible with surfaces. However you can do it with > > windows. Create a Window (with same properties as your buffer, ie single > > buffered, etc...), then get the window ID with the GetID method, and > > pass it to the second process, and finally use GetWindowByResourceID on > > the layer in the second process retrieve the same window. At this point > > you should be able to manipulate the window's buffer on both side. > > When using windows 2 questions arise: > 1. Is there any standard way of having a hidden (off-screen) window? > AFAIK there is no function to show/hide a window.
You can set window's opacity to 0, That's how directfb window managers hide them. Or maybe move the windows outside of the screen's limits (haven't tested that one). > 2. When creating only hidden windows on the same display layer as my > process is doing compositing, is it going to work? I don't know how > directfb renders windows but IMHO it might want to clear the primary > surface or display some background, thus interfering with my drawing. Indeed, it might lead to some strange behaviors... What I could suggest to you, is to have look at SaWMan which is a directfb window manager. Client applications use the standard directfb API, and the compositor uses the SaWMan API which provides control over windows and also features a kind of composition manager. Through the multiapp/fusion api, SaWMan is aware of the windows changes and is able to handle screen composition. However SaWMan has some limitations, because it handles each window change as a new frame to display on the screen. Thus, if you have two windows updating their content at respectively 20 and 25 fps, SaWMan is going to compose screen at 20 + 25 = 45 fps. You can imagine the problem with more windows... If you already have a good compositor which handles that kind of use case, you could probably modify SaWMan or rewrite another window manager which could do the job. At this point you will only need a window per application. > > >> I also looked at another approach, to use CreateWindow and in other > >> process window::GetSurface. I am not sure it will work when actually I > >> have my own window compositing. It seems a bit overcomplicated. > >> > >> Thanks, > >> Krzysztof Sachanowicz _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
