nanogui: Current plans for Microwindows
Subject:
Re: [nanogui] Current plans for Microwindows
From:
Alex Holden ####@####.####
Date:
16 Jul 2002 09:57:56 -0000
Message-Id: <3D33EB1C.9080700@linuxhacker.org>
Greg Haerr wrote:
> : I think it's unlikely that true translucent window background support
> : (the kind of thing Mac OS X is capable of) will be implemented any time
> : soon, if ever, in Nano-X as it is a complex problem to solve and tends
> : to require a lot of memory and processor power (and ideally accelerated
> : video hardware support).
> The bin/malpha demo program implements this, and it isn't
> that big a deal to add it for server support. Yes, it is processor
> intensive, since each pixel must be individually read, blended, and
> then written, and there aren't any hw accelerators for it on x86
> processors.
I don't know about mwin but it certainly would be a "big deal" to add it
to Nano-X. The biggest problem is that we don't store a "clean" copy of
the contents of every window somewhere off-screen, so when something
changes below a translucent window, we don't have all the information
available to reblend it. The situation quickly gets much worse if you
have a stack of translucent windows on top of each other. Sending an
event to each of the translucent windows above something that has
changed to get them to redraw their contents in order wouldn't be
practical at all. It isn't sufficient to simply store a double buffer of
every translucent window, we actually need the contents of every area of
every window which has a translucent window directly above it. The
simple way to do this is to double buffer every window, regardless of
whether there's currently a translucent window over it, but this
obviously is a terrible waste of memory. There are ways to optimise it
so you only store the contents of translucent windows and areas of
non-translucent windows which currently have translucent windows over
them, but keeping the list of buffered areas up to date when windows are
moved around wouldn't be easy. Of course I haven't even mentioned the
non-trivial problem of figuring out which areas of which windows need
reblending when something under them changes yet... Keith Packard's
article goes into the whole thing in detail:
http://www.xfree86.org/~keithp/talks/KeithPackardAls2000/index.html
Note that I'm not saying that it's impossible, just that it would
require a lot of work to do and would significantly increase the code
size when it was enabled, whilst probably not being very usable on
typical low end embedded system hardware without hardware acceleration
of the blending.
--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
