Open Bug 1253394 Opened 8 years ago Updated 2 years ago

jquery performance increases if the page is displayed in a iframe

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
44 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED
Project Flags:
Performance Impact low
Tracking Flags:
Tracking Status
platform-rel --- +

People

(Reporter: marovitosoc, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [platform-rel-jQuery]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

Spawning something like 4096 inline-block divs and then animating the scrollTop of the entire page via jQuery. Then attempting to display the page in the iframe of a second page.
Posted working code in this stackoverflow question: http://stackoverflow.com/q/35781700


Actual results:

The framerate of animating scrollTop of a page containing thousands of divs increases if that page is displayed via an iframe by a large margin, like 2 to 3 times.

Can't provide a live example as most hosting services like jsfiddle use iframes themselves, which isn't optimal for this case.


Expected results:

i expect the performance should be at least equal.

Things to notice:

1) In both cases, if i manually scroll the pages with my actual finger it goes very fluid at max framerate.

2) there is no scrollbar when visiting the page with the iframe. Not sure if it has anything to do with the issue.

3) Chrome mobile doesn't present any issue.

4) cannot reproduce on desktop version of firefox.
Flags: needinfo?(kbrosnan)
Whiteboard: [platform-rel-jQuery]
platform-rel: --- → ?
Taking a stab at the right component.
platform-rel: ? → +
Component: General → Layout
Product: Firefox for Android → Core
Posting some URLs to narrow this down...

The basic test file returns the elapsed time for the scrollTop animation:
http://media.junglecode.net/test/1253394/source.html

A page that loads the test file above in an iframe:
http://media.junglecode.net/test/1253394/test.html
We tested in Firefox for Android version 50b10 and don't see a significant difference between the two tests. Please confirm that we've configured the test environment correctly.
Flags: needinfo?(marovitosoc)
(In reply to Jet Villegas (:jet) from comment #3)
> We tested in Firefox for Android version 50b10 and don't see a significant
> difference between the two tests. Please confirm that we've configured the
> test environment correctly.

Good day
what you should look for is the choppyness (framerate) of the animation, not the time between start and end, as jQuery will attempt to meet the duration value regardless of the device's performance or framerate on display afaik.
I also noticed that in source.html the duration of the animation is set to 1200 instead of 12000, a slower and long animation can be more useful to determine the difference.
I should have specified that i tested on android 4.4.4 on a galaxy S4 Mini, processor Snapdragon 400 (8930AB).

I just cobbled together this alternative source.html that uses requestAnimationFrame instead of jquery's animate.
Features a frametime meter in the top for easier checking (retested right now with latest firefox mobile version 49.0.2 and jquery 3.1.0 and on my end the difference is still 2x from 60-70ms to 130-150ms per frame):

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script>
</head>

<body>
<div style="position:fixed; display:inline-block; left:30px; padding:5px 10px; background-color:red; font-size:25px;"><button style="font-size:100%;" onclick="ended = 1;">Stop</button> <span id="u"></span></div> 

<div id="saa">
<div class="v" style="width:30px; height:10px; background-color:grey; display:inline-block; vertical-align:middle;"></div> 
</div>

<script>
var ended = 0;

window.onload=function(){
	var e = $('#saa').contents();
	for (var i = 0; i < 12; i++) {
		e.clone().insertAfter('.v');
	}

	var prev = (new Date()).getTime();
	var curr = 0;
	var scrollpos = 0;

	function step() {
		curr = (new Date()).getTime();
		$('#u').html(curr-prev);
		prev = curr;
		scrollpos += 1;
		scroll(0, scrollpos);
		if (ended == 1) {return 0;}

		window.requestAnimationFrame(step);
	}

	window.requestAnimationFrame(step);
}
</script>

</body>
</html>
Flags: needinfo?(marovitosoc)
Rank: 10
Flags: needinfo?(bugs)
Can we get a re-test on this one now that bug 1285874 is fixed?
Flags: needinfo?(bugs) → needinfo?(marovitosoc)
(In reply to Jet Villegas (:jet) from comment #5)
> Can we get a re-test on this one now that bug 1285874 is fixed?

Just tested on nightly 55.0a1. Performance is better compared to 52.0 in the source page, but there is still a 30-40% observable increase when viewed through the iframe (i now get average 80ms on iframe page and 110ms on source page).
I also noticed that interacting with the touchscreen causes the iframe page to permanently drop framerate to the level of the source page so that the iframe page reads 10% worse performance than the source page (around 125ms), which is more in line with the expectation, up until manual page refresh.

Here are simpler pure javascript versions of the two test scripts.

iframe.html:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>

<body style="margin:0;">
<iframe onload="this.style.height = (window.innerHeight-10) + 'px'" style="width:100%; border:none; margin:0;" src="source.html"></iframe>
</body>
</html>


source.html:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>

<body style="margin:0;">
<button style="position:fixed; left:30px; top:10px; font-size:30px; line-height:160%;" onclick="ended = 1;">Stop (<span id="u">0</span> ms)</button>

<div id="saa"><div class="v" style="width:30px; height:10px; background-color:grey; display:inline-block;"></div> </div>

<script>
document.getElementById("saa").innerHTML = document.getElementById("saa").innerHTML.repeat(4096);

var ended = 0, curr = 0;
var prev = (new Date()).getTime();

function step() {
	curr = (new Date()).getTime();
	document.getElementById("u").innerHTML = curr-prev;
	prev = curr;
	scrollBy(0, 1);
	if (ended == 1) return 0;
	window.requestAnimationFrame(step);
}

window.requestAnimationFrame(step);
</script>

</body>
</html>
Flags: needinfo?(marovitosoc)
Whiteboard: [platform-rel-jQuery] → [platform-rel-jQuery][qf]
Whiteboard: [platform-rel-jQuery][qf] → [platform-rel-jQuery][qf:p1]
(In reply to daddytunz from comment #0)
> 4) cannot reproduce on desktop version of firefox.

Setting [qf] in case this was an oversight.
Whiteboard: [platform-rel-jQuery][qf:p1] → [platform-rel-jQuery][qf]
Whiteboard: [platform-rel-jQuery][qf] → [platform-rel-jQuery][qf:p3]
Keywords: perf
Flags: needinfo?(kbrosnan)
Performance Impact: --- → P3
Whiteboard: [platform-rel-jQuery][qf:p3] → [platform-rel-jQuery]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.