Gnome optimization

[ilia_kr]

Metacity uses xml and is a little slower than the 'boxes' which are usually text.

Interesting is the more code and the bigger the xml file, the slower the metacity theme is. My recent gFlat metacity theme buttons are all code, and the round version with round buttons is twice as slow as the square making it probably one of the slowest metacity themes (in code) ever.....slower than Clearlooks. There's twice the code for the buttons. But I wanted the buttons to scale with the font size so, that's the price I pay. Clearlooks doesn't do that, unfortunately, and I find it strange it is default w/o acessability.

http://www.gnome-look.org/content/show.php?content=40324

 

You know, i decided to play with themes to check whether there are speed difference. I got to the conclusion that some icon themes are faster that the others (I think it has no connection to xml). For instance Clearlooks default icon theme feels faster that VistaInspired (nautilus switches folders faster). Is it possible or is it just wrong feeling?

[iphitus]

That makes sense as metacity has to read twice the options. If we just add an equal amount of whitespace to a theme with half the options, I doubt there would be any difference.

Yes, it has to read twice the options from a xml file, which itself is not efficient. I don't care about whitespace and have said nothing about them.

which would be slightly OT, as that was what this was thread was started about

If I understood a developer (I trust) correctly, metacity does not cache code for rendering, only pixmaps, which is why some (clearlooks for example) choose pixmaps for buttons. While the xml file may be cached, the rendering of the code is not. That's how I understood it anyway.

 

My point is with ilia_kr. Xml is slower than text, and that is a very well known fact. I guess metacity is probably not a good example because of what the xml is used for, and how, but that doesn't change the basics.

http://news.com.com/Putting+XML+in+the+fas..._3-5534249.html

 

what most programs would do, is load up, and parse the XML to it's own objects, instructions or machine understandable version in memory. Once the XML is parsed, it would not be parsed again unless the theme is reloaded or changed. Once it's in this parsed form, all speed comparisons between text and XML are irrelevant, they only effect the parsing speed. It's from this parsed form that the WM processes through the instructions contained, and renders it.

 

It's just simple logic, that a theme that has more rendering instructions, is going to be slower/not as quick to render than a pixmap, which is pre-rendered, it just needs to be drawn from one memory position to another.

 

There's a lot of naysayers out there who dislike XML, and you're goin to find it easy to find articles and blog posts against it. I agree with many to an extent -- it is over used, and is abused, but this does not mean it doesnt have it's purposes. I can't say I like how it's used to provide a theme format for metacity, but I can see very easily how it works and definitely why the GNOME developers chose it. It does work very well, provide an effective and powerful theme description mechanism.

 

Saying 'XML is slower than text', is a naive argument. XML IS text. What format is the text it's being compared to? And how well written is the text parser for that format? Most of the XML parsers out there are pretty reasonably written (sure some arent too), and for the length of a Metacity XML theme file, the parse time would be negligable.

It'd take a very good programmer to write a custom theme language with the capabilities of metacity's XML schema, and be just as efficient. You can see this in action, just click through some themes in gnome-theme-properties, they change quickly, and most of the delay is not parsing, but locating and reading them from the hdd.

 

So XML is not the reason for a slow redraw of a theme which dynamically renders a theme, it's just the simple fact that a computer has to process more instructions to draw the theme rather than blitting an image from a cache to screen. And on more modern computers today you shouldnt notice the difference.

 

James

[bvc]

You know, i decided to play with themes to check whether there are speed difference. I got to the conclusion that some icon themes are faster that the others (I think it has no connection to xml). For instance Clearlooks default icon theme feels faster that VistaInspired (nautilus switches folders faster). Is it possible or is it just wrong feeling?

There's a wide variety of theme speeds depending on what gtk-engine is used. Clearlooks doesn't have an icon theme, so I'm not sure what icon theme you are referring to but if you notice a diff its probably because it's svg and not png. I think (don't have it installed) VistaInspired is png. Gtk and png icon themes do not use xml , but it's another good thing to point out because all an svg icon is, is an xml file ;)

 

Say you can make an 128x128 svg icon that ends up being 36kb in size. Well we only need it to start at 48x48 so we size it down, utilizing common sense, and in hopes of cutting some kb's, but no, the 48x48 svg is still 36kb. It's an xml file that has a line for every drawing operation. Now, imagine an svg icon theme with 2000 icons where in a 2 day boot 1000 are parsed and put in memory. You say, we have to load png's into memory, but a 48x48 png is only 4kb and a 128x128 8kb. Now you know why you notice a diff and why after the slowdown from cairo I can't believe they are considering and svg icon theme as default when for years the concept has been wisely shot down for the above obvious reason.

 

