You do have to convert to ARGB because of X servers, mostly because graphics cards use it. If you really wanna delve into performance-efficiency of both pixel formats then lets just say that since almost all image file formats are RGBA it’s of course faster to just render everything else too in RGBA. I haven’t looked at anything like this, or anything remotely graphical for ages, but that’s the way it was the last I looked. Even if you only have two colours going on, gdk-pixbuf seems to use 24 bits for each each pixel regardless. Well, within GDK we’re talking here, the problem is that they are stored in true colour. Hmm, this caught my eye.Why would RGBA be any more inefficient than ARGB or use more memory? And nasty hacks? Converting ARGB RGBA is just a matter of shifting a few bits (the amount if bits depends but on a 32-bit display depth it’d be 8 bits per component). - If you really wanna delve into performance-efficiency of both pixel formats then lets just say that since almost all image file formats are RGBA it’s of course faster to just render everything else too in RGBA. And yes, X server does support both RGBA and ARGB. Hmm, this caught my eye.Why would RGBA be any more inefficient than ARGB or use more memory? It can’t be just simply because it’s just the same thing.It uses exactly the same amount of memory and all. It’s just a sad show-off, that doesn’t mean all that much, just to keep the ‘bling’ crowd interested. Until we see some code for this in GTK and Gnome, it means pretty much nothing. It requires GTK 3, and it can’t be API or ABI compatible.Ĩ. Referring to point 5 and 6, it is impossible to do this within the current context of GTK 2.x. KDE 4 needs a piece of designer software though, but Plasma scripting makes it reasonably possible and just about reachable for most.ħ. To do this on Vista, OS X and KDE 4 all you need to be is a Flash thingy designer really. To do this kind of think in GTK requires a developer well versed in programming this. Hacked widget transparency in every theme is a joke next to these toolkits, and once you scratch away the screenshot, the cracks show.ĮDIT: You need application support as well!Ħ. When KDE 4 gets rolling and starts using Qt 4 more fully, hopefully we will see this on Linux desktops. Next to Quartx and WPF, this is an embarrassment trying to hold this up as some sort of equivalent. This is all just crack painting next to a toolkit that actually does this for you from the ground up. Firefox does weird stuff to put it mildly.ĥ. I can see a lot of application specific issues with this, particularly with GTK using applications like Firefox. You need compositing here, and I think composite checking went into GTK circa 2.8.Ĥ. One approach was to overdraw this pixmap with a background rgba (setting the default colourmap for widgets to rgba), and a future idea was to actually make the background pixmap transparent. The GTK theme engine, I think, generally draws a grey background pixmap and then renders the widget on top. Whether it is done in the same way, I don’t know. In the depths of my mind on some forum somewhere, I can remember some hack being done like this for GTK themes not long ago. This does require nasty hacks, and how this is ‘fast’, I have no idea.ģ. gdk-pixbuf handles both RGB and RGBA, but what people are interested in is ARGB – which most X servers use I believe. This is rather inefficient, both memory and performance-wise. He talks about people thinking that GTK doesn’t have RGBA support, which I find bizarre – or it’s a slip of the keyboard -). GTK themes can only paint into GDK rendering contexts and not Cairo ones, and if you want to, the hacks should make you shudder. What we have are two drawing engines, and GDK is fundamentally incompatible with Cairo – unless themes themselves make use of it, and even then, you’ll have to do some copying and pasting. This is not done through Cairo in one central point (from what he writes anyway). The trouble with this and GTK is that it isn’t really news, although it probably looks like it to most of the uninitiated:ġ. Screenshots are one thing, working is something else. Transparent widgets and all – all done through the paint engine in one place incidentally. However, support for this stuff has been in Qt from the ground up for a couple of years (three years even) ever since Qt4 came into existence, and screenshots of KDE 4 and Qt using it are a penny a dozen. This announcement will not give you that. Well, you can’t go into the Gnome control panel today and enable transparent effects in GTK themes. So I wish people would stop saying “KDE could do this for years” and start showing us how to do it. I have kcontrol open right now and am ready to try it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |