Open Bug 73624 Opened 20 years ago Updated 8 years ago

Pages loading is much slower running in 256 colors


(Core Graveyard :: Image: Painting, defect, P1)

Windows 98


(Not tracked)



(Reporter: pawyskoczka, Unassigned)



(Keywords: embed, memory-footprint, perf, Whiteboard: [imglib])

Running jrgm page loader tests on the following machines in 256 colors and 32
bit color produce the following results.

Kayak AS 500 mhz with 128 mb of memory
256 colors - avg=3207 median=3016
32 bit color - avg=1930 median=1839

Dell 220 733 mhz with 128 mb of memory
256 colors - avg=2475 median=2444
32 bit color - avg=1174 median=1113

Looks like there is a significant downside to running in 256 colors.
Changing owner from pam to pavlov
Assignee: pnunn → pavlov
Keywords: perf
Blocks: 71668
I ran in 8bit, 16bit and 24bit with a 500MHz/128MB Kayak last night as well, 
and while running in 8bit shows the same slowdown relative to 24, running in
16bit (thousands of colours) shows _no_ slowdown relative to 24bits. So, this
is only an issue for 8bit. 

Anecdotally, sfraser and I ran a quick test of this a couple of weeks ago 
(which I forgotten about). There was no slowdown on Mac when running in 
thousands of colors, instead of millions. [Do any Macs have an 8bit mode
these days?].
As per performance meeting, reassigning to saari
Assignee: pavlov → saari
Okay, first guess is that Windows is as bad at dithering down to 256 colors on
blit as Mac is, which is pretty bad. I wouldn't have guessed it would affect
page load by 2x though. If I'm right, that implies that we paint waaay too much.

Bringing up a Windows Quantify build right now to see where this time is going.

If it is blit dithering, it isn't the end of the world. I was planning on
caching image data in screen depth anyway for the memory savings, so thing would
just make that change even higher priority.
Target Milestone: --- → mozilla0.9
Okay, I'm pretty sure it is just GDI thrashing when taking the 24bit image down
to 8bit screen depth that is killing us here. Quantify shows StretchDIBits
taking a full second on the load of CNN in 256 colors and 1/3 that time when in
24bit color. This is on my P3 500 with 256MB of ram.

So doing paletted support and storage of the image at device depth should bring
the numbers back in line (and save memory too!). Now I just have to find time to
do it...

That said, loading CNN takes 1300-1500 StretchDIBits calls, which is way too
many IMO. 
Target Milestone: mozilla0.9 → mozilla0.9.1
changing status to [imglib]
Whiteboard: [imglib]
Depends on: 78567
*** Bug 78567 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
*** Bug 88627 has been marked as a duplicate of this bug. ***
->0.9.5 too risky for 0.9.4
->0.9.5 too risky for 0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Bug 95106 seems like a severe regression that may be related to this bug. 95106
was reported on 8/13, but no one has apparently tried to confirm it so far.

Please check it out running NT with display set to 256 colors. This more severe
color display problem shows up first in the 8/09 build, and makes the browser
basically unusable at 256 color display setting.

By the way, why is working on this bug (73624) too risky for 0.9.4? I would
think that putting off work on important bugs is more risky than addressing them
quickly, for many reasons.
this will be a big change to the code and 0.9.4 isn't the time for big changes.
It is on my list of things to do ASAP though.
Is our offscreen backing store at screen depth, or 24-bit depth? If the former, 
then this slowdown must be entirely image blits. If the latter, then the slowdown 
is backing store->screen blits.
I'm a little confused by this bug. By definition, 256 color support IS slower 
than others because of the overhead required to do palette switching.

If you tested in the current build, you would probably find that 256 color is 
just as fast as other color depths because palette management (the expensive 
stuff) was removed by Pavlovs libimg removal.

However it does need to be put back, and when it is, things will slow down 
again. 256 color support adds a whole level of palette switching in which slows 
stuff down (on Windows, on OS/2, etc.)
It is slower on 256 color machines because the OS blit call has to do a color
map conversion for each and every blit that goes to screen. You're right that it
is faster on most machines today (they're all running in true color). However,
it might be worth the memory/speed tradeoff on some boxes/OSes to use paletted
GIFs. We'll have to measure that and decide on a default setting.

I want there to at least be an ifdef that allows people to always use paletted
images for GIFs to save memory. It will be slower on true color machines yes,
but it is a valid tradeoff to make in some cases.

Ideally this will be dynamic, so if you're running in 256 color paletted mode,
then you'll just get paletted images. 
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Priority: P3 → P1
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: footprint
Keywords: nsbeta1
Keywords: topembed
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.0.1
plusing to topembed+ as per edt triage since this will improve performance. 
saari started work on this already.
Keywords: topembedtopembed+
Keywords: topembed+embed
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX
Don Cone has agreed to drive this issue
Assignee: saari → dcone
Have tests been done when chaning the color depth when without restarting Mozilla?
This boosts performance considerably - as stated in bug 117436.
Target Milestone: mozilla1.0.1 → Future
QA Contact: tpreston → image.gfx
(reporter's address is dead)
Assignee: dcone → nobody
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.