Hi,
Sorry to come to this discussion so late, but I'm not getting a lot of time
to keep up at the moment.
In short, I would like the option to have expose events (possibly with the
option to cache window contents to a surface for machines with the
resources for it).
In message <[EMAIL PROTECTED]>
Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> Quoting Ian Walters:
> > On Friday 09 January 2004 12:37 pm, Ville Syrj�l� wrote:
> > > On Thu, Jan 08, 2004 at 10:09:09PM +0100, micronuke wrote:
> > > > Hello,
> > > >
> > > > is it possible to create an IDirectFBWindow without a surface? [...]
> > > >
> > > > This may sound strange.. thus I'll explain. Every DirectFB-window has a
> > > > surface attached to it.. When you have many windows, this can easily need
> > > > a lot of memory. If I have a window that doesn't have focus and doesn't
> > > > need to be updated until it gets focus again I could blit it onto the
> > > > primary surface, remove its surface (and thus free the memory) and later
> > > > when a focus event arrives recreate and redraw the surface (if I remove
> > > > the complete IDirectFBWindow there won't be any more focus events ;).
> > >
> > > You need the surface for window stack updates. DirectFB doesn't have
> > > expose events like X.
Yes, without using surfaces, the application needs to be told when its bit
of the screen needs to be redrawn due to a window being moved away, or which
parts of its window are visible when it wants to update it.
As I understand it, when a (rectangular) area of the screen changes, a
traditional window manager needs to identify a set of affected
non-overlapping rectangles on the screen belonging to various windows and
tell the windows to redraw themselves. With the added complication of
alpha-blended windows, each screen rectangle can "belong to" (be affected by
the contents of) multiple windows: a lowest level opaque window (possibly
the background) and zero or more translucent windows above it in the window
stack. This would mean that the expose events would have to be sent to each
window from bottom to top, in turn. (Applications using windows with
surfaces would presumably never see the event, the blit from their surface
to the screen memory being done by the library.)
[snip]
> Of course, each window only consumes memory for its own size.
>
> The surface manager will swap out "hidden" windows if the video memory is full.
> The system memory instance will be swapped out by the kernel.
>
> While the kernel swaps out page wise, DirectFB only swaps out complete surfaces.
So a window that is 99% invisible will still have its whole memory in video
memory, right?
[snip]
> > It would be
> > very hard to generically ask apps if they may update graphics in the next 20
> > seconds.
I don't understand, why do you think this would be needed? Any application
may update its graphics at any time due to some event known to it (like a
mouse event, a timeout, new data on a socket or inter-process communication,
for example).
[snip]
> Especially with alpha blended windows the clipping approach (traditional)
> is not applicable.
I think it's not impossible, though.
I haven't looked to see how the screen drawing is done at the moment; is it
just "blit each window to the screen memory starting with the deepest
first"? Is there even a "screen memory" to blit to? (Around 1990 Intel
produced a display chip that could be programmed to take regions of the
display from anywhere in memory at different numbers of bits per pixel,
etc., without an intermediate screen buffer.)
> > Also this sounds more like a user problem. If I have 20 windows open and my
> > machine starts running out of memory I have 3 options
> >
> > a) buy more memory
> > b) close some windows
> > c) turn window oppacity 100%. Sooner or later the lower windows will be
> > swapped out if the apps are not updating graphics and the DFB doesn't need to
> > read them (assuming large areas of the screen is 100% accounted for before it
> > gets to that layer).
> > d) accept that 20x2048x1024x4 (20 windows, resolution, bytes per pixel?, I am
> > guessing) is still only 160meg, and some video cards have more memory than
> > that these days.
e) use a system that doesn't run out of memory or even slow down with 20 (or
200) windows open.
I don't think you can reasonably say "only 160MB" just yet! Maybe in five
years time.
Please bear in mind that not all machines have large amounts of video RAM,
(some don't have any more than is needed to display the screen) and not all
applications will have a majority of alpha-blended windows (in fact, in a
traditional desktop environment, I'd say alpha-blended windows are more of a
hinderance than a help, otherwise everybody would print on tracing paper
instead of the normal opaque stuff). Can you tell me any other use for
alpha-blending than overlaying text over movies, and displaying menus?
> > Still, an interesting thread.... look forward to seeing how it turns out.
>
> True ;)
I'm developing a window manager that duplicates the look and feel of another
OS's GUI. I was hoping that it would work acceptably on older hardware, as
the original OS does admirably.
At the moment (it's early stages yet), I allocate two DirectFB windows for
each application window, so that I can draw the furniture in the larger one
and limit application drawing to the smaller window and also get ENTER and
LEAVE events to pass to the applications more or less for free. Does this
mean I'm invisibly allocating memory for the client area twice? I don't
really want to be forced to allocate memory for it at all!
Regards,
Simon
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