That makes sense as metacity has to read twice the options. If we just add an equal amount of whitespace to a theme with half the options, I doubt there would be any difference.

Yes, it has to read twice the options from a xml file, which itself is not efficient. I don't care about whitespace and have said nothing about them.

which would be slightly OT, as that was what this was thread was started about

anything but OT. It IS what this was thread was started about.

 

Once it's in this parsed form, all speed comparisons between text and XML are irrelevant, they only effect the parsing speed. It's from this parsed form that the WM processes through the instructions contained, and renders it.

 

It's just simple logic, that a theme that has more rendering instructions, is going to be slower/not as quick to render than a pixmap, which is pre-rendered, it just needs to be drawn from one memory position to another.

Thanks for the echo :D

 

Saying 'XML is slower than text', is a naive argument. XML IS text. What format is the text it's being compared to? And how well written is the text parser for that format?

Thats the obvious but the fact is, if another format can be used instead xml, it's faster, but all that means is xml wasn't needed. So it's not niave, it's just fact.

 

So XML is not the reason for a slow redraw of a theme which dynamically renders a theme, it's just the simple fact that a computer has to process more instructions to draw the theme rather than blitting an image from a cache to screen. And on more modern computers today you shouldnt notice the difference.

but you do

[tyme]

So XML is not the reason for a slow redraw of a theme which dynamically renders a theme, it's just the simple fact that a computer has to process more instructions to draw the theme rather than blitting an image from a cache to screen. And on more modern computers today you shouldnt notice the difference.

but you do

I don't :unsure:

 

I've used several window managers - fluxbox, metacity, kwin, and gnome-window-decorator (compiz) and i don't notice a difference in speed (with regard to the WM) - I'm sure if I sat here with a program and clocked it, I would see a few milliseconds of difference...but, I don't care if I don't notice it in every day use.

[iphitus]

There's a wide variety of theme speeds depending on what gtk-engine is used. Clearlooks doesn't have an icon theme, so I'm not sure what icon theme you are referring to but if you notice a diff its probably because it's svg and not png. I think (don't have it installed) VistaInspired is png. Gtk and png icon themes do not use xml , but it's another good thing to point out because all an svg icon is, is an xml file ;)

 

Say you can make an 128x128 svg icon that ends up being 36kb in size. Well we only need it to start at 48x48 so we size it down, utilizing common sense, and in hopes of cutting some kb's, but no, the 48x48 svg is still 36kb. It's an xml file that has a line for every drawing operation. Now, imagine an svg icon theme with 2000 icons where in a 2 day boot 1000 are parsed and put in memory. You say, we have to load png's into memory, but a 48x48 png is only 4kb and a 128x128 8kb. Now you know why you notice a diff and why after the slowdown from cairo I can't believe they are considering and svg icon theme as default when for years the concept has been wisely shot down for the above obvious reason.

 

To be fair, the size of the SVG icon depends on it's complexity. Looking through tango's application icons, 2/3 of them are less than 30kb. When a SVG icon is loaded, it's rendered and rasterised and into forms which would most probably take up less space than the original icon. Some may be cached in SVG form though, I'm not sure on the details. So 36kb is an excessive value to work with, but i will anyway.

 

1000 36kb files arent actually all that much in memory.

>>> 1000*36/1024.0
35.15625

35mb. Affordable on most systems nowadays. And I'd say that's quite an exxaggeration, as find and wc tell me that there arent even 1000 scalable icons in Tango for example. It's scalable directory is only 8mb, which is certainly affordable.

 

So SVG icons really arent unreasonable.

 

As for the cairo slowdown, that depends on what version, and what theme engine you're using. I see no problems here on cairo-devel and ubuntulooks. I'm pretty sure it was just a specific issue with a particular version of cairo. Funny to see you complaining about cairo anyway, i would expect you'd embrace it, as it allows you to do a lot more with GTK.

 

Saying 'XML is slower than text', is a naive argument. XML IS text. What format is the text it's being compared to? And how well written is the text parser for that format?

Thats the obvious but the fact is, if another format can be used instead xml, it's faster, but all that means is xml wasn't needed. So it's not niave, it's just fact.

