Comment 202 for bug 125970
Revision history for this message
|
|
#202 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
> Yes that's the case.
>
> Maybe it should be slow then... regarding the mess in the code. After reading
> comment #122 this slow down could definitly be normal and justified. And a few
> people have probably been convinced that it's not a firefox problem.
>
> The code is a mess and is pretty heavy, there's a fixed div with a png
> background, and there a png background. It's slow. Without the images it's
> better but still slow.
> So I actually have 2 'bugs' here at the same time.
Or maybe the position: fixed bug has been fixed.
> But both of them have a big
> impact on performance.
Correct and appropriate QA bug management indicate that we shouldn't confirm a bug unless a set of conditions are met, a good, clear testcase, thorough search for duplicate has been done, etc.
> I'm posting this because Firefox 2 handles it perfectly fine.
>
> Like W. Brackets did, comment #124, rolling the scroll wheel as fast as
> possible, the time it took to scroll from top to bottom of the page, retried, 3
> or 4 times if any difference:
>
> Smoothscroll on
> FF 2 about 5, 6 seconds, slightly slower than whithout smoothscrolling.
> FF 3 2008052304 took an astonishing 48 seconds the first time and 50 seconds
> the second time I tested it. Where 20 seconds are spent on the last 200px of
> the page. 8 times slower?
> We knew already that smoothscrolling did that, but I didn't really expect it to
> be this bad. Redrawn once per second as well, not worse then with smoothscroll
> off, but the distance scrolled at each redraw is a lot smaller.
>
> Smoothscroll off:
> Firefox/2.0.0.11 20071127: between 3 and 5 secondes, redrawing maybe 4 or 5
> times a second.
> Firefox 3 2008052304 after trying several times: between 13 and 15sec to scroll
Then that is bug 202718, not *this* bug. Discussion, data, comparison regarding smoothscroll ON or OFF should not be in this bug.
> The website where I get this is on the intranet.
Realistically speaking, there is nothing to be done without being able to examine, investigate, test, performance-profile a webpage. We still would need a reduced testcase focusing and targeting (and highlighting) well the performance + behavior considered as incapacitatingly slow.
> I will try to upload a new archive containing the images/html/css files,
> stripped from the private information.
Please consult
What is a Simplified Test Case, and How Do I Make One?
http://
How many of you have read
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://
I believe that attachment 139911 and this bug's URL
http://
were adequate webpage and testcase for this bug. If no one experiences significant (measurable) loss of performance in those webpages with a trunk build, then this bug should be resolved as WFM.