73624 - Pages loading is much slower running in 256 colors

Status: RESOLVED INCOMPLETE

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

Description

[Paul Wyskoczka]

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.

Comment 1

[Paul Wyskoczka]

Changing owner from pam to pavlov

Comment 2

[John Morrison]

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?].

Comment 3

[Paul Chen]

As per performance meeting, reassigning to saari

Comment 4

[saari (gone)]

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.

Comment 5

[saari (gone)]

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. 

Comment 6

[Peter Trudelle]

->moz0.9.1

Comment 7

[Terri Preston]

changing status to [imglib]

Comment 8

[saari (gone)]

*** Bug 78567 has been marked as a duplicate of this bug. ***

Comment 9

[Peter Trudelle]

->moz0.9.2/p3

Comment 10

[Matthias Versen [:Matti]]

*** Bug 88627 has been marked as a duplicate of this bug. ***

Comment 11

[saari (gone)]

->0.9.5 too risky for 0.9.4

Comment 12

[saari (gone)]

->0.9.5 too risky for 0.9.4

Comment 13

[David De Graff]

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.

Comment 14

[saari (gone)]

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.

Comment 15

[Simon Fraser [no longer active]]

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.

Comment 16

[Mike Kaply [:mkaply]]

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.)

Comment 17

[saari (gone)]

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. 

Comment 18

[Winnie Lam]

plusing to topembed+ as per edt triage since this will improve performance. 
saari started work on this already.

Comment 19

[Stuart Parmenter]

Moving bugs to new Image: GFX component

Comment 20

[saari (gone)]

Don Cone has agreed to drive this issue

Comment 21

[Markus Hübner]

Have tests been done when chaning the color depth when without restarting Mozilla?
This boosts performance considerably - as stated in bug 117436.

Comment 22

[Vedran Miletic]

retargeting

Comment 23

[Wayne Mery (:wsmwk)]

(reporter's address is dead)