Pages loading is much slower running in 256 colors

NEW
Unassigned

Status

P1
major
18 years ago
6 years ago

People

(Reporter: pawyskoczka, Unassigned)

Tracking

({embed, memory-footprint, perf})

Trunk
Future
x86
Windows 98
embed, memory-footprint, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [imglib])

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Changing owner from pam to pavlov
Assignee: pnunn → pavlov
Keywords: perf

Updated

18 years ago
Blocks: 71668

Comment 2

18 years ago
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

18 years ago
As per performance meeting, reassigning to saari
Assignee: pavlov → saari

Comment 4

18 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9

Comment 5

18 years ago
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

18 years ago
->moz0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 7

18 years ago
changing status to [imglib]
Whiteboard: [imglib]

Updated

18 years ago
Depends on: 78567

Comment 8

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

Comment 9

18 years ago
->moz0.9.2/p3
Priority: -- → P3
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

18 years ago
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. ***

Comment 11

17 years ago
->0.9.5 too risky for 0.9.4

Comment 12

17 years ago
->0.9.5 too risky for 0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 13

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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. 

Updated

17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

17 years ago
Priority: P3 → P1

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

17 years ago
Keywords: footprint

Updated

17 years ago
Keywords: nsbeta1

Updated

17 years ago
Keywords: topembed

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1-

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0.1

Comment 18

17 years ago
plusing to topembed+ as per edt triage since this will improve performance. 
saari started work on this already.
Keywords: topembed → topembed+

Updated

17 years ago
Keywords: topembed+ → embed

Comment 19

17 years ago
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX

Comment 20

17 years ago
Don Cone has agreed to drive this issue
Assignee: saari → dcone
Status: ASSIGNED → NEW

Comment 21

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

Comment 22

15 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future
QA Contact: tpreston → image.gfx

Comment 23

11 years ago
(reporter's address is dead)
Assignee: dcone → nobody

Updated

9 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.