Image display is 50-100% slower than 4.x

VERIFIED FIXED in M14

Status

()

P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: elig, Assigned: pnunn)

Tracking

({perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
* TITLE/SUMMARY
[4.xP] [Perf] Image display is 50-100% slower than 4.x

(noted by sfraser)

* STEPS TO REPRODUCE
0) Launch Apprunner
1) Display a decent-sized (e.g. 100-200K) image. An example image is attached to
this bug.

* RESULT

*Approximate* performance results were (using 19991111xx builds):

Mac OS:
        * Communicator (4.7): 2-4 seconds
        * Internet Explorer (4.5): 4-6 seconds
        * Seamonkey: 10-12 seconds

Windows:
        * Communicator (4.7): 5-6 seconds
        * Internet Explorer (5.0): 2 seconds
        * Seamonkey: 7-8 seconds

Linux:
        * Communicator (4.61): 4-5 seconds
        * Internet Explorer: N/A
        * Seamonkey: 6-7 seconds


Thus, optimization should be considered prior to product release.

* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

19 years ago
The perfomance bottleneck is unlikely to be in imglib, since that code has not
changed much. Possible causes could be:
1. Optimizations lacking which just redraw the changed part of the image.
2. Necko buffer size and threading issues.
3. Others?

Updated

19 years ago
Depends on: 18992

Comment 2

19 years ago
Currently every times nsImageFrame::Paint() is called, the entire image is
redrawn. This will explain most of the slowdown here. See bug 18992.

Updated

19 years ago
Blocks: 2611

Comment 3

19 years ago
After some investigation, and hacking, I can say that the following factors cause
slow image loading. Note that my test case here is a large 4Mb JPEG, on a very
simple HTML page, loaded from disk (file transport).

Image updating and rendering happens as follows:

The transport (e.g. nsFileTransport) reads data via an nsPipe from the file
channel, notifying the nsAsyncStreamListener::OnDataAvailable() for
every NS_FILE_TRANSPORT_BUFFER_SIZE (8K) bytes read. The nsAsyncStreamListener
posts a PLEvent (in the necko thread), which is handled on the main thread, and
calls into ImageConsumer::OnDataAvailable(). The ImageConsumer spools this
data into imglib IMAGE_BUF_SIZE (4K) bytes at a time, for decoding and output to
the FE.

Progressively displayed images are redrawn on screen as a result of two
processes:

1)  il_partial() will call il_flush_image_data() after OUTPUT_CHUNK_SIZE bytes
	(15000) of image data has been processed.

2)  il_flush_image_data() is called from a timer that flushes data to the UI
	every ROW_OUTPUT_DELAY (300) ms.

Both these processes do an Invalidate(), with the result that the OS might
coalesce these updates. On receipt of the OS udpate event, we then Paint, which
draws the dirty part of the image.

The factors that slow this entire process down are:

1. Image redrawing
   i) the entire image is redrawn for each Paint() call that results from an
      Invalidate (modulo clipping). It would be much more efficient to only
      redraw the part of the image that needs updating (bug 18992).

   ii) All imglib image buffers are 32-bits deep. When rendering to 16-bit
       screen, the blitting can take a significant amount of time.

2. Thread switching.
   On Mac, we aren't yielding to the necko thread often enough, with the result
   that we spend a lot of time doing nothing. Bug 19170.

3. Buffer sizes.
   We get 8k buffers from necko. We need to tune buffer sizes, perhaps
   adaptively.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M14
(Assignee)

Comment 4

19 years ago
This is important, but its gotta wait until
my crashers are fixed.

Comment 5

19 years ago
*** Bug 2151 has been marked as a duplicate of this bug. ***

Comment 6

19 years ago
*** Bug 3958 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 7

19 years ago
[Note to QA/self: please also double-check 3958 when verifying this bug.]

Updated

19 years ago
Keywords: perf
Summary: [4.xP] [Perf] Image display is 50-100% slower than 4.x → [4.xP]Image display is 50-100% slower than 4.x
(Assignee)

Comment 8

