Quoting Stephen Perez ([EMAIL PROTECTED]):
> I need to add something to DFB for a little project I am working on, and I
> wanted you all's opinion (since the features maybe generally beneficial).
>
> I need to be able to add decorations to windows in a fairly flexible manner.
> The idea is to modify the core window object so that it not only has a
> primary surface, but decorative surfaces as well. Somewthing like (psuedo
> code):
>
> DFBRegion r = {0,-20,100,20}; // x,y,w,h
> window->AddDecorativeRegion(r, DSPF_ARGB, MY_DECORE_ID); // r is relative to
> upper left corner of the "window proper"
>
>
> The above code illustrates the basic idea: being able to have arbitrary
> decorative regions with arbtrary pixel formats. For my needs, these
> decorative surface don't even need to have physical backing stores (although
> they could). I was looking more to having a callback that could be
> implemented by the consumer (called by DFB when it updates the window
> stack). When DFB called the callback it would send me a temp surface and the
> id (MY_DECORE_ID) of my decorative region so I could draw into the region.
> It would then take the surface and composite it along with the other window
> surfaces. Also for my purposes, I am going to need to be able to route
> decoration events to seperate event buffers than those that handle the main
> window (window proper, primary window, or whatever you want to call it :).
> I've benchmarked something similar and there doesn't appear to be much of a
> slow down having to call out to the consumers callback. Of course you could
> just turn decorations off, in which case there's no slowdown.
>
> I have read the list archives and I think providing these sort of decoration
> hooks will provide far more power then reparenting or just using four
> standard windows wrapped around a primary to provide decoration.
>
> I would really appreciate some feedback...good?....bad?....hacky (perhaps:)?
I like this "integrated" approach. Having just arbitrary regions added to
a window seems lightweight. But I don't think it's a good idea to call
an application function during the core's window stack update. There are
several reasons why this even wouldn't be possible. At least using the multi
application core the decoration functions cannot be called directly. Whenever
an application moves a window etc. it recomposes the desktop surface using
all window surfaces within the shared memory or video memory. So using backing
stored surfaces as attached regions seems like the best solution so far.
As a long term topic I would like to discuss on a core module that acts as a
highly integrated window manager. Having just a function call to decide if the
application gets the event or the window manager seems better than piping events
to a window manager application that in turn sends the event to the window owner.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
Convergence GmbH
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
