Okay, so I'm running into a weird issue with a game I'm developing all of the sudden, I'm just wondering if anyone has seen something like this before:
When my window is sized below ~600,000 pixels, it runs very smooth. This is a profile taken at 989x610px:
When my windows is sized a little bit up from that, it slows to a halt, using 99% CPU and running at like 7fps. This was taken at 990x610px (1px wider):
The 990 isn't hard-coded anywhere, because the exact width that it slows down at is dependent on the height, it's more of a "total pixels" thing.
Anyway, I'm just wondering if anyone has seen this before, if it's a known issue, or if I should be filing a bug report with the chrome team.
When your window is that size or when your canvas is that size?
Either way I'm guessing its merely a Chrome bug and you should file a bug report. You should also test to see if its working on Chrome Canary.
There have been similar bugs in the past, such as this still-not-fixed bugs in Chrome for Android where the canvas has distinct functionality above and below 64k total pixels (see bugs here and here)
Related
I have an app written with Konva.js, and it works really smoothly on both my 13-year-old PC and my wife's iPhone XR - it's just perfect. But whenever I run it on my Xiaomi Redmi 9 Pro and also my older one, Xiaomi Redmi Note 4X in many different browsers including Chrome, Opera and Firefox, it is really slow. I have animations using Konva.Tween and also some draggable nodes, and both of them work unbelievably slowly, FPS seems to be close to zero.
The strangest part is, I tried moving draggable nodes to a separate layer right before the dragging starts, and it doesn't speed up dragging at all, not one bit, at least visually, I didn't measure the actual FPS. So to me it seems like I am facing a limitation of my phone's performance here or there's something else which I do not see.
What is it that might cause the issue?
First, you should run the performance profile on your phone and take a look at what exactly is slow. Konva code execution? Native 2d canvas rendering? Browser layout work?
Also try to experiment with Konva.pixelRatio property https://konvajs.org/docs/performance/All_Performance_Tips.html.
Konva.pixelRatio = 1;
The image may be blurry on HPDI device, but probably it will be good enough. Probably default pixel ratio is too high. You can try different values like 1 or 1.5.
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'
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...
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.