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...
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 have a situation where the CPU used by firefox jumps up to about 50% and does not decrease when I go to my app's tab. The app is idle, I am not clicking on anything, and no requests are being made. Yet the CPU does not drop.
I used Firebug to profile what was going on, but it returned that there was no javascript calls.
So then I used the most recent Performance profiler in Firefox 40. Running the profiler for about 5 seconds then stopping showed that the gecko engine was sending lots of calls to "Recalculate Style", specifically the hint given was that it is related to CSS Animations. See screenshot:
I need to find out what is causing this because I believe it is inherently slowing my app down. However, I am not sure what to do next in order to track down the issue.
Thanks
Problem turned out to be an animation that was off screen but Firefox was still burning CPU calculating the keyframes etc.
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)
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.