Scaled image rendering is slow

RESOLVED DUPLICATE of bug 121015

Status

()

Core
ImageLib
RESOLVED DUPLICATE of bug 121015
17 years ago
4 years ago

People

(Reporter: Francisco León, Assigned: Stuart Parmenter)

Tracking

({perf})

Trunk
mozilla1.0
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-20mdk i686; en-US; rv:0.9+)
Gecko/20010522
BuildID:    2001052213

Image rendering on some images is done really slow. I have an amd 1.2 with 256mb
on ram using linux and that url chokes my pc.

Reproducible: Always
Steps to Reproduce:
1.Go to that url
2.Scroll up and down past the image


Actual Results:  Rendering is done ok in this build, but too slow

Expected Results:  Faster rendering

Am i asking too much? Netscape 4.77 renders this image as i expected. Fast!
Check it out yourselves

Comment 1

17 years ago
believe thsi would be imagelib not image conversion
Assignee: mjudge → pavlov
Component: Image Conversion Library → ImageLib
(Reporter)

Comment 2

17 years ago
Ok, right about the component type. How about checking the bug too? :)
Mozilla really renders slow images. And sometimes they get cut and garbled, and
fix if you scroll up and fown past the image and then go back. I bet this bug is
already filed (the garbling of the images)

Comment 3

17 years ago
Perhaps a dupe of 81342?
(Reporter)

Comment 4

17 years ago
No way. Image looks good, but scroll up and down when it's loaded. I guess there
may be a memory leak around. It's hellish slow!

Comment 5

17 years ago
this linux build wont even load the image. (2001052606).. i think its getting
stuck somewhere else in the transaction rather than on the image... been 4
minutes with no luck...

Comment 6

17 years ago
this linux build wont even load the image. (2001052606).. i think its getting
stuck somewhere else in the transaction rather than on the image... been 4
minutes with no luck...
(Reporter)

Comment 7

17 years ago
Yes, i saw the same thing on the early may 26 build, this is getting worse!
Konqueror loaded the page quick and fine.

Common developers, pay attention to this one
(Reporter)

Comment 8

17 years ago
Yes, i saw the same thing on the early may 26 build, this is getting worse!
Konqueror loaded the page quick and fine.

Common developers, pay attention to this one

Comment 9

17 years ago
I saw the same bug. (build ID 2001052411).

The page at the url provides the image at 4 different resolutions. All all them
but the biggest (1152X864)
scroll very slow after loading. The (1152X864) one scrolls perfectly!!! 

In Netscape everything is fine.
(Reporter)

Comment 10

17 years ago
http://www.angelfire.com/hi/CristianCastro/

Try to look at that webpage.
On my amd 1200mhz system, this one brings it to its knees
Besides the speed, look at the wrong rendering of the images (this is another bug)

Comment 11

17 years ago
For the digitalblasphemy URL, the different sizes are all being done on the
client side with height/width tags.  There's some issues with resized images on
linux, see bug 74313.

Comment 12

17 years ago
I was asked to comment:
testing with a linux CVS build including patch in att. 37860 from bug 74313
I see no problems on the page in URL field. It loads, scrolling is quick.
Nothing unusual. (P3/500, 512MB RAM)
(Reporter)

Comment 13

17 years ago
Well, i tested with 0.9 and lots of builds until 0.9.1, and rendering is very slow
athlon 1200mhz/256mb ram here

Also have a fast video card, latest drivers and X too
If only i would be smart enough to make a quick video of it...

Well, you are using a quick patch that was made like an hour ago
All you need to do is test the same url with commercial 0.9.1 build to see if
you can see the problem

Comment 14

17 years ago
I tested it with the patch from bug 83920 and it's probably a little bit better
but it could be improved more. The patch from bug 74313 uses XIE and therefore
it's doomed.
Please mark it dependent on bug 83920 I don't have rights to do it.
(Reporter)

Updated

17 years ago
Depends on: 83920

Comment 15

17 years ago
Confirming with Linux nightly 2001061821. CCing Tor if he could do something
with it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Summary: Image rendering is too slow → Scaled image rendering is slow

Comment 16

17 years ago
We're always redrawing the entire image when scrolling a scaled image instead
of just the dirty areas.  The responsible code is in pavlov's arena.
(Reporter)

Comment 17

17 years ago
CCing pavlov due to comments
This is one of those bugs that people want to get fixed
(Reporter)

Comment 18

17 years ago
Why cant i enter digitalblasphemy.com?
Other browsers can get in fine
(Reporter)

Comment 19

17 years ago
Finally could get in. The page now renders faster with the fixes from bug 83920
but it's still too slow compared to netscape 4.77

Comment 20

17 years ago
*** Bug 81804 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla1.0

Comment 21

17 years ago
Attached is a patch which uses the dirty rectangle when doing scaling
to minimize the amount of work that needs to be done.  It relies on
the platforms gfx implementation ability to handle a non-origin scaled
image draw request.

If you try it with the gtk port, the new chunks don't exactly match
the old image.  Not normally visible, but if you do a xrefresh or a
diff between snaphots before/after an expose you'll see the
variations.  I think that's just due to the pixel replication scaler
in gfx/gtk not adjusting for the non-zero origin.  Could probably be
fixed by tweaking the initialization of 'e' in the scaler.

There's also a possibility that the rectangle calculation in this
patch is wrong.

Attaching patch so I don't loose it in my tree and for other eyes to
examine.

Comment 22

17 years ago
Created attachment 39861 [details] [diff] [review]
make scaled images use dirty rect

Updated

17 years ago
Blocks: 91351

Updated

16 years ago
Blocks: 71668

Comment 23

16 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 24

16 years ago
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0

Comment 25

16 years ago
The link no longer shows a scaled image.  I went ahead and created a new one for
the same image:
http://www.xsta.cc/mozilla/bug82278.html
(Reporter)

Comment 26

16 years ago
You have little imagination. That url lets you choose the resolution you want,
so click for example on 1024x768 and there you go
Blocks: 124140
(Assignee)

Comment 27

16 years ago
this should be a lot better with tor's patch
(Assignee)

Comment 28

16 years ago
this was fixed by bug 121015

*** This bug has been marked as a duplicate of 121015 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.