Hacker News Reader

Comment by bd | Hacker News Reader

I just ran it through usual menagerie of browsers (Win7 - CH, FF, SF, OP, IE) and Chrome was the only one with really bad performance (surprisingly even on HW accelerated canary build).

It's quite refreshing to see MS guys pointing out performance bottlenecks in Google's code :).

Competition is good.

With IE9 MS managed to find one area where virtually all other browsers sucked (large / many / transparent image sprites), made a good implementation and created some clever demos that benefit from this implementation.

This may have hastened coming of HW acceleration to upcoming public releases of Chrome and Firefox.

Kudos for IE team for stepping up the game.

View on HN

I tried it out with Chromium 7.0.533.0 on Ubuntu 10.04, with the hardware acceleration disabled. It seemed to me that it became sluggish only when the text bubbles were on the screen, which admittedly was most of the time. It could handle the images fine, but for some reason it seemed to have trouble with the text. It'd be interesting to know why this is.

I'm going to try it again with the hardware acceleration enabled this time to see how much of a difference it makes.

Edit: So with hardware acceleration enabled, it was smoother but still a little laggy. It also used up more of the CPU.

Competition is good but browser fragmentation is the last thing we need. Good that IE highlights one area where browsers differ, but still, I wonder if we will ever get to write once run anywhere.

Unfortunately I'm afraid some fragmentation is going to happen, though not necessarily around browser axis.

This is actually a deeper problem. It's not about standards, it's about performance.

"Old" web (where old is almost anything up to just recently) got to the point that whatever you do, can run reasonably well virtually everywhere (welcome to dream, write once, run on PC / Mac / Linux / iPhone / Android).

"New" web (what runs on nightlies / alphas / canaries) will need enough raw power for all its shininess.

Old web was seriously underusing resources on modern computers, so there was enough slack to cut / optimize away. New web is about reclaiming back this idle unused power.

If you get a terrible performance in some recent demos (and yet you see other people telling how good something runs), welcome to inequalities of new HW accelerated web.

Problems can be:

a) bad GPU drivers preventing your HW performing well (old drivers, weird manufacturer's driver versions for notebooks, not-completely-fine-tuned drivers for Linux / Mac),

b) your HW is not very powerful (netbooks, mobile devices, integrated GPUs).

This is something standards can't hide. You can have software emulation fallbacks to be compliant, but this will not really help practically, especially not on underpowered devices.

And this is in addition to performance differences coming from different browsers implementations (which may all perfectly comply with standards).

Not too different, in the end. The "Old" web was "patched" with excessive Flash, which slowed it down for many users.

I'll take the "New" web browsers over Flash, though. Better hardware acceleration (such as for large images) should've been done long ago, and Flash is a security / stability / (usually) usability nightmare.

Old web's patch is for the most part optional, if you don't want the shinies. With "new" web, what is there to disable if your hw can't handle it's stress?

Not entirely, as it's only recently that anything even remotely challenging Flash has been a viable option, and where fallbacks / functional pages without it exist frequently.

I do agree with your second point, however. Is it too much to hope that the standard JS libraries will eventually support scalable shininess?

Works smoothly on Safari on OSX, though not Chrome. Anyone know if OSX-Safari has explicit hardware acceleration? Or does it use the core libraries for display? Or is there some other trickery going on?

Reply on news.ycombinator.com