That looks...

AWESOME.

WANT.

NOW.

HATE.

DELL.

Well it shows the same scrolling / rendering issue, so at least we can confirm Megacrazy doesn't a have a "slow special" in that department

It's very interesting to see that the issue doesn't occur (or only very slightly) when zoomed out and showing a complex web page with tens of thousands of characters and plenty of images. It only occurs when you've zoomed in fully.

That tells me it is definitely a software issue with the rendering algorithm. If it was raw performance, it would be slower when zoomed out, due to increased scene complexity (whether hardware-assisted rendering or not). Since that's Gecko's area (the heart of Mozilla, Firefox, Fennec) I don't think we can blame Nokia for Gecko's behaviour - after all Gecko is an excellent browser engine choice in most respects - but we can annoy the folks at Mozilla with these videos until they improve it

I have no comment on the other issues.

It does? Please point it out to me.

Anyway, this issue is of no concern to me. Even Megacrazy's videos present performance that seems satisfactory to me. And if I want another browser, that shouldn't be a problem either.

Thanks for the video that was great contrast to the OP's claims. It is interesting to look at various users expectations. As this video proves the N900 is pretty adequate in scrolling while music is playing for the majority of people. I guess 50 fps is what constitutes as smooth these days. I don't know anything though I don't have an N900 yet.

Could it be that larger text is more complicated to render? And that it scales in such a way that the higher resolution is a greater factor than the fewer number of characters on the screen at one time? Maybe there just needs to be a cache for the glyphs that are most frequently rendered in a given font and for a given point size. We should really open a bug, if only to inquire about how this all works.

I've recently implemented phase 1 of a double-tap zoom hack for the Diablo GTK webkit, so I spent some time staring at how the iPhone OS webkit implements zoom. It's simple. They just do an animated 2D transform while another thread is rerendering the page. They time the animation such that the final pixel copy happens soon after the animation finishes. If you have such a device, you'll notice that your screen is frozen to UI while this is happening. After the zoom is complete, you have to reregister your onFingerDown event. Nothing will happen until you do. A simple parlor trick, nothing more. Nokia could do this, but instead they decided to show you the continuous output of your appSSS. Plural. So, now all you eye candy weenies know.

At 4:24 there's the worst bit: a big rendering chug while scrolling up, taking a long time to draw the mysymbian banner. In that time, the whole top half of the screen is blank for a quarter of a second. It's like watching Netscape Navigator 4 all over again :-)

In fact it has the delay twice there. It really looks like it happens when there are certain object types being rendered.

See what I mean about it only happening when zoomed in? And I notice, when scrolling up (to the start of the page); it doesn't happen scrolling down.

At 4:18-4:20 when you zoom out, there's a long delay in filling in the top and sides - more white gap.

When zoomed out, it's pretty consistently good. At 4:12, there's a white strip at the top of the browser - another rendering delay, perhaps. (It'd be less visible if it was black).

(I see lots of brief stalls in the kinetic scrolling, but that could easily be Youtube not the device).

Big rendering chug at 5:33. Ok, that's a task switch, we may expect more chugging then. (Though a really polished implementation would hide such things).

Indeed. To me it reminds me of browsers from an era gone by (waves to my old laptop). But it's usable, and no doubt will improve. It's a very superficial issue.

As someone who has worked on game engines, video playback devices and GUI toolkits, I tend to notice these little things and think "if only I it wasn't just me..."

I'm fascinated that you didn't see them in your own video. It really reminds me of my colleague who can't tell the difference between 30fps games and 60fps games - whereas I can tell immediately and they feel totally different to look at. No wonder people argue about these things if they're invisible - and therefore not an issue - to half the people

Knowing is half the battle. When can we expect this hack?

Parlour tricks are what good eye candy is made of.

I think Nokia's approach is better, and in this case it's up to the app to provide the parlour tricks.

(Though for really polished polish, to make transitions glitch free you do need some global scene management or compositing of app output.)