[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    True window-level transparency and KDE 3 api
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2001-11-02 7:32:03
[Download RAW message or body]

Dear list,

Firstly, I apologise that this is so close to the feature freeze, but I
have only just completed my (unrelated) thesis and didn't want to get too 
distracted beforehand.

I have been reading up on X windows recently with the intent of trying to 
implement a true window-level translucency extension into XFree86.  This 
would properly enable things such as (hardware-accelerated) translucent 
menus, translucent dialog boxes, translucent terminals, translucent
kicker, translucent noatun skins, translucent popups, and of course
drop-shadows on windows and menus.

Before anyone gets their hopes up, no code is written yet.  The reason I
am writing this is because I think there is a reasonable expectation that
such an extension to X will arrive on users' desktops during the lifespan of
kde 3.x, and am wondering if forward-thinking KDE API changes should be made
now. Keith Packard recently mentioned that he expected he would have a sample 
implementation ready in about six months' time, so even if I find this is 
beyond my abilities it should still happen.  This would put early 
installations on users' desktops in the 9 - 12 month range, about kde 3.2 
time? (I hope that this is a pessimistic approximation).  By this time,
32Mb graphics cards should be very common, and 64Mb should be even starting to 
gain an appreciable installed user base.  The video memory size is
important to an efficient hardware accellerated implementation.

As to what API changes are needed, many of the effects would be handled 
internally by kwin.  I would expect apps might like to know if eg. their 
menus / dialog boxes are being rendered translucently, and have the option
to disable this.  For efficiency and speed (especially if software rendering
is required), the translucent window extension might call for windows to
provide hints as to how often they are likely to update themselves.

Additionally, it seems like a good idea to have a standard way of making 
parts of windows translucent, rather than people haphazardly writing their 
own implementations.  The protocol will likely call for apps to either
draw in ARGB or to supply an external alpha channel, using a clip list and an
8bpp Xrender drawable.  Additionally, an input mask will also be needed.  A
call could be made to retrieve the alpha mask as a QPainter or similar.

Another api change which may become relevant over kde 3's lifetime is ARGB
mouse cursors, although I haven't read anything about this.  An
appropriate API could be created that falls back to the default bitmap implementation
for now.

I would like to hear your thoughts on this.

For those who want to read more on this topic, follow these links:

http://www.xfree86.org/~keithp/talks/KeithPackardAls2000/index.html
http://www.xfree86.org/pipermail/render/2001-October/thread.html

Cheers,

Hamish Rodda

[prev in list] [next in list] [prev in thread] [next in thread]