uh, no, that's making the assumption that everything else is faster than XML. Which is taking the 'i dont like XML' fanboi path.

I'll echo myself now, to write a theme description language as capable as the one used in metacity, in another lang or from scratch, would take a ridiculous amount of work -- and would be terribly difficult to get as efficient.

So... despite the fact that the speed of XML's parsing in use here is negligable because the files in use are so short, XML is probably one of the faster choices they could have made.

 

So XML is not the reason for a slow redraw of a theme which dynamically renders a theme, it's just the simple fact that a computer has to process more instructions to draw the theme rather than blitting an image from a cache to screen. And on more modern computers today you shouldnt notice the difference.

but you do

i'll agree with tyme there.... you dont. but maybe the metacity theme you're looking at is poorly written.

 

James

Edited June 12, 2006 by iphitus

[bvc]

To be fair, the size of the SVG icon depends on it's complexity. Looking through tango's application icons, 2/3 of them are less than 30kb. When a SVG icon is loaded, it's rendered and rasterised and into forms which would most probably take up less space than the original icon. Some may be cached in SVG form though, I'm not sure on the details. So 36kb is an excessive value to work with, but i will anyway.

 

1000 36kb files arent actually all that much in memory.

35mb. Affordable on most systems nowadays. And I'd say that's quite an exxaggeration, as find and wc tell me that there arent even 1000 scalable icons in Tango for example. It's scalable directory is only 8mb, which is certainly affordable.

 

So SVG icons really arent unreasonable.

That's your opinion with your nice shiny new pc but it says nothing for all the complaints. A slow down here, another there...it begins to add up. So much so that a DE that used to be faster than KDE is now slower. So much for reason.

 

 

As for the cairo slowdown, that depends on what version, and what theme engine you're using. I see no problems here on cairo-devel and ubuntulooks. I'm pretty sure it was just a specific issue with a particular version of cairo. Funny to see you complaining about cairo anyway, i would expect you'd embrace it, as it allows you to do a lot more with GTK.

I've always got the latest and I run all the engines, you know that. Cairo offers nothing for themers, but a slow down. Performance test show clearlook-cairo and ubuntulooks, which is also cairo, slower than some pixbuf themes and much slower than traditional engines. After all the hoot'n and haller'n over cairo we still only have 2 cairo themes (engines), both made by the same individual and the second was paid for and is a simple offspring of the first, so???? Why would a themer embrace it? sheesh this is all OT.

 

 

uh, no, that's making the assumption that everything else is faster than XML. Which is taking the 'i dont like XML' fanboi path.

I'll echo myself now, to write a theme description language as capable as the one used in metacity, in another lang or from scratch, would take a ridiculous amount of work -- and would be terribly difficult to get as efficient.

So... despite the fact that the speed of XML's parsing in use here is negligable because the files in use are so short, XML is probably one of the faster choices they could have made.

I never made that assumption at all. I'm just not getting into details that anyone participating in the dicussion should already know, without it needing to be said. I'm not a theme engine writer so I wouldn't know. Would you? :P ...other than the fact that I do know binaries are faster but I wouldn't want that because I don't what to loose flexibility.

 

So XML is not the reason for a slow redraw of a theme which dynamically renders a theme, it's just the simple fact that a computer has to process more instructions to draw the theme rather than blitting an image from a cache to screen. And on more modern computers today you shouldnt notice the difference.

i'll agree with tyme there.... you dont. but maybe the metacity theme you're looking at is poorly written.

 

James

Well, since it is what I do, I can assure you the theme is not poorly written, in fact, in my attempts to speed it up (which I did), I could speed up Clearlooks/Human, Industrial and a few offspring, quite a bit since they are poorly written ;) Of course I could remove the utility code and have improper utility windows like everyone else and speed it up a little, but I think everything should work properly and as designed, else, why bother? Since my sys is not shiny new and is about ...?... almost 2 years old, I do notice, and I'm more the norm and what matters when considering these things ;) Are you implying that linux should adopt the XP/Vista mentality that people should have to upgrade hardware in order to run it? (not an actual question) Edited June 12, 2006 by bvc

[iphitus]

That's your opinion with your nice shiny new pc but it says nothing for all the complaints. A slow down here, another there...it begins to add up. So much so that a DE that used to be faster than KDE is now slower. So much for reason.

it's foolish to not acknowledge and embrace new things, despite the fact they will not run well on older computers.

 

