Closed Bug 18738 Opened 25 years ago Closed 25 years ago

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

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: elig, Assigned: pnunn)

References

(
URL
)

Details

(Keywords: perf)

* 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).
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?
Depends on: 18992
Currently every times nsImageFrame::Paint() is called, the entire image is redrawn. This will explain most of the slowdown here. See bug 18992.
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.
Status: NEW → ASSIGNED
Target Milestone: M14
This is important, but its gotta wait until my crashers are fixed.
*** Bug 2151 has been marked as a duplicate of this bug. ***
*** Bug 3958 has been marked as a duplicate of this bug. ***
[Note to QA/self: please also double-check 3958 when verifying this bug.]
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
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
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).
Thanks Warren. maybe quantify can give me a handle on this. -p
Setting the keyword all open [4.xp] bugs to 4xp.
Keywords: 4xp
This isn't a bug on 4.x, it's a performance comparison with 4.x.
[pnunn, I'm assuming that warren/sfraser/et al's comments suffice. if you still want me to poke around, please ping. thanks!]
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.
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
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
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
URL: http://jazz/users/pnunn/publish/Perft...
Looks like this might be useful if seamonkey could handle javascript. _sigh. -p
Why do we need any js to do this? Can't we just have a page with 50 images on it?
No problem. I'll build you a paga with 50 big images on it. no js. -pn
test page now has 8 big images. Will add more later. Are you using logging to get your data, Warren? -p
Another test page with many small gifs: http://gooey/art/clipart/objectgear/gifs/
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.
Wait. I found one more place where I need to update the ImageURLImpl. -p
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
Eli: Would you scan leger's perf report and close this bug? (assuming its not gotten worse over the wkend.) -P
since there have been no responses, I'm closing the bug. -P
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verifying per Pam's comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.