19 years ago
eli:
What's the status on this one?
Image display is a function of necko, layout, gfx, imglib
and who knows what else.
Alot has changed all over the code.

Though I do agree image display speed is important, this 
isn't a really useful bug. I can't fix 
"images display too slow". 

-P

Comment 9

19 years ago
Pam: You should look at what's going on in Quantify. Image loading in 4.x is 
_way_ slower than in IE, which would make it unbearable in seamonkey. I suspect 
that some amount of image work is being done on a timer, and the timer isn't 
firing often enough (or something). 
(Assignee)

Comment 10

19 years ago
Thanks Warren.
maybe quantify can give me a handle
on this. 
-p

Comment 11

19 years ago
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp

Comment 12

19 years ago
This isn't a bug on 4.x, it's a performance comparison with 4.x.
(Reporter)

Comment 13

19 years ago
[pnunn, I'm assuming that warren/sfraser/et al's comments suffice. if you still 
want me to poke around, please ping. thanks!]

Comment 14

19 years ago
As you all are looking at this was thinking it would be good to keep in mind bug 
9922 "Large JPEG images fail to display".  Depending on how deep in the code you 
get on this bug fixing bug 9922 could be a nice side effect.  

Bug 9922 even has others marked as dupes of it so a few are interested in it.
Currently 9922 is marked as later, but it could be nice to get it put away 
before beta.

(Assignee)

Comment 15

19 years ago
Jan,
I'm taking the 4xp off the keyword and summary.
We are only talking seamonkey here.
-pn
Keywords: 4xp
Summary: [4.xP]Image display is 50-100% slower than 4.x → Image display is 50-100% slower than 4.x
(Assignee)

Comment 16

19 years ago
Image dimension limits and display speed are not
related in this case. The browser limits image to
8k in height or width.

Image display slowness could be the effect of a
problem in decoding(imglib), rendering (gfx), or
layout.... or compositing.
-pn
(Assignee)

Comment 17

19 years ago
I've added a simple perf test page that will give us
some crude numbers to compare mozilla, communicator 4.x, and
other browsers loading of large images.

There are 3 large jpg images on the page and one small gif.
Two are 1024x1024 compressed to 160K and 210K; one 2346x3174
compressed to 532K. The last image is small, 5x6 pixels.

A simple javascript makes note of the time when the page 
is loaded. The last image is used to trigger an onload event
which then notes the current time and displays the difference
from the start time in an alert.

Note this is giving us a very crude measure of the display of
3 large images. This includes the layout, rendering, decoding
of the images.

I plan other tests to give more meaningful data that will
isolate the decoding from the rendering.
-pn
(Assignee)

Comment 18

19 years ago
Looks like this might be useful if seamonkey could handle
javascript.
_sigh.
-p

Comment 19

19 years ago
Why do we need any js to do this? Can't we just have a page with 50 images on 
it?
(Assignee)

Comment 20

19 years ago
No problem.
I'll build you a paga with 50 big images on it.
no js. 
-pn
(Assignee)

Comment 21

19 years ago
test page now has 8 big images. Will add more later.
Are you using logging to get your data, Warren?
-p
(Assignee)

Comment 22

19 years ago
Another test page with many small gifs:
http://gooey/art/clipart/objectgear/gifs/

Comment 23

19 years ago
I think I have the fix for this.. using some of your previous work..
The test page I did went from 35 seconds to 14 seconds limiting the blitting to 
the amount of the image read in.  As soon as I can check in I will... and this 
bug should close out.
(Assignee)

Comment 24

19 years ago
Wait. I found one more place where I need to update
the ImageURLImpl.  
-p
(Assignee)

Comment 25

19 years ago
Take a look at jazz/users/pnunn/publish/perf_032200.html
which is img only data from leger's daily perf report.

Can we close this vague bug now?
-P
(Assignee)

Comment 26

19 years ago
Eli:

Would you scan leger's perf report and
close this bug? (assuming its not gotten 
worse over the wkend.)

-P
(Assignee)

Comment 27

19 years ago
since there have been no responses, I'm closing the bug.
-P
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 28

18 years ago
Verifying per Pam's comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.