Hi,
"Stephen Perez" <[EMAIL PROTECTED]> writes:
> 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):
we definitely want to allow for window decorations. Our plan was to
allow pluggable window managers in the core since the applications
shouldn't have to deal with window management.
> 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 agree that events from decorations shouldn't be delivered thru the
window's event buffer. I also agree that we should allow decorations
to be of a different pixelformat. This contradicts to my earlier
proposal that talked about using the same surface for the window as
well as for decorations but I was persuaded that it makes a lot of
sense to have ARGB decorations around an RGB16 window.
The point about your mail that I didn't quite understood is who is
going to draw the decorations. Do you want the let the applications
handle this? Shouldn't this be handled by a window manager that either
runs as a seperate process or as a module in the DirectFB core?
Salut, Sven
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
