bvc
-
Posts
8645 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by bvc
-
-
any one that ran/runs Dapper and FC5 got any comments on speed/performance between the 2? I don't care about bootup just after login. Dapper is tearing me up. I told myself to keep the month old devel version and not upgrade to the release, because everyhting was hunkydory, but noOOOo....I had to
I have to turn nautilus off, use a light metacity and the thinice engine to get anything done. -
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.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.
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.
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.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.
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.
-
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.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.
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.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 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.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.
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)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
-
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
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.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?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
-
yes, cause when I used unstable for over a year it was more stable than mandrake :P
don't let the definition of the word fool ya
-
That file doesn't exist. This is everything I have in /etc/X11
app-defaults gdm X Xresources Xsession.options
cursors rgb.txt XF86Config-4 xserver xsm
default-display-manager rstart xinit Xsession Xwrapper.config
fonts sysconfig xkb Xsession.d
XF86Config-4
oh, they never switched? yuk
-
well, we need more info, like;
-video card
-driver being used
in other words....post the Device Section of your /etc/X11/xorg.conf file
-
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.
with the more code, there's more rendering being needed to be done, and more instructions to be followed by the WM to draw the theme.You could pad it with half a meg of whitespace though, and the theme would render in exactly the same time for every window, as the instructions are only loaded once, and are only parsed the once, when the theme is applied, or when the wm is started.
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
-
CleanBig is a port to Metacity based on the CleanBig Enlightenment DR16 theme and was ported to Sawfish before we had Metacity. I know, it's old, but I sometimes like to take trips back in time. Included is the smooth engine theme seen in the screenshot.
-
That's crazy...test for a year?. Based on my on personal experiences with Mark, I'd say he'll press on with the current process and improve on it. That's a good plan, and he is a smart man, IF the good and bad are called correctly. From what I have seen, that is not the case, and that pisses a lot of people off, so you lose good people. Then a lot of time is wasted on the next release bringing people into the ubuntu process. That would make the plan very bad, and you've seen the end result. Will it happen again? We'll see, but I won't have any part of it.
Take the art team. The way he finally wants it ran is what I've been screaming for for since warty, but it takes a lot of time, and it's hard to find people that have that kind of time that can work for free because we have jobs and lives. If you want tope notch results, you gotta be willing to show the $. Did Apple find a few wannabe themers and say 'hey, make us a desktop theme'. No they found designers and artist and showed some $. Otherwise you get half baked art. If I had the time, I'd love to participate in the Edgy art process, but I do not have that kind of free time. Throughout the dapper devel process I laughed at people trying to compare dapper with vista. Please people, even with xgl/aixgl and compix it's not even in the same ballpark and you gotta be in the same ballpark to play ball with the big boys. It's no diff than marketing. If you don't show the $, forget it.
-
they took extra time because there was no other choice if even to have half a distroIMHO it is a bit surprising as this release was expected to start their enterprise business, and they took the extra time in order to make sure that the release is enterprise ready. And what do they deliver? Something that apparently is not Enterprise-ready.
might? II don't think there's room for any other option, unless they want to continue to fail.Now that they couldn't live up to their own set high standards/goals shows me that they might need to rethink their Enterprise model, much like Red Hat did. Split RH into RHEL and Fedora. Let's see how they will handle this...
Won't hurt linux. Ubuntu simply delivered what was expected. Sure ain't gonna help though. Yeah, I'm also a pessimistWhat worries me most is: taking into account that much of the media focused on Ubuntu lately, the serious bugs in 6.06 and the spreading of word about them will only hurt the overall Linux image, I guess. For many, who never heard of Linux before, Ubuntu IS Linux. Yeah, I'm a pessimist.
They grew too fast and furious, got big headed, and tried to take big boy steps when they still needed to take baby steps.
-
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.
-
I'm dialup so...I won't be clean installing and it'll be a while before I upgrade everyhting, but yes, much was left undone. If you know ubuntu's devel process, it's really not suprising.
-
well, when president Who?..I mean Hu was here a month ago, he visited Bill Gates before meeting with the president of the counrty he was a guest in for political reasons. MS ain't missing out on anything I'm sure. China wants Taiwan, and since we won't let them have it, they'll take what it wants from it. ;) Traitor Gates will be more than happy I'm sure.Interesting, John. That would imply that the Chinese government is indeed pulling a fast one on windows. Could it be that there is a private discussion going on that Redmond seems to be losing? -
-
-
removing white space and return characters really doesn't make that big of a difference in the grand scheme. XML files usually aren't stored in memory, just read when a program starts for the necessary information and possibly a few times during program usage - but if a program is loading XML files into memory on a regular basis it's inefficient. XML should be read to get variables, and those variables should be what are stored in memory (with the program) - at which time all the white space and return characters aren't present anyways (if the programmer is worth his salt).
That's right, but it takes some time to read the whole file, rendrer it, then find a needed key/option. The larger a file - the more time you need to render it and then search for a proper option. Deleting white spaces and return chars makes a file much smaller (though less readable for human).
It is pity you can not read the original post, they give some clever explanations there, and i think i support them. Some said that gnome's xml parser is kind of a slow.
but if a program is loading XML files into memory on a regular basis it's inefficient. XML should be read to get variables, and those variables should be what are stored in memory (with the program) - at which time all the white space and return characters aren't present anyways (if the programmer is worth his salt).If the program reads xml file and then stores it in variables, than indeed xml file is read only few times while the program is running. If it is so, then how does gnome enable instant apply of gconf? In kde for example you don't have this feature.
gconfd-2
I don't know if dbus has anything to do with it or not
-
Metacity uses xml and is a little slower than the 'boxes' which are usually text.
KDE loads a lot in mem ahead of time, so it is naturally faster (they say). A big slow down for Gnome was the addition of Cairo.
My wife was using 2005LE Gnome2.8 up until a few weeks ago and she says Ubuntu Dapper Gnome2.14 is a lot snappier and faster and loves the swith overall. I thought the opposite but then I've been Ubuntu since Warty-beta.
-
http://www.gnome-look.org/content/show.php?content=37461
that won't work for ya?
-
-
-
Nice theme bvc!
here my old Vista theme:
thx!
-
-
rt-click the panel>Add to panel>Window List
Still undecided? Then install Fedora Core 5!
in Everything Linux
Posted
thx! You'd think there'd be an improvement from devel to release, not the other way around, and not twice as bad
Just a few days ago, and before, I hardly ever touched my swap, but now I do every boot. Haven't singled anything out, just seems a lot of things are using more mem, and I wish I new why and if anything can be done about it.
/bvc goes searching......