OSNews

Its news since it can be done with the GTk engine.

I've already used GTK engines that provided at least transparent window titlebars. So I assumed this was already supported in general.

Perhaps that sort of transparency was simply from transparency in the image used for the title bar.

The window title bar is metacity and compiz replaces metacity to do the effects, again it's different.

compiz has nothing to do with GTK, it's a window manager, it's GTK that does the transparency in this case and alot of people want it for pure eyecandy sake.

Many people said for years it couldn't be done or would take a rewrite or something to that effect, they were wrong.

Edited 2007-12-13 19:23

Well it's different from simply controlling the transparency of a whole window: now transparency can be on various elements of a GTK app. See for example the terminals in the second screenshot: the background is translucent, but the text isn't. I certainly can't do that on my compiz here.

It can be done, and is being done. Most modern terminals support real transparent background in a compositing environment. I've had it for years.

Well, gnome-terminal atleast does support real translucent background if you are running a compositing manager such as Compiz-fusion. But you're right, this is not about window translucency, it's about the translucency being applied to single widgets such as buttons, images, scrollbars or whatever the author of the theme wants.

you can if you use gnome-terminal, but that's what he meant by a hack.

Wrong. Just set the pango markup.

Here's an example in python:

import gtk

win = gtk.Window()
lbl = gtk.Label()
lbl.set_markup("Hello to <small>small</small> and <big>big</big> textn" +
"You can even &lt;b&gt;bold&lt;/b&gt; if you want" )
win.add(lbl)
win.show_all()
gtk.main()

Edited 2007-12-13 19:50

You sound like a GTK troll!

This is simply not true. There are seven different "size" values ranging from xx-small to xx-large, which are all defined relative to the user's chosen desktop font size.



Entirely possible in GTK, and no more difficult than (for example) specifying the use of bold text. I don't know why it isn't used more by application developers, but it's not because the toolkit doesn't support it.

Edited 2007-12-13 23:43

I'm sorry for providing wrong facts in my comment. Thanks for your clarification!

Qt has been doing this for years.

They have? Where can I get a KDE/QT theme that does this?

Plasma is going to use it in places. See Aaron Seigo's blog for details. Apparently GTK has some kind of bug in their implementation.

His blog is http://aseigo.blogspot.com/

The relevant posts are:

http://aseigo.blogspot.com/2007/12/argb-visuals.html
http://aseigo.blogspot.com/2007/12/argb-updates.html
http://aseigo.blogspot.com/2007/12/busy-day-doing-apparently-nothin...

Not answering the question is it, someone said Qt has been doing this for years, where are the themes that can do this in KDE3?

Ah. Guess we'll have to wait for KDE4 then.

I don't really see how this has got anything to do with Qt, but still....

I'll call you. Post a link to a screenshot from 2-3 years ago of KDE3 doing toolkit level transparency (and note that this is not the same thing has window manager level transparency, which is quite different). A transparent button in the middle of an opaque window, or vice-versa, would suffice.

Either do that, or leave the discussion to grown-ups who actually know what they're talking about, okay?

Why do you think GTK+ uses CPU for alpha? It's the compositing manager which does handle drawing the stuff on the screen and they do indeed use GPU for that. GTK+ just properly sets the alpha mask and voila, GPU draws it as it should. Learn a little before you start making such stupid claims.

That definitely depends on how you compiled GTK+ and the theme in question and which version of GTK+ you are using not to mention the version of Cairo, Pango and whatnot.

GTK+ on my machine supports 3D hardware acceleration through Cairo.

That however does not mean that GTK+ on your machine is compiled with support for Cairo or that Cairo is compiled with support for hardware acceleration (OpenGL).

GTK+ on my machine supports 3D hardware acceleration through Cairo.

Mmmno. As much as I personally like GTK+ and Cairo I just have to correct you here: GTK+ devs have not seen it necessary to make Cairo use Glitz for rendering. As such, Cairo (when used by GTK+) does use software rendering. Even if Cairo is indeed compiled with Glitz support it still isn't used unless specified by the application/library utilizing Cairo.

Now what I would find interesting would be a benchmark between normal GTK+ vs. patched GTK+ with Glitz enabled.

True, it requires a composite manager to work. They need cairo compiled with glitz to work, as it is. But without a composite manager it is just waste of good memory and harddisk space.

EDIT: And would a certain person please stop with his consistent down-modding of all my posts? (Not directed at Werecatf) -

Edited 2007-12-15 14:13 UTC

What a blatant liar. It's obvious that since GTK by itself is slow, GTK with alpha blending won't suddenly get faster.

Now I got curious..Where do you get the idea that GTK+ is slow? Cos it can't be as slow as you claim..Why? Well, it's used on a lot of handheld devices which just simply can't sport a high-end CPU. And it's used on several embedded devices too. So, care to elaborate?

And secondly, when GTK+ uses true alpha-blending it will be a lot faster than doing semi-transparency in software. In theory it could just speed up apps which have been doing alpha-blending for their widgets in software. And in practice it most likely would run just as fast as before.