embracing SVG based themes, is not removing support for PNG based themes, and PNG based themes will exist for quite a while. So the option is there, people can choose. If they've got older hardware, then they're free to change it - but we shouldnt restrict ourselves to that.

 

But hey, we should never have embraced PNG in the first place, we should still be using XPM. Change happens mate, it takes time, but it's inevitable.

 

I've always got the latest and I run all the engines, you know that. Cairo offers nothing for themers, but a slow down.

there's a lot more that's shown that can be done in the writing of theme engines that hasnt previously been possible. I look forward to working with cairo and developing a GTK engine later in the year when school is over...

Performance test show clearlook-cairo and ubuntulooks, which is also cairo, slower than some pixbuf themes and much slower than traditional engines. After all the hoot'n and haller'n over cairo we still only have 2 cairo themes (engines), both made by the same individual and the second was paid for and is a simple offspring of the first, so???? Why would a themer embrace it? sheesh this is all OT.

because cairo based theme engines can do more. I'm sure you would have seen all the demonstrative engines put out during gtk+cairo's early days. And i'd like to see these performance tests you speak of.... they sound ... interesting. Because, like others, I've seen none of these slowdowns you speak of.

 

I never made that assumption at all. I'm just not getting into details that anyone participating in the dicussion should already know, without it needing to be said. I'm not a theme engine writer so I wouldn't know. Would you? :P ...other than the fact that I do know binaries are faster but I wouldn't want that because I don't what to loose flexibility.

Again, a binary format for the theme wouldnt cause the window to redraw any faster. It would only make a very negligable change to the initial loading time, and hinder development and distribution by requiring it to be compiled, and depending on implementation, recompiled for different architectures.

 

Well, since it is what I do, I can assure you the theme is not poorly written, in fact, in my attempts to speed it up (which I did), I could speed up Clearlooks/Human, Industrial and a few offspring, quite a bit since they are poorly written ;) Of course I could remove the utility code and have improper utility windows like everyone else and speed it up a little, but I think everything should work properly and as designed, else, why bother? Since my sys is not shiny new and is about ...?... almost 2 years old, I do notice, and I'm more the norm and what matters when considering these things ;) Are you implying that linux should adopt the XP/Vista mentality that people should have to upgrade hardware in order to run it? (not an actual question)

good to see you're working hard on it. Though i'd like to know why clearlooks and industrial are poorly written... those are big words for someone to throw around.

 

I also have an older system which i use frequently, my laptop, so I'm also on the norm, and see no problems right now. Cairo is rendering fine on it, no slower -- and more importantly, not noticeably slower. Maybe if you run some synthetic benchmarks you'll find that cairo will render slightly slowly, but so long as it isnt in the human perceptible range, it simply isnt relevant.

 

anyway, we never see eye to eye, and I'm sure other's can understand what I have said, so I think i'll leave it there...

 

James

Edited June 12, 2006 by iphitus

[arthur]

true, binary would only be faster for code, not for configuration options. my gnome setup (2.14) is running rather slow, but that might be because of XGL and compiz eating up a good % of my CPU. The price of eye candy...

[bvc]

Performance test show clearlook-cairo and ubuntulooks, which is also cairo, slower than some pixbuf themes and much slower than traditional engines. After all the hoot'n and haller'n over cairo we still only have 2 cairo themes (engines), both made by the same individual and the second was paid for and is a simple offspring of the first, so???? Why would a themer embrace it? sheesh this is all OT.

because cairo based theme engines can do more. I'm sure you would have seen all the demonstrative engines put out during gtk+cairo's early days. And i'd like to see these performance tests you speak of.... they sound ... interesting. Because, like others, I've seen none of these slowdowns you speak of.

Cairo engines can do more than traditional engine only themes, but themers do not write engines, developers do. So as a themer, it doesn't interest me a lot because I'm not a developer.

 

Others? You mean tyme? That's one. Funny you argue a point when the devopers themeselves disagree with you. They flat out say cairo engines are slower and it's just the price we'll have to pay for better looking engines. However, if the marginal diff from the pixbuf engine doesn't increase, why bother with an engine when you can make a pixmap theme? Lets not forget the post all over the web of people complaining about slowdowns either. You two are part of an extremely small minority.

 

These are test from gtkperf and twf hacked to spit out timing (twfperf). Check out d3a-eXperience!

