We have published an HTML5 Canvas through Adobe Animate. And have reduced the file size down to under 2MB total and it loads in under 3 seconds on all browsers. But we are having frame (FPS) lagging issues on Google Chrome only.
We deactivated the 2D canvas chrome accelerator in Chrome Flags, but are still having issues getting the animation run smoothly at larger screen sizes.
Is there a way to publish the canvas in Animate so this doesn't happen? Or is there some JavaScript code to allow for Chrome to load the animation at the correct FPS?
We have tested in IE, Edge, and FF and all of those browsers run smoothly. It is only Google Chrome that is experiencing the issue.
Having profiled this, I have found that the code makes a large number of calls to drawImage. On my machine, it spent 86% of its time in calls to drawImage.
Its possible that its redrawing the large images every frame. See if there is a way to stop this from occurring.
Try removing the background images and having just the lines, if the lag disappears, you have your answer.
Potentially relevant:
Why does chrome struggle to display lots of images on a canvas when the other browsers don't?
Related
the situation is as follows: there is an HTML5 game. The game is quite heavy in terms of the javascript code, graphics and sounds – approximately 30 MB. All the animation is created by means of createjs. In the game I use 2 canvases one over the other; the control buttons are between the canvases (the buttons are created by means of the standard button elements).
One canvas is the main one and most of the animation is implemented on this canvas; the second canvas is used when it is necessary to show the animation over the control buttons. Initially, the size of each canvas was 970px x 740px. All the animation worked perfectly in desktop browsers as well as in Chrome and FireFox in Android. However, in the mobile Safari browser the animation worked very slowly.
Then I reduced the size of the canvases by 30 % (accordingly to the graph on the sprite sheets). As a result, Safari started working more efficiently on an ipad. The animation of the lower canvas stopped hanging but only unless the extra animation was launched on the upper canvas. Then everything got slow again. I don’t apply WebGL because I have to use both bitmap and the vector graphics. Who knows how to improve the situation in this case so as to prevent the FPS from falling, could you help me, please?
There is another funny thing: if you minimize the browser and then maximize it again, the game starts working faster from time to time.
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.
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...
I need to connect Google Chrome Frame to my project. It based on Canvas, a lot of big elemements.
Everything is all right, GHF works correctly, buy...
When square of canvas is greater than 216 it doesn't works correctly. E.G. if size of canvas is 256x256 or 512x128 - it works, like in Chrome.
But if size is 257x256 or 515x128 - there are nothing on my canvas.
Checked in IE7 & IE8.
Here is my test code: http://theshock.github.com/trash/chrome-frame-fail.html
Here is result in IE8. U can see, that rectangles draws correctly in smaller canvases, but larger canvasesare clear:
Upgrading to Chrome 25.0.1364.160 resolved the problem for me both in Chrome Frame and Chrome standalone.
Doing performance profiling using the chromium tracing panel I've found many image resizes, especially on scroll.
I've removed all (I think) of the image resizes from the front-end, and simplified the dom for testing purposes to be mostly just static image elements at this point.
I have a few theories:
All images resize/resample internally
looking at the chromium source, I've found evidence that everything is calling "NativeImageSkia::resizedBitmap"
Using a retina display mac causes the images to be sampled up
This is backed up by seeing a "dst_pixels" size 4x the src_pixels in the tracer
Can someone confirm or deny any of the above?
Also:
Is it possible to track down which image is being resized?
After working with some of the guys at google I've determined that this is in fact a webkit bug related to the handling of the high PPI monitors on the retina macbook pros.
You can see on a non-retina display (same mac, external monitor) there are only "Image Decode" events. Same content, same mac, rendered on the retina display you can see there are both "Image Decode" and "Image Resize" events.
Tested with 24 and 25.0.1329.0
Also, it is currently not possible to find out what image is being resized from the runtime instrumentation in chrome.