Your link mentions a *file I/O* performance issue, not a graphics performance issues. Do you even know what you're talking about?

1. If it's already slow in one department, that's not a good reason to make it slow in another department.
2. Do you really think that a naïvely coded directory examination replacement is 120 times faster than GTKs? No, the thing that makes the slowdown is surely the GTK treeview. Those things are slow, and it's got to do with how drawing is handled.

And what makes GTK slow isn't the simple things like that, but drawing and other stuff.
A real world example can be seen here: http://www.purebasic.fr/english/viewtopic.php?t=29336

I'm sorry, I couldn't help but laugh out loud! xD That's about GTK+ file operation speeds! It has nothing to do with graphics performance :3 Sure, GTK+ may not handle tens of thousands of files very efficiently but I imagine they're atleast trying to fix that sometime. But that is really a bit off-topic since you were complaining about rendering speeds and this article too is about graphics.

Now I got curious..Where do you get the idea that GTK+ is slow? Cos it can't be as slow as you claim..Why?

I'm afraid anyone who has used GTK and Gnome applications long enough knows this. Redrawing is an obvious shortcoming. You also haven't been reading many of Frederico Mena-Quintero's blog entries on tracking down why this might be. Some of the stuff he's been able to find, and managed to do something about, is pretty amazing work. It's very complex stuff though, since it isn't just GTK. A lot has to do with Pango, and various other components and bits of code.

Edited 2007-12-13 23:41

Uhm my old Athlon 1.4 Ghz ran GTK just fine without any slowdowns. Where did you get the idea that GTK will be slow on today's dual core CPUs?

I don't think that'll happen so no worries. Atleast if the author of the application is smart he/she will make sure any widgets with text are _not_ transparent and only those widgets which really need transparency will gain that.

Well Pidgin(GTK ported app) in Windows has a option for transparency, so in theory yes.

I'm pretty sure that's different. That's using whole window transparency which was introduced in W2k.

Does GTK+ provide transparency for widgets in X11, OS X and XP/Vista?

Recent versions of GTK added an "opacity" property to widgets, to allow them to specify how see-through they are (1.0=solid, 0.0=invisible). This is the same on all platforms.

Whether the opacity request is respected or not is up to the renderer, or "theme engine" in GTK-speak. What we've got here is the first X11 theme engine that obeys the opacity requests.

The theme engine for GTK on Windows uses GDI+. I don't know whether GDI allows individual widgets to set their transparency, but if it does then in principal there's no reason why the theme engine couldn't be updated. (More interesting would be an entirely new theme engine based on Windows.Forms... anyone from Novell want to set the cat amongst the pigeons on this one?)

GTK on OS X uses Quartz, which is certainly capable of transparency, but there are some rather higher-priority things they need to get working first I think.

Sorry, you're wrong. As it is stated very clearly in the blog entry you need a compositing manager which draws transparencies. If you aren't running one you don't get transparency even if you try to specify your widgets completely transparent. Besides, for example drawing a PNG with alpha mask in a image widget would still not result in the background showing through unless the app copied an image of the background and blended it with the PNG or unless you had a compositing manager running and widget/window masks and params correctly set.

Just believe me, it is real transparency.

Thanks, I stand partly corrected. I missed the sentence "The translucency effects obviously require a compositing window manager, ..." when I read the text, but I was not entirely wrong, in the sense that if you don't use compiz or another compositing window manager you wouldn't have real transparency. And then it continues "but the theme engine is designed so that the widgets will simply be rendered without transparency when no compositing window manager is present." In other words, that when you would get fake transparency, transparency isn't used. But my post was essentially correct in the sense that RGBA by itself does not provide real transparency.

Thanks again for your corrections.

Well you need something to composite the alpha channel on. X doesn't do this by default and this stuff has to be done in a buffer anyway, unless you want to see windows being composited in front of you as you work. I'm not sure if you know aht RGBA is or not, its not a thin exactly its just a way to describe the alpha channel (hence the A for alpha). RGBA support in gtk+ or any other toolkit, os, etc. always means the final image has to be composited in-order to get true alpha-blending, this can be done 2d through the cpu (though its slow) or through hardware. Compiz uses opengl to do the compositing and thus leverages the power of already built-in support for alpha-blending. The technique whether its OSX or Vista still requires that the windows be buffered and copied off to memory somewhere so that they can be displayed later so regardless of how you look at it a compositing manager is still necessary to do it at reasonable speeds and interactively.

As for how the widgets will be rendered without compositing enabled, my guess is that if there is no compositing manager the engine will only use the color and ignore the alpha entirely, I don't think they'll use that wallpaper hack at all. In other words they will use only the RGB components and ignore the A.

You are wrong. RGBA is basically is two components color and alpha. Compiz by default already supports compositing, gtk+ already has support for RGBA but it hasn't been used extensively until now, but it has been used before for example gnome-terminal uses rgba so that when you use a composting manager it actually use the alpha component as a way to define transparency, this is true transparency you will see eveything under it not just the wallpaper which is a hack that was used before/

