We Keep Coding

Major slowdown seen in Pixi.js with Chrome VS Firefox?

I've been using the Phaser.io 2 game engine which runs on Pixi.js as it's primary renderer. However, I've seen some stuttering in the rendering methods directly that I can't seem to pin down. On Chrome, I've managed to smooth things out but not precisely, while on Firefox things run very smoothly, and apparently in other browser and mini-browsers as well.
Today, I recorded a gif of the effect with the main Pixi.js site open in both:
https://i.gyazo.com/23ede3852844317c3abda424a06b9adc.mp4
I have asked others to look at the rendering on Chrome and they have also seen this stuttering, however in the gif, with Chrome on the left and Firefox on the right, it's very obvious something is not correct.
Is there any possible cause that should be looked at, or known issues?

Try enabling hardware acceleration in Chrome settings->search 'hardware acceleration'

Down-Sized Images are Slow in Chrome

I'm working on a script and have an issue with Chrome.
Here's what I'm doing:
1. Loading large images into a DIV.
2. Scaling the images to fit the size of the DIV.
3. When the browser is resized, the image is scaled up and down with the browser.
Everything is working 100% in all browsers except Chrome.
I've checked the profiler in Chrome and don't see anything unusual.
These are large images, however are working just fine (even live) in all other browsers.
I've read a ton of places that have noted this issue when using down-sized images in Chrome...but not solution.
Nothing special going on, just using a
var img=new Image();
$(img).load(function(){ .... {);
Does anyone know of a workaround or solution that will work in Chrome?
Thanks!

So it appears that Chrome just sucks when it comes to handling large images and even images that aren't large, but just scaled down. I've searched around endlessly only to find similar questions without resolutions.
Still not sure why all other browsers (even IE 7 and 8) can handle large images (tested with 7mb scaled-down PNGs), but Chrome can't even manage to do a 700kb scaled-down JPG without lagging.
So, I'm answering this question with: in this instance, Chrome sucks.

I had exactly the same problem, but recently solved it. Huge amounth of performance takes up chrome's anti-aliasing, because it recalculates the entire image whenever you resize it.
So to solve it you just add this line to the css if your image:
#myImage
{
image-rendering: -webkit-optimize-contrast;
}
You can turn it off by javascript when the image is still.
More about anti-aliasing: Disable antialising when scaling images

How are you resizing the images? Using height/width or CSS transforms? The latter might result in better performance.
Some info:
Improving the Performance of your HTML5 App

When you're profiling issues with image resizes and decodes in Chrome, it's best to use the Developer Tools Timeline for this as it can give you relatively accurate stats on exactly what took a long time to be decoded.
Downsizing (or re-sizing) involves Chrome having to both decode the image (JPEG/PNG/GIF) you're sending down the line and then do extra work to resize that image into the container (div) that you would like to display it in. Where possible, the advice from the Chrome team is to prescale your images to the correct width/height needed.
Now you might be wondering: well, surely this issue is just down to desktop Chrome sucking, right? It's not as clear-cut as that. Particularly on mobile devices where browsers have less access to a powerful GPU/CPU, it's going to be costly to perform those resize operations there as well. So in short: yes, rescaling large images can be slow in Chrome sometimes. Try to prescale where possible and these performance bottlenecks should disappear.

Chrome 24 vs IE10 Scrolling Horrible Lag

I am currently developing a web application focusing primarily on Chrome 24.01312.57 and IE10. In the former browser, I am experiencing a large amount of lag. However, the latter experiences little to no lag, which is quite opposite to what everyone claims.
To show you the difference, I am recording the screens of my netbook using an iPhone while scrolling down The Chrome Webstore - something Google itself created.
Testing Equipment
2 year old Gateway Netbook -Single Core Intel Atom - 1GB RAM - Win7
iPhone camera (not that great recording solution, but it is quite easy to spot the difference)
Website: https://chrome.google.com/webstore/category/home (I scrolled down quite a bit for both the browsers before starting the test for those worried of AJAX loaded content slowing down the rendering)
Results
Google Chrome 24 (No extensions) scrolling down the Webstore:
http://www.youtube.com/watch?v=njkRqiNJPIY
Internet Explorer (No addons) 10 on the same page:http://www.youtube.com/watch?v=B_E_9OzPers
Note: Look at the mouse cursor and the scroll thumb - on IE10, the mouse is always on the the thumb whereas Chrome, it is all over the place indicating a high latency between mouse movement and the actual rendering.
Bottom Line:
Before I conclude, do realize that these lags on Google Chrome are increasingly magnified as the website becomes more complex and/or the specs go lower. However, IE10 is pushing the FPS quite high even in these conditions. I also did some analysis of the Chrome timeline. In reveals that the FPS drops as you zoom out to the point where rendering takes up to ~900ms per frame (on the Google Webstore) while IE10 is still fluid smooth (and better yet it retains that smoothness on an atom netbook)
As web developers, is there some CSS property/ies that is causing Chrome to render the pages with lag?
Why is Internet Explorer rendering so quickly?
What can be some steps to make Chrome render as quickly as IE10?
PS: Bug Report: http://code.google.com/p/chromium/issues/detail?id=163092 but no recent developments on this currently.

Chrome struggles with painting, especially at high resolutions such as 2560x1440 and above. Many websites such as the Chrome Web Store, Facebook, etc. exhibit significant scroll lag on it. IE10 maintains 120 fps on my monitor while scrolling on these sites.

I just had and fixed a similar issue.
Apparently Chrome isn't too smart about their recalculation of styles, besides that being terribly slow, so I focused on preventing it from recalculating anything.
I added the 'scrolled' class whenever the scroll event was triggered, but if it was already there, Chrome kept recalculating the new styles anyway. When I modified it to be like:
if (!body.hasClass('scrolled')) { body.addClass('scrolled'); }
Chrome suddenly experienced a significant speedup (still no IE or FF, but much better than before)

It's the video card on the Netbook! You will experience similar effect on almost everithing that moves on your screen.
I have a Netbook...
The web you are testing crashed Chrome browser until not long ago...

Choppy/glitchy CSS3 transitions problem on the iPad 1 (with example)?

With this project at work, we have had to make a iPad HTML5. Using Backbone and jQuery Mobile, we thought we were on to a winner, but jQuery Mobile seems to be causing more problems than it should be. Using such things as page transitions with jQuery Mobile is painfully slow, choppy and glitchy (I do understand it's still in Alpha).
For our needs, we do want a smooth way of transitions between pages. I set about doing some experiments to see if I could get them any better for bespoke solution. I feel I'm quite close with this, but the animations still seem choppy and glitchy. I wonder if there is any other way to approach this? Or if there is a nugget of information that will help getting this rock solid?
I'm using translateX()/translateY() CSS3 (hardware accelerated) transforms to ensure it gets the best performance, but it still seems unreliable with it's performance. Sometimes it's ok, sometimes it's not.
I have uploaded an example... Please note, this is only tested in Chrome/Safari (which it looks fine in) and Mobile Safari on the iPad 1st generation (which it looks choppy in). If you happen to have an iPad handy, please take a look at this example...
http://littlejim.co.uk/code/ipad/jquery-plugin-page-transitions/
It's made as a basic plugin, because once I have this nailed I want to develop it more.
Can anyone help with this? I just wonder why it's still choppy on the iPad?
UPDATE: I tried using translate3d() as well as the translateX and translateY(), made no difference.

Only 3 dimensional transforms are hardware accelerated on the iPad. You should use translate3d and provide a 3rd parameter, set to zero.
http://googlecode.blogspot.com/2010/08/css3-transitions-and-transforms-in.html

Maximum number of divs allowed in web page

Hi I was wondering if there is a limit to the number of divs that are allowed on a web page?
For example will Internet Explorer start to choke when it has to render a webpage with a thousand divs?

I know this is an old post, but I recently did a test that is directly related to this topic and I wanted to share my results.
I created a simple php script that spits out x number of 5px by 5px inline-block divs to test browser stability and page scroll-ability.
At 1000 divs on the page IE9, Firefox, and Chrome have no problem whatsoever and don't even seem to hiccup when scrolling.
At 10,000 divs IE9 and Chrome are able to scroll with a barely-noticeable delay, still within the 'acceptable' range in my book, however Firefox begins to lag more noticeably, to the point where you feel the scroll bar is jumping into position a half-second later than it should.
Interestingly, the performance difference between 10,000 divs and 100,000 is not as drastic as you'd imagine. IE9 and Chrome perform with only a barely perceptible delay in scrolling (with Chrome being the slightly smoother of the two), and Firefox has a delay that is very noticeable and would probably be considered annoying, but still functions reasonably well (i.e. it doesn't crash).
Now at 500,000 divs on the page it finally started to get interesting. IE9 Crashed and tried to restart itself (on the same page, of course) and crashed again, at which point I shut it down properly, restarted it, and tried one more time to make sure the same result would happen again. It did.
Chrome remained stable, but it became nearly impossible to scroll the page due to the extreme delay.
The big surprise was Firefox, the browser that was chunky at 100,000 divs is just about the same at 500,00 divs ... scrolling is not smooth, but it is way, way better than Chrome.
Amazingly, the results were pretty much the same for 1,000,000 divs on a page! Firefox handled them without crashing and remained scrollable though 'chunky'. IE9 crashed. And Chrome was able to load the page but became so slow that it was virtually unusable.
I know this isn't exactly a scientific study, but I figured it might be interesting to someone else besides myself.
Tests were performed on a Dell workstation with Dual-Xeon processors and 4 gigs of ram, running Windows 7.

There are two things to consider. Memory is one, where DOM nodes take up a huge amount of space. The other is CPU time needed to re-render all of these nodes when something changes. The threshold of smooth rendering depends on the engine used. In my experience, IE falls far behind, starting to choke after several hundred. Firefox can take several thousand, and it's about the same (and a little better) for WebKit browsers like Chrome.