Expecially when it’s only one steaming pile of manure browser that has the problem… ESPECIALLY when that browser is NOT IE. Chrome doesn’t have these issues, Safari doesn’t, Opera doesn’t… Even IE9 and 10 Beta don’t…
I’ve started to think gecko needs to go the way of trident – both engines are aging poorly, too heavily reliant upon code of their forebearers (for all the claims of a clean break, gecko based browsers are still Nyetscape 4’s sweetly retarded cousin, just wearing the big-boy pants)… and it shows… PAINFULLY. See how the main renderer is such a black box in Gecko nobody can figure out how to simply make alignments on colgroups inherit… Time to throw it out and start over.
Though I’ll admit freely, I’m one of the few developers who has HATED Firefox in most every incarnation since it was introduced and hated mozilla suite before that for being a buggy unstable train wreck with the slowest RENDERER of any browser. Because of course, locking up and refusing to respond every 20 minutes like clockwork due to a broken caching model – It’s not a bug, it’s a feature..
That I can still make even the most recent version do just by trying to save images I’ve opened in multiple tabs.
Then what the {string of expletives omitted} are they giving us them for in the first place? Much less if using them ONCE is your idea of ‘crammed’… Sure, some of the pages linked to are heavy in them:
Some of the examples (like that full screen gradient) uses them only ONCE and still throws ricky fits on certain hardware combinations in ONE particular browser… and said pages “crammed” with them EXHIBIT NO SUCH PROBLEMS in browsers other than Firefox.
Of course, if we said the problem was in IE, everyone’s tune would change, right? Suddenly we’d have twenty different scripted shivs to workaround it?
Off Topic:
Oh yes, that crippled vendor lock in overpriced overvalued might as well be IKEA Apple nonsense is the answer… RIGHT. Christmas on a cracker what the blazes is in the kool-aid for those?
That article that starts with this opening statement.
The application was highly dynamic, interactive, and was heavily stuffed with new CSS3 goodness. I’m not talking just border-radius and gradients. It was a full stack of shadows, gradients, transforms, sprinkled with transitions, smooth half-transparent colors, clever pseudo-element -based CSS tricks, and experimental CSS features.
–
It’s always been known that certain selectors are expensive in terms of speed (universal selector I’m looking at you) but in most normal applications they are largely irrelevant. However on complex pages you do need to be careful what you use and that will vary from browser to browser.
There is no real answer and to be honest I think browsers should be able to handle most of what you throw at them without “us” having to have an in depth knowledge of how efficient each selector is and in which browser version it will slow down. Common sense should prevail but it is clear that some css3 properties do need to be optimised more efficiently by the UA.
I agree with that, but I don’t find the current breed of browsers struggling as much as ds is claiming with what I’m calling reasonable effects.
ds, firefox just doesn’t do that on my machine. It’s my default browser and it handles these features quite well.
I actually refuse to run FF for the very same reason. While I have little CSS issues on my rather beefy machine (3.06 Ghz i7, high end graphics card and 6GB/s hard drive, 6GB RAM). However, I have the saving-images-locks-the-browser issue without fail in the past several iterations, and it can even bring my system to it’s knees. When I can play most modern games on max specs, but a browser can’t handle ten tabs… somethings wrong…
It should be almost impossible to have CSS slow a machine like mine down… period. FF does though. I tried several very complex examples and even on my work laptop (which is decent, but not as good), all of the other browsers could handle it just fine. FF barely moved.
However, I don’t think that dimishes CSS3’s usefulness. At the same time, having image fall backs is also not a bad idea. =p
I switched from FF to Chrome for this reason. I used to have a very slow netbook. Not a lot of processing power. Running FF alone would cripple my netbook. I like to have a lot of tabs up. Chrome allows for many tabs, and even can load a high performance game as well :).
Now that I have a faster computer, habit still has me use Chrome. FF is only good to me for firebug.
I used to love and swear by FF, but now I refuse to have it open for more than a few minutes at a time because it bogs my whole machine down. I agree with DS that they just need to throw it away and start from scratch, or just go away. It’s clearly become too antiquated.
Did you read PAST the opening statement? Here, I’ll do it:
In both Opera and WebKit, “border-radius” is among the most expensive CSS properties to affect rendering time. Even more than shadows and gradients. Note that it doesn’t affect layout time — as one would think — but mainly repaint.
Why Opera and Webkit? Because those were the two browsers that allowed him to do the kinds of tests he wanted to do. Meaning, other browsers could be worse, or fail harder on other things than border-radius. Would’ve loved to see what Firefox would have come up with.
The CSS-heavy app page was merely the intro, where he described why he started looking further into CSS performance.
Yes, I read past it. And you’re right Paul, there’s some good information on topic in there.
But, you think his example was light on CSS3?
He’s applying these styles to 400 elements on the page.
rgba color
rgba text-shadow
rgba box shadow
rgba box shadow 2
border-radius
linear gradient
opacity
I know not all effects are created equal but that’s 2800 effects on top of regular layout, and it takes 177ms to draw everything. That’s pretty much what I would expect.
I also got different results visibly in Firefox, while his example was jumpy with scrolling - it was opacity that had the biggest impact on scrolling for me.
It’s clear that there’s lots of factors and different browsers on different hardware will perform better at some things than others. Jason tested a game I made in lots of different browsers and gave some detailed feedback. It was using quite a lot of CSS3 and transitions as well as SVG & Canvas.
The results were a mixed bag, some browsers performed well on different platforms & hardware. Some on lower specs outperformed the better hardware in some cases.
It’s good advice to test these thoroughly and be cautious - but it’s not good advice to say it can’t be used.
I’ve found many uses of it time-saving for development, better output for clients and a better experience for users.
It was really cute how it locked up Firefox on two different platforms too. Oddly I think if you took that game you showed me mono-canvas and ditched the CSS3 altogether, it would be much more viable… and all your effects would actually work in IE… though admittedly that’s a lot of work; you’ve got a lot less going on in that game in terms of screen updates and drawing than say, my stupid little canvas demo I linked you to. (which uses so many bezier curves it’s a miracle I can get 15fps out of it full-screen in FF or 30fps in anything else).
All of this stuff shows a lot of promise, but really needs to be dialed in more in terms of renderer speed. Canvas right now is ‘ready to go’ IMHO even in FF for simple vector/scaled games – CSS3 effects are as you said a mixed bag, and IMHO should be used with a eyedropper. SHAME audio isn’t anywhere NEAR ready for use though with it’s half a second lag in just about everything, inability to loop without dropouts, and that you can’t dynamically generate playback reliably or in all browsers.
Also a shame javascript’s timer maxes out around 33 ticks a second accuracy, limiting your frame rate options and ability to respond to changes.
Just be VERY careful on that last one – this is the Internet, the only thing we know about who will come is we don’t know who will come.
The other thing I found with that demo with all the buttons is that the number of elements on screen is important. Make the buttons bigger with a width / height and the performance increases.
Thanks for the feedback Jason, I’ll have a good play on different windows machines and see it how performs.
Nobody thought the original page he started his article on was light on CSS3. But it would be a worthless test if you didn’t take a page and test one thing at a time. A page with nothing but Opacity. A page with nothing but border-radius. A page with nothing but canvas junk. Applying 400 styles and saying “well this one bit of CSS was the heaviest” makes no sense to me, how could someone make a valid test from that??
In the course of his testing he was also trying to improve the craptastic page he was asked to optimise as well, but I don’t take that to mean his tests actually measuring performance were “light CSS3 pages with 400+ elements”.
I know someone who (unfortunately) believes his next project must have all this new stuff (also HTML5, localstorage and several other APIs). It seems the hype has convinced him that if he does not build by cramming as much crap into one page as possible, then his page won’t be “future-proof” (or, he seems to have the idea that if he built more leanly and also with older technology, that within a year the page will “break” or quit working or something… not sure where he gets that from).