In the past transparency was done that wa but this transparency is done by the x-server specifically x.org.

I thought the same thing about Vista and .Net, but hey

I think cairo would be sped up considerably if they used the opengl backend to accelerate it liek they planned. If you use gtk on X I think it uses xlib for the rednering backend, but there is no reason why most of this couldn't be offloaded to the compositing manager at some point if it isn;t already being done.

Yeah, well for quite a while it's been the case that SWT is best on Windows and slower on Linux and Mac. That is something probably best left to the SWT people to fix. How about comparing something *other* than Eclipse?

Actually using Cairo speeds up the themes...

Actually using Cairo speeds up the themes...

Not in my experience, and I doubt benchmarks (gtkperf?) show otherwise. I remember how much slower GTK+ suddenly became after the Cairo switch in 2.6. It was slow in the 2.0-2.4 versions, too, but since 2.6, it's been really slow.

Actually using Cairo speeds up the themes...

I cannot see how, since all the GDK routines are generally faster and more mature than their Cairo equivalents. Cairo hasn't caught up here. GDK is just more mature and faster at bilinear filtering, and stuff like transformations and alike.

I've also seen Cairo's software fallbacks turn out to be terrible really. They're certainly not as good as GDK performance-wise, which is probably why people are talking about doing what they can through GDK now.

There's not really a whole lot of incentive for themes to move wholesale to Cairo, which takes new code, time and effort and may well turn out to not be worth it performance-wise.

100% agreed. GTK+ is painfully slow. Yes, it is a modern toolkit with many modern features, but the performance suffers. It is quite OK for simple apps, but as long as the window layout gets more complicated, with tabs, lists, progress bars, spin buttons etc., it gets quite CPU-hungry. Especially the Cairo integration in 2.6 made it really slow. General (re)drawing performance is poor (and has always been poor in GTK+ 2.x) this can be seen in many graphics apps), switching between tabs in dialogs is visibly slow (I can see the individual widgets being drawn to the tab), resizing has always been slow, scrolling in large lists is slow, context menus are slow (more CPU intensive than in other toolkits) etc.



Yes, using these big apps on Linux (as opposed to MS Windows) is painful exactly because the GUI runs like molasses.

Then in that case, you'll be fine sticking with KDE 3 and it's badly-rendered shutdown dragon. Some of us, however, appreciate these gestures towards the realm of decent design.

So I guess it doesn't count that KDE integrated compositing support for kwin a long while back? Or is it because KDE could only support compositing effects like shadows and transparency, while transparent widgets somehow magically become more effective for UI design?

Who's kidding who, it's bling, nothing more. Just because it's GTK doesn't make it more or less UI effective than KDE/Qt. It's a tool to be used or abused as the devs see fit.

Besides, if you enjoy it, just be grateful for the KDE4 screenshots floating around the interweb, because that's likely what inspired those ten lines of code to be added to enable it in the first place...

Actually, I rather feel that the Murrine author has never taken any design tips from the KDE guys (thankfully), the word Murrine actually means a form of glass-work, so the idea of creating translucent windows will have beem much more influenced by the Aero glass effect than KDE.

Who's kidding who, it's bling, nothing more.

Any form of design above basic functional implementation could be called bling, yet people APPRECIATE this stuff, and (surprisingly, for people like you, I'm sure) hardware and software with good graphical design makes people more productive, and helps them produce better quality products.

Actually I find transparency to be quite a useful feature (if for example you were waiting for something to complete in a shell). It all depends on how you use your desktop. Windows users don't get the concept of virtual desktops but that doesn't mean that they aren't useful. Just because you don't think transparency is useful doesn't mean that the rest of feel the same way. Speak for yourself and leave the rest of us to decide for ourselves. BTW - Apple does NOT invent everything - they just like to claim that they do.

Becuase we are living in the Real World (tm). Technologies get named after the people who make them successfull.

If I say:
Hey, I'm listening to my iPod while travelling up an escalator, on my way to buy a hoover.

a lot more people will understand me than if I say:
Hey, I'm listening to my PMP, while travelling up a motorized staircase, on my way to buy a vacuum cleaner.

If you start talking about patched-windows-95-style transparency, noone will understand you.
If you talk about windows-2000-style transparency, then the geeks will think of whole-window transparency, and fading-in/out windows.
Only Aero-like transparency will create the instant recognition in people's minds that will allow them to correctly identify what you are talking about.

It's not a vacuum cleaner. It's a dustsucker!

So the word "Vista" has entered our lexicon as being synonymous with "all things computerized and graphical"? Was there a memo that I missed? Is this Steve Ballmer that I'm responding to?

In fact, I distinctly remember the last time I saw rendered water on a PS3, the sentence "Wow, look at that great Vista!" or "Check out that Aero!" was never uttered by anyone in the room.

You're right about things like "Xerox"-ing, and people still referring to PCs as "IBM"s; but I dare you to find ONE single thing that Vista has done, that makes the public use the term ubiquitously, as in calling every "PMP" an iPod.