I'm running an animation using Kineticjs using the Animation module. Now I noticed there quite a big performance difference between Chrome and Firefox. Looking at the framerate I found the following results.
Chrome Firefox
avg: 50 50
min: 33 20
max: 56 75
As you can see, the variability of the framerate for FireFox is a lot bigger. The animation in Chrome is smooth (at least smooth enough), but the animation in Firefox is choppy every second or so, this happens when the framerate is very high or low.
Especially the high framerate spikes seem to ruin the appearance of a smooth animation.
Has anybody else experienced this behaviour? And is there a way to smooth the framerate out a bit more in Firefox?
This could be due to browser tab architecture differences, such as the fact that currently Google Chrome uses a separate process for each tab, so slow or bad code in one tab is far less able to affect code in another tab. With Firefox tabs are run in the same process, so slow code on one tab can affect other tabs.
This could also be due to browser performance differences, meaning the implementation of DOM and Javascript APIs that you are using.
is there a way to smooth the framerate out a bit more in Firefox?
You should try to find some causes for the difference in the framerate, process of elimination is probably the best path.
Try using the browsers with only one tab, and go through the list of apis used to see if there are performance differences for those.
Related
I am building a website for me and I care about performance, speed, user experience and a lot more. When I started I didn't know much and I made an initial design using adobe xd. Then using webexport plugin I got a html file that has 2k+ lines of codes for scale to fit any screen and proportional resize of everything. I think I made a 1080p standard artboard but somehow it was way too big like 3554px by 2216px. So the webpage is now that big and scaling is running on it. I don't think it's too big for a browser to handle. Things were good before chrome 97 or 96 update. After that chrome and any browser running on chromium just can't scale my webpage fast enough to fit the screen. I see big divs getting smaller and it takes kinda like 500 ms to settle with decent setup. A lot of variables can affect the performance like if the machine(pc) and network is slow the scaling takes couple of seconds which is too much.
Is there any way to hint the browser to do the scaling first then make the page visible? The older version of chrome was doing it right. I can make the page visible after 600 ms using setTimeout function but doesn't seem what I want.
CSS
will-change: transform;
Tried this but it has bad effect like blurry text on my content. I don't know why it's pushing the browser to it's limit sometimes, maybe I can better optimize my page but these browsers should be more powerful (safari is the worst - can even render the webpage)
This is the home page
https://elomymelo.com/
You should see big page fitting inside the screen and it'll probable take 200 ms pretty fast
proportional resize on window also works
This is a heavy article page
https://elomymelo.com/oneplus%20nord%20review.html
I tried to hide the scaling effect in this page but not satisfied because browsers mess up sometimes. I need the javascript scaling done much faster like visitors will not see that weird transition.
I'm currently working on a small canvas game written in pure javascript from scratch.
The game involves a 2d lighting algorithm similar to this one, but with one light source and 25 polygons which makes for about 30,000 calculations per frame.
My frame rate is great in Safari, meh in Chrome, and unplayable in Firefox. However, if I have the Chrome developer console up while playing the game, the frame rate is the same as Safari.
What could be the reason for this?
After the comments suggested the window size might be affecting the frame rate, I found out that the smaller the window, the smoother the game runs but only in chrome. The amount that is drawn on screen or any calculations used by the game don't depend at all on the screen size.
I measure the frame rate difference purely by eye, and you can see the effect in these gifs:
Bad, big window:
Good, small window:
The game runs much smoother in the browser than is apparent in these gifs, but the effect is still noticeable.
I can get the same effect to happen with the first example in the link that I posted. Is it just me or does anyone else get the same effect?
Even stranger... I gotten the same effect on several other websites, like Facebook when I scroll the home feed. The bigger the window, the choppier the scrolling gets. Is this a Chrome specific thing, is anyone getting similar results?
I've seen this as well in my pages/applications. The issue seems to apply to anything, but is more pronounced with canvas and accelerated CSS. As far as I can tell, this issue is a performance bug relating to Chrome's composited layer rendering. Basically, Chrome breaks the page up into layers and uses the GPU to render those layers. You can see these by enabling the "Show composited layer borders" option in the "Rendering" tab on the dev console. Chrome's FPS performance decreases as the number of composite layers increases, regardless of the layers changing or not.
Here's an independent example. Steps to reproduce:
Load this page in Chrome, it's a relatively simple animated CSS demo that is a fixed size like your game: http://www.subcide.com/experiments/fail-whale/
Bring up the Chrome developer window (pop it out so it's an independent window) and enable the "Show FPS meter" option.
Size the window small so that it just contains the fail whale demo. Note your FPS.
Now size the window large or full screen it. Note your FPS.
With a small window, I get 55 FPS. Full screen, I get 34 FPS. I would expect the FPS to be nearly the same, regardless of the page size as the animated area doesn't change. The FPS seems to be proportional to the number of composite layers on the visible screen. Also, resizing the window results in the animation being chunky and skipping frames. If I perform the same window resizing in Safari, the animation stays smooth. Safari knows there's nothing new to render, while Chrome is seemingly doing a bunch of work for no reason.
So the reason why you see better performance when your dev console is open is because you have your dev console inline/embedded with the page, which makes the page itself smaller when it's open. This results in a page with fewer composite layers for Chrome to handle, which results in better FPS. If you pop your developer console out so it's an independent window and doesn't affect the page size, your FPS won't be affected by the dev console being up or not.
This appears to be the "why" this is happening. Now, if anyone figures out what can be done about this, I'd certainly be interested to know.
I'm trying to build a homepage that has a lot of moving elements. I've checked other websites that have the same moving animations do the same technique e.g. move stuff on setInterval(). But I don't know if it would be ok, on my computer its running smoothly. But I don't know if it would cause any damage to other users specifically slow computers. I say this because when I opened the site on my phone it got hot real fast.
I made a fiddle where you can see what kind of simple movements are happening but how fast the functions are executing. The fiddle only shows 4 elements but the homepage has about 10 more elements moving.
So what would be good practices to follow when implementing these kinds of website animations?
setInterval would be fine if you target old browsers, but it's not meant for animation. Some browsers cap it to 4ms. Some won't slow down when the window is not focused, so it will eat up CPU cycles, and therefore power - not good when you're on a mobile device.
There's requestAnimationFrame, a timer that's optimized for animation. Animation slows down or halts when the window is not in focus, and it aims to draw at 60fps.
For minor, non-behavioral animation (style, rather than behavior), you can do CSS animations instead. One nice thing about CSS animations is that some of them, especially the ones that deal with 3D, are GPU accelerated, making them faster and smoother than your make-shift JS animations.
I just finished a website: http://www.basenharald.nl and all is good in IE9, chrome and firefox.
It does not support browsers < IE8, but that is planned.
However the website is really really slow in IE8 and for some reason some people encounter that the scrolling divs do not work (not all IE8 users).
Any help on these issues would be greatly appreciated since i cannot locate the problems.
Because IE8 just renders these animations VERY poorly. Also slow PC's will have issues with the animations.
You should detect IE8 (and lower) and disable those effects, because they are not functionally necessary
First of all well done on a good looking site. I have used Developer Toolbar in Chrome to detect the following problem. Your site uses or reference a page called daddy-shoutbox.php. This code in this page or calling code to this page is causing a infinite loop or continues call. From my results I could see that that page takes on aggregate about 500ms to load.
From the browser perspective I can only assume that IE8 actually shows the symptoms of this loop. My stats showed that the page has made over 130 requests and counting after 2mins.
Not modern browsers and, as douwe said, even slow PCs will be affected.
The parallax animation requires lots of CPU time and the effect is mainly related to the aesthetics of the website.
A good compromise between usability and aesthetics could be achieved by reducing the parallax effect.
I suggest you to remove the effect from the text ( class: contentwrapper). It will save you some CPU time and it will give you a more readable text.
You could even switch to a normal scroll bar. For my experience, customized scrollbars, always give some trouble with the users ;)
If you are happy with the experience on the modern browsers, you could simply discriminate older browsers.
With jquery you can use this
good luck
In Opera 11.52 it doesn't load at all..
I'm using jQuery .scrollTop to scroll image within a div. It works great in Firefox - scrolling is very smooth and fast. In IE 8 scrolling is very slow and glitchy - image scrolls once in about a second - two seconds. Image size is on average between 2000 * 2000 and 4000 * 4000 pixels.
Is there a way to improve this for IE 8?
Performance in IE 7 is slightly better, but still not good enough.
Thank you
Edit: I believe that an issue is in how scrolling is implemented in IE 7 and 8. I have enabled both scroll bars (overflow-x and overflow-y), and I have tried scrolling an image using these scroll bars. Issue is exactly the same. I've tried running this on a fairly underpowered PC - pentium dual core few years old with 2 GB of RAM as well as Core i7 desktop with 2.8GHz CPU 1600Mhz RAM and the results are nearly identical. FireFox scrolls a lot faster, however its CPU usage on average is 10% higher than IE CPU usage. This leaves me puzzled...surely Microsoft would have addressed this issue by now?
Another thing that I have found slightly odd is that scrolling ran faster on a Core 2 Duo laptop. I'm wondering whether this has anything to do with graphics card drivers...does IE 7/8 even make a use of GPU?
Excuse me if any of this sounds silly, but I'm really interested in solving this problem...IE can't be that bad..
jQuery's .scrollTop() is notoriously slow in ie, and if the markup is even slightly complex or large, you'll never get it to perform well.
The solution is to not use the jQuery .scrollTop() function, but build your own based on the native properties .scrollHeight and .scrollTop.
The reason is the way ie computes offsets, which is the base of jquery's .scrollTop() slowness - you have to walk up the DOM tree and calculate offsets for every parent in ie.
jQuery does this the best it can, but you will always be able to do it faster since you know the markup in advance and can optimize this - you can even do the offset calculations in advance most of the time and just use a constant as modifier.
All that said, this might not be jQuery's fault - it can simply be a problem with ie's rendering pipeline - depending on how you made your marklup and styling of it, a scroll might force ie to completely rerender/repaint the page for every pixel you scroll, and that will slow it all down to a crawl.