Possible performance improvement in rendering iframes under Linux

NEW

Status

()

Core
Layout: HTML Frames
--
enhancement
17 years ago
8 years ago

People

(Reporter: Geraint, Assigned: John Keiser (jkeiser))

Tracking

({perf, testcase})

Trunk
Future
x86
Linux
perf, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

17 years ago
I discovered the following during the development of our company's web application.

Rendering multiple IFrames with style settings position:relative and 
visibility:hidden can take less than 50% of the time taken for position:absolute
and visibility:hidden.  

I know the first is not a logical combination, it was an accident, but the
performance difference is real and highly significant and may provide a
developer with an insight for tuning Mozilla/Netscape under Linux.  

The performance difference does NOT arise under Windows NT or MacOS.
ccing jrgm for perf testing....
->HTMLFrames

If you have testcases that demonstrate this, this bug report would be much more
useful if you could attach them to the bug.
Assignee: clayton → pollmann
Component: HTML Element → HTMLFrames
QA Contact: bsharma → amar

Comment 3

17 years ago
Yes, if you could attach an example of some kind, or a little more detail 
of what you mean, then I'd be happy to look through this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

17 years ago
Created attachment 30063 [details]
Open this file first
(Reporter)

Comment 5

17 years ago
Created attachment 30064 [details]
This file is opened by mozTest12.html
(Reporter)

Comment 6

17 years ago
Created attachment 30065 [details]
This is about 40% faster than mozText12.html
(Reporter)

Comment 7

17 years ago
I have added 3 attachments as a test case - they demonstrate a 40% difference in
rendering performance between the absolute and relative position setting.

I wasn't sure of the how attachments would be named when uploaded - the example
will not work unless the second file is called 'mozTest6.html' and is saved in
the same directory as the other 2 files.  Note that I have called the first
file mozTest12.html (hence the reference to this filename above!)

It is a rather contorted example but demonstrates the effect.  The effect does
not require this many IFrames to be created to demonstrate the time saving - in
our proprietary application I see a larger time saving effect with only 7-8
IFrames but their content is dynamic (and not cached as the static
mozTest6.html,in the test case attached, would be).

I hope these examples help.

Updated

17 years ago
Target Milestone: --- → mozilla0.9.2

Comment 8

17 years ago
Created attachment 35754 [details]
40% faster file for viewing from bugzilla

Comment 9

17 years ago
Created attachment 35755 [details]
mozText12.html equivalant for viewing from bugzilla

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 10

17 years ago
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Updated

16 years ago
Keywords: perf
Target Milestone: mozilla0.9.4 → mozilla0.9.6
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
Status: ASSIGNED → NEW

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla1.1

Updated

14 years ago
Keywords: testcase

Comment 13

14 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future
roc, this sounds like painting fun....
QA Contact: amar → layout.html-frames
You need to log in before you can comment on or make changes to this bug.