94758 - Rendering image creates 3 huge temp files in the application directory

Status: RESOLVED FIXED

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

Description

[Simon Fraser [no longer active]]

If I go to http://www.blizzard.com/broodwar/, the browser grinds to a halt
as the page is loading. When I finally get control back, I see 3 temp files in 
the application directory, temp00000001, temp00000002, temp00000003 which range 
from about 2Mb to 6Mb in size.

I *think* these temp files are coming from the jpeg library's backing store code 
(which uses ANSI temp file stuff), since breaking during the disk grinding shows 
jpeg_huff_decode and read_backing_store on the stack.

But it seems very wrong that decoding a few images needs to dump about 10Mb of 
data onto the disk.

Comment 1

[Simon Fraser [no longer active]]

Here is the image that causes problems:

http://www.blizzard.com/images/broodwar/background2.jpg

It's 1600 x 1900 pixels

Comment 2

[gsa]

seeing this behavior also when viewing any web server page containing large graphics
mac build id: 2001091008
3 temp files in the format temp00000001,temp00000002,temp00000003
fscking destroying my disk

Comment 3

[Terri Preston]

Simon, I don't see this behavior on OS 9 or OS X, here are the mac system
requirements

Mac OS
      Mac OS 8.6, 8.6.1, 9.x, Mac OS X

Therefore, I'm marking won't fix, if you disagree, please reopen

Comment 4

[Simon Fraser [no longer active]]

It still happens. Loading 
http://www.blizzard.com/images/broodwar/background2.jpg causes lots of disk 
activity, and freezes up my machine for several seconds. I see these files in the 
application directory:

temp00000000
temp00000001
temp00000002

It took mozilla almost a minute to render that JPEG.

Comment 5

[gsa]

also experiencing this bug in mac os 9 Mozilla Build ID: 2001112011
when loading a url that contains large images 3 temp files of 324k each are
created in "Mozilla Folder", are labelled temp0000000[A-Z,0-..]

Comment 6

[[not reading bugmail]]

this may help:


original URL perf on win platform isn't bad now thanks probably the checkin to
bug 98252, build 2002-01-10-03.. mac perf is still an issue, so stay tuned to
#98252.

Comment 7

[Simon Fraser [no longer active]]

There is nothing in bug 98252 that will affect mac performance. This issue is 
specific to the JPEG library on Mac. Please don't confuse the issue.

Comment 8

[tor]

Switching from using jmemansi.c to jmemnobs.c will eliminate the use
of temporary files for backing store.

Comment 9

[Jo Hermans]

Is this still an issue on Mac OS X ? I'm not seeing the temporary files, and the
performance is great, even on a 300 MHz iBook.

Comment 10

[Simon Fraser [no longer active]]

I don't think we build jmemansi.c on Mac OS X now, so this is fixed.