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
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.
Status: NEW → ASSIGNED
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]
*** 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.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.
plusing to topembed+ as per edt triage since this will improve performance. saari started work on this already.
Keywords: topembed → topembed+
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX
Don Cone has agreed to drive this issue
Assignee: saari → dcone
Status: ASSIGNED → NEW
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
12 years ago
QA Contact: tpreston → image.gfx
(reporter's address is dead)
Assignee: dcone → nobody
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.