I've been working on a Skrollr site but it appears to be getting excessively jerky. I've had dev tools open and have found a few really really slow frames, but I don't have the knowledge to track down exactly what is going wrong.
My observations are:
it is slower scrolling down than up
intermittently it is absolutely fine
So far I have tried a few things
Given the first segment a translateZ value to try and separate out the paint (I have no idea if this is correct – I'm really at the limit of my knowledge!)
Had a go getting rid of the relative animations (data-top-bottom etc) which could well be slowing things down, but after changing everything back to static numbers (data-1000 etc) its still almost identical
Can anyone shed any light on this? The URL is http://fieldviewfestival.co.uk/500 ... power up!
I think I've fixed it!
The webfonts weren't fully loaded when skrollr kicked in. After initializing it I added a
$(window).load(function(){
Where I refreshed skrollr I then added the following:
s.refresh();
I think the main problem was that the height of the page wasn't calculated by the time skrollr kicked in.
Also I had a strange scrollbar left over (so a scrollbar on the body AND html), which skrollr hadn't removed so I also added above that function
$(window).trigger('resize');
The final initialize looks like this:
var s = skrollr.init();
$(window).load(function(){
// console.log("Loaded");
$(window).trigger('resize');
s.refresh();
});
NB Silly miskate I made as well, don't use the function $(document).load(
Related
https://codepen.io/chrisjdesigner/pen/ExNPqBx
// Old Film Look
filmPass = new THREE.FilmPass();
composer.addPass(filmPass);
In this example you can see it and it's something I've been having in my own tests as well. I'm not sure if it's only tabbing out or if by leaving the computer idle it eventually turns like that.
The way to replicate it is to open the demo, leave the tab for a while and after 15 minutes or so, when you return to the tab, the noise will look displaced and forming patterns
. Chrome latest version.
My assumption is that the requestanimationframe is causing this issue, but I wouldn't know what to tweak to fix it.
Anyone got a pointer?
It appears adding a deltatime to the render alleviates the issue greatly.
I’m working on a complex project in threejs.
Trying to cut the corner:
I have to load an obj, create some pivot point to use as parent of the mesh inside this obj, let the user move and rotate the pivots.
It takes somewhere about 10 to 15 seconds to load due to its complexity.
My problem is that it is working flawlessly if I load the page and don’t change the focus, but if I change the browser tab or collapse the browser window I got a very specific problem:
geometry.computeBoundingBox() gives different results.
Is there someone who can help me figure out what’s happening?
To help you better understand the situation: at loading time I have to rotate the obj to -90° on the X axis (inverting Y and Z as a consequence); I think it’s relevant because the boundingBox calculation somehow inverts Y and Z and changes its min and max also, but as I said only if I switch tab or collapse the browser.
p.s. No matter the OS nor the browser. It’s a super consistent bug
Ok, I somehow solved the issue, but take it with a grain of salt:
the problem can be tracked back to the execution stack of javascript:
the first function computes the bounding box, the second uses this computation, but if the first function is somehow slower to execute, the second could not have what it needs.
What I did is to force javascript to execute functions in a given order and only when the previous is finished.
The problem occurred only when changing the tab because browsers optimize resources of non visible tabs, but the code I wrote was anyway too much entropic to work properly.
I hope what I found will be understandable and useful to someone else in future.
... and I've scoured the web for answers.
I boiled down the problem as much as I could in this jsfiddle:
https://jsfiddle.net/tko8rk5j/14/
There are 2 button, you click Go then Boost.
I'm trying to get the whole svg back to its initial position after the end of the Boost animation, so you can play the same sequence again and again.
I attempted various solutions suggested in other posts:
// tl.pause(0);
// tl.restart();
// tl.remove();
I also tried using the repeating TimeLineMax, but that just repeats the first animation sequence after the first click on Go button.
I'm not quite sure about what you're ultimately trying to do (which could greatly influence how I'd recommend building this effect), but here's a fork that I believe delivers the result you were asking for:
https://jsfiddle.net/2q1qrvty/7/
Your code was jumping back to the beginning before your animation even had a chance to run at all. Plus it was re-using the same timeline and constantly adding to it which isn't very efficient.
To make it go back to the beginning and stop as soon as it's done, just use an onComplete callback, like:
tl.eventCallback("onComplete", function() {
tl.pause(0);
});
There are a bunch of other ways to do this, but I don't want to overwhelm you :)
You may have better luck asking your questions in the dedicated GSAP forums at https://greensock.com/forums/
Happy tweening!
Basically I am downloading a zip file and extracting a collada file to load in the browser. This works freaking awesome in chrome but is REALLY slow with model movement from the mouse in Firefox. I cant seem to figure this out or if there's a setting I'm missing to speed up Firefox or what. The file is loaded up here
http://moneybagsnetwork.com/3d/test.htm
Its using jsunzip and three.js to load everything. I've bypassed the jsunzip and that's not the issue. I've also dumbed down the model to not use any event listeners and no lights and that didn't help one bit. Completely stumped here and the model really isn't that big :/
Here is a link to a zip of the files I'm using
http://moneybagsnetwork.com/3d/good.zip
Sorry about the multiple commented lines. I might turn things back on if this gets fixed.
I have noticed that Chrome is usually way faster and more responsive with Three.js applications than Firefox. The difference is not so much on the WebGL side, but at the plain Javascript supporting code.
Looking at your code, it seems you do some very heavy javascript stuff on your onmousemove function. This could very well cause much of the performance gap between the browsers. Mousemove is executed many many times during each and every mousemovement, so it quickly adds up to slow performance. It could also be that Firefox actually creates more mousemove events for similat cursor movements (not sure).
You could either move most of the raycasting and other stuff from mousemove to mouseclick. Alternatively, you could implement a delayed mousemove so that the function is called only maximum of X times per second, or only when the mouse has stopped. Something like this (untested but should work):
var mousemovetimer = null;
function onmousemove(event){
if (mousemovetimer) {
window.clearTimeout(mousemovetimer);
}
mousemovetimer = window.setTimeout(delayedmousemove, 100);
}
function delayedmousemove(event) {
// your original mousemove code here
}
Maybe your graphics card is in our blacklist. There is usually a note about this towards the bottom of about:support.
Cards can be blacklisted for various reasons, missing drivers / features, occasional crashes ... see:
http://www.sitepoint.com/firefox-enable-webgl-blacklisted-graphics-card/
To enable WebGL, set webgl.force-enabled to true.
To enable Layers Acceleration, set layers.acceleration.force-enabled to true
To enable Direct2D in Windows Vista/7, set gfx.direct2d.force-enabled to true
I’m building a mobile web application, and even though I’m still in a prototyping kind of the process, I’m having a hard time fixing certain performance problems.
The application itself (works all smooth in desktop browsers, but significantly sluggish in Mobile Safari): Hancards webapp prototype. You may login as mifeng:wangwang or create a new user.
The overall clumsy performance could be tolerable though, except for one thing: the browser simply crashes (!) when you open a set page, tap ‘view’ (enlarge all cards) and then try to go back to the previous page.
The code that gets executed when ‘view’ is tapped is this (very sluggish by itself as well; any way to improve it?):
if ($(this).hasClass('big')) {
$('.card').unwrap().removeClass('big flippable').addClass('small');
$(this).removeClass('big');
}
else {
$('.card').wrap('<div class="bigCardWrap" />').removeClass('small').addClass('big flippable');
$(this).addClass('big');
}
And another thing, a pretty weird bug. Very often the ‘word of the day‘ block won’t display the text node for the last element (<div class="meaning">), even though it’s in the code. The text will not show unless you ‘shake’ the DOM anyhow (unticking and ticking back one of the associated CSS properties can also achieve that). This happens in both desktop and mobile Safari browsers.
The code that writes it in there is this:
// While we are here, also display the Word of the day
$.post('ajax.php', {action: 'stuff:showWotd'}, function(data) {
// Decode the received data
var msg = decodeResponse(data);
// Insert the values
$('.wotd .hanzi').text(msg.content[0]['hanzi']);
$('.wotd .pinyin').text(msg.content[0]['pinyin']);
$('.wotd .meaning').text(msg.content[0]['meaning']);
});
I don’t expect you to advice me on how to fix the performance of the whole application (I will probably have to revise the overall scope of the project instead of trying to find workarounds), but I at least would like to see how to solve these two problems. Thank you!
The only performance issue I see in the script is the wrap/unwrap calls - adding and removing elements from the DOM tends to be fairly slow, and you can probably get the same effect by always having a wrapper element and changing its class rather than adding or removing it.
However, the performance issues you are seeing are most likely in your css:
3D transforms can be much faster than 2D due to hardware acceleration. It looks like you already have this, though you do need to be careful about which elements it is applied to
Shadows have real performance issues, especially when animated. Removing them will probably fix most of the slowness.
Rearranging background images can help - A single background image under transparent pages is faster than having a background image for each page.