Hacker Newsnew | past | comments | ask | show | jobs | submit | cmf028's commentslogin

Also relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=539356

That bug is getting close to being done. It fixes a lot of crappyness with excessive layout reflows and painting.

You can see how sometimes Gecko will reflow a much larger area than needed by setting nglayout.debug.paint_flashing to true or installing the following addon: https://addons.mozilla.org/en-US/firefox/addon/toggle-paint-...

Notable cases of excessive reflows: Hovering over the sidebar links in gmail (updates almost the entire page on each hover) Hovering over "related videos" links on youtube (updates all of the related videos area, area around the video, video description, and comment area) A lot of the javascript powered animations/slideshows you see on web pages. (Again, its not uncommon to see almost the entire page being updated here) A few IE test drive tests like BetaFishIE, Santa's workshop, and the CSS maze solver.

When the above bug is fixed, Gecko should be much better in all of these cases.


I did Save Page -> Find/Replace All "webkit" "moz" Works :)


there is also no way this ipad will have great gaming perf at that resolution.

you would have to run games at a less than native resolution then upscale it to fit the screen which looks really bad.

Graphics perfomence on this machine will take a very large nosedive overall if you use fullscreen apps at that native resolution. Mobile Gpus simply arnt up to the task of filling that resolution at a good enough rate for anything other than simple graphics.


The solution is to render games at 1024x768, the same resolution as the ipad 2. Scaling it up to 2048x1536 is trivial if you just treat every pixel as four pixels on the display and will look just as good/bad as the ipad 2 does.

Can't believe this article got upvoted, there is no information about anything in it.

TLDR; iPad 3 has a resolution of 2048x1536.


Same here, reading the title I was already sure this was some kind of bad mashed up article. I guess extremetech got a lot of "friends".

Give me a break with supercharging photoshop on ipad..

It kind of does not change anything, maybe it makes a big change in games for antialiasing, but that's it. It remains ti be seen if it will really improve reading on the device

Anyway..


I'm not really convinced that upscaling will look "really bad" with algorithms optimized for high resolutions. Besides, consumers have already been conditioned to accept upscaling artifacts with the current gen gaming consoles.


* citation needed


Interestingly, the pencil tool doesn't have this limitation. Even when turning the size up.


ecmascript 6 will also introduce for of loops which is said to fix for in. checkout wiki.ecmascript.org for all the ecmascript 6/harmony niceness


Hardware acceleration for Canvas and SVG makes a huge difference in this case.

Firefox 4+ (Windows Vista/7), IE9+ (Windows Vista/7), Chrome(I forget which version)+ (All Windows, Mac Soon), and Safari 5+ (OSX) all support hardware acceleration of Canvas.

Opera development builds support hardware acceleration too.

Chrome Beta on Android supports hardware acceleration of Canvas. iPhone 4S also supports hardware acceleration of Canvas.

Hardware accelerated Canvas completely destroys Flash on the Desktop.

A lot has changed in `~2 years

Not to mention that modern JS engines outperform even statically typed AS3 code.

Of course, if you don't have a supported graphics card for your computer, you won't get hardware acceleration.

However, I imagine this won't be a problem on Mobile once Android 4.0 eclipses other versions of Android since Hardware acceleration is a standard Android 4.0 feature.


"As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster."

[Citation Needed]

I know of old benchmarks (pre Crankshaft) that showed the interpreter being faster than V8, but my own tests using the same benchmarks from the computer language shootout show V8 to be about 1.5x faster than luaJIT now.

I did some searching, and the most recent (though still way out of date) comparison I could find was this: http://attractivechaos.github.com/plb/


You can compare v8 to vanilla lua on the computer language shootout benchmarks page, and then compare luajit to lua on the luajit page. V8 has definitely made up some ground, and the luajit interpreter isn't generally faster than v8, but the jit is still way faster on almost all tests. The one area where luajit isn't great is on tests that stress garbage collection, since luajit still uses vanilla lua's GC. I think that's luajit's next area of focus.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: