143365 - unloaded part of bmp image displays black/random garbage

Status: RESOLVED FIXED

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

Description

[vectro]

The unloaded portion of Windows BitMap images is not displayed as trasparent;
rather, that portion seems to be filled with some image from the cache, or a
solid colour.

The linked page has one example of a windows bitmap which is large enough to
display progressive rendering.

Comment 1

[Miloslaw Smyk]

Mozilla 2002061108/Linux-686.

It WFM, but I have seen similar problem with progressive BMPs delivered in mail.

Comment 2

[Anthony DeRobertis]

2002072204 --- I see the unloaded portion of the BMP as black.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

correcting summary. progressive bmp loading works just fine.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

taking bug.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

happens on windows too.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

changing url to point directly at the bmp

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

grrr. I found the reason for this bug. it's in gfx code.

I'll attach a patch as soon as I fix the non-gtk platforms.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

so here's the patch.
It is tested on gtk, and I will test xlib and windows too.
OS/2 seems not affected, and I can't make head or tail of the photon code.

Comment 9

[ArronM (:paper)]

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

logic looks good.

I have plans on changing mDecoded[XY][12] to the OS/2 style of mDecodedRect,
but that won't be for a while.	So in the mean time, this will be nice.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

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

tor, could you super-review this simple patch to fix a display problem of
(bottom-to-top loading) bmp images? It makes the nsIImage implementations "do
the right thing" (interestingly, almost all of them have this bug :) )

Comment 11

[Mike Kaply [:mkaply]]

Note to biesi: Os/2 doesn't have this problem. Works great, and we actually use
the background color before the image is drawn (we don't just fill it white)

Comment 12

[tor]

Probably need a check in Draw/DrawTile of the various platforms to bail
if X1>X2 or Y1>Y2, as the [XY]1 values are used in some clipping
calculations.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

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

marking superreview- due to last comment, will attach another patch

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: address tor's comment

note, this also includes a few warning fixes in nsImageGTK

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 117015 [details] [diff] [review]
address tor's comment

transferring r=paper, re-requesting sr

Comment 16

[tor]

Comment on attachment 117015 [details] [diff] [review]
address tor's comment

Good find. sr=tor

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

fixed, thanks for the reviews.