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.
Here is the image that causes problems: http://www.blizzard.com/images/broodwar/background2.jpg It's 1600 x 1900 pixels
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
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
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Priority: -- → P3
Resolution: WONTFIX → ---
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-..]
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.
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.
Switching from using jmemansi.c to jmemnobs.c will eliminate the use of temporary files for backing store.
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.
I don't think we build jmemansi.c on Mac OS X now, so this is fixed.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.