Closed Bug 317398 Opened 19 years ago Closed 16 years ago

Large svg does not scroll properly

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ologgio, Unassigned)

References

()

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

The attached SVG file loads correctly, but does not scroll properly. It takes a long time for the browser to repaint when the scroll bar is moved, and the repainting fails sometimes.

Reproducible: Always

Steps to Reproduce:
1.Load the attached file
2.Try to move the vertical scroll bar
3.

Actual Results:  
The repainting of the browser is very slow or fails
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051121 Firefox/1.6a1 ID:2005112103

I see the same.
Assignee: nobody → general
Component: General → SVG
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
Attachment #203910 - Attachment mime type: image/svg → image/svg+xml
Severity: normal → critical
The problem also occurs with Firefox 1.5 on Windows XP.

I have attached another SVG file which renders at 557px by 6090px and demonstrates the problem. Firefox 1.5 becomes *completely* unresponsive and hence unusable when an attempt is made to view that file.
Please could someone change the platform to All, as this occurs on Windows XP as well as Linux.
OS: Linux → All
I've changed this back to Linux from All since it now scrolls just fine for me on WinXP. Can a few other people test too?
OS: All → Linux
The original testcase scrolls fine.

The second testcase is quite slow scrolling due to its use of feGaussianBlur on   some extremely tall objects (~6000 pixels high).
(In reply to comment #7)
> I've changed this back to Linux from All since it now scrolls just fine for me
> on WinXP. Can a few other people test too?

Scroll usability with Firefox 2 is, in fact, very low with both test cases. Firefox 3 makes first attachment pleasant to scroll, although scroll in second attachment is still somehow slow - which is perfectly acceptable, IMHO, given the document itself - huge, both in canvas size and complexity (comment 8). 

Tested in both Windows and Linux. Hardware description included also, as scrolling performance, given these test cases, is tightly related to processing power.

As the report refers to broken scroll behavior, maybe this issue could be marked "fixed" or even "invalid" - as the scroll behavior was never broken but simply unusable.

Versions:
Firefox 2 (Windows) - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Firefox 3 (Windows) - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9pre) Gecko/2008040805 Minefield/3.0pre
Firefox 2 (Linux) - Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.8.1.13)
Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13
Firefox3 (Linux) - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre)
Gecko/2008040804 Minefield/3.0pre

Hardware:
Windows - Pentium IV 3.0GHz processor, 1GB RAM
Linux - Pentium M 1.6GHz processor, 512MB RAM
Marking as WFM then as performance would seem to be fixed by unknown check-ins.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: