235064 - Poor visual quality of background on 8-bit win32

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Win32, defect)

Description

[tor]

Background images look pretty bad when run in 8-bit mode on windows.
Turns out that in the tiling code we're creating a new DC but not
setting the flag that makes GDI dither the result.

Comment 1

[tor]

Attachment: testcase

Comment 2

[tor]

Attachment: patch

Comment 3

[tor]

Comment on attachment 141850 [details] [diff] [review]
patch

Seems to be only dithering against the locked-down colors.

Comment 4

[tor]

Attachment: hook up the palette too

Comment 5

[tor]

Comment on attachment 141853 [details] [diff] [review]
hook up the palette too

wrong patch

Comment 6

[tor]

Attachment: right patch

Comment 7

[[e-mail]]

Wow, it even makes Modern almost usable in 256 colours!

Comment 8

[Ere Maijala (slow)]

Comment on attachment 141855 [details] [diff] [review]
right patch

Looks more consistent but bad in very green way in a terminal session, but I
believe this is the right thing to do and I also believe Neil.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 141855 [details] [diff] [review]
right patch

Two questions:

-- The comment says we only progressive double blit if we're not in 256 color
mode, and it looks like the code agrees. What's going on?

-- Are you forgetting to release dctx? Why did you change it from being an
nsCOMPtr?

Comment 10

[tor]

Attachment: back to nsCOMPtr

The mNumPaletteColors check seems to be old code to deal with colormapped
images, which gfx never sees these days.

Switched back to nsCOMPtr.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 142243 [details] [diff] [review]
back to nsCOMPtr

Please change the comment about 256 colors to something like

// we aren't a 256 color image, and we don't have an unoptimized 8 bit alpha.

Comment 12

[tor]

Checked in.