###############################
##########	GTK PERF		########
##############################
Simple			(thinice)			10.77
Mist				(mist)			11.00
d3a-eXperience	(experience)		13.73
Slider 			(smooth)			16.40
Rezlooks-Gilouche	(rezlooks)		16.47
Glider			(smooth)			16.54
Clearlooks-cairo	(clearlooks-cairo)	18.86
Human			(ubuntulooks)		19.26
Gentle			(pixbuf)			22.31
eXperience		(experience)		27.41
d3a				(pixbuf)			28.56
E17-Gtk			(pixbuf)			31.79
Ana				(svg>pixbuf)		35.67

#################################
###########	TWF PERF		##########
################################
Mist				(mist)			0.411885s
Simple			(thinice)			0.421149s					
Slider			(smooth)			0.936762s
d3a-eXperience	(experience)		0.591864s				
Rezlooks-Gilouche	(rezlooks)		0.733326s
Glider			(smooth)			0.962215s
Clearlooks-cairo	(clearlooks-cairo)	1.040012s
Human			(ubuntulooks)		1.106234s
d3a				(pixbuf)			1.130783s
E17-Gtk			(pixbuf)			1.398836s
Gentle			(pixbuf)			1.406059s
Ana				(svg>pixbuf)		2.085190s
eXperience		(experience)		2.224572s

 

 

I never made that assumption at all. I'm just not getting into details that anyone participating in the dicussion should already know, without it needing to be said. I'm not a theme engine writer so I wouldn't know. Would you? :P ...other than the fact that I do know binaries are faster but I wouldn't want that because I don't what to loose flexibility.

Again, a binary format for the theme wouldnt cause the window to redraw any faster. It would only make a very negligable change to the initial loading time, and hinder development and distribution by requiring it to be compiled, and depending on implementation, recompiled for different architectures.

Of course it would, but I was mostly referring to the gnome de not a theme engine. That would really suck.

 

 

Well, since it is what I do, I can assure you the theme is not poorly written, in fact, in my attempts to speed it up (which I did), I could speed up Clearlooks/Human, Industrial and a few offspring, quite a bit since they are poorly written ;) Of course I could remove the utility code and have improper utility windows like everyone else and speed it up a little, but I think everything should work properly and as designed, else, why bother? Since my sys is not shiny new and is about ...?... almost 2 years old, I do notice, and I'm more the norm and what matters when considering these things ;) Are you implying that linux should adopt the XP/Vista mentality that people should have to upgrade hardware in order to run it? (not an actual question)

good to see you're working hard on it. Though i'd like to know why clearlooks and industrial are poorly written... those are big words for someone to throw around.

 

I also have an older system which i use frequently, my laptop, so I'm also on the norm, and see no problems right now. Cairo is rendering fine on it, no slower -- and more importantly, not noticeably slower. Maybe if you run some synthetic benchmarks you'll find that cairo will render slightly slowly, but so long as it isnt in the human perceptible range, it simply isnt relevant.

Wait, so it's not big words for you to say my theme is poorly written, but it is big words for me to say Clearlooks and others are? How's that work? Why was I asked to smooth out Ubuntulooks/Human? and did (as much as I was permitted), why are other major changes coming to ubunulooks if they are approved after implimented? Am I new at this? You need to adjust your bias perception.

 

They are poorly writen because they contain 'tint' and 'alpha'. Gflat-Round went from 9 milliseconds to 13 milliseconds changing the buttons to round using that code and changing it to rectangles got it down to 10 milliseconds. If thats just a few milliseconds that is irrelevent, why did Clearlooks switch to pixmap buttons to get it from 13 or 14? to 9 or 10 sacrificing accessability for the default gnome theme? ;)

 

It is very relevent because you are forgeting the biggest factor, regardless of benchmarks because they need to be multiplied ;). It's the same reason a pixmap metacity theme can be faster than a code only theme according to the metacity-theme-viewer, yet you can plainly see it has a much slower redraw on the destop. Nautilus. Everything has to get past nautilus. Disabling nautilus more than doubles your gnome performance. This of course has little to do with xml though. Nautilus can render metacity code a lot faster than images.

 

No, we never see eye to eye anymore.

 

arthur, no, xgl/compiz is faster than xorg/metacity depending on the degree of effects of course. That's according to my own personal experience and many others I've heard the same from. That is encouraging! I just can't use something that's not themable yet.

Edited June 13, 2006 by bvc