15891 - stripes in image if scroll while loading

Status: VERIFIED DUPLICATE of bug 1248

(Core :: Graphics: ImageLib, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm guessing ImageLib rather than Compositor on this one, but I could be wrong.

DESCRIPTION:  If I use the arrows to scroll while an image is loading, there are
black stripes in the parts of the image that were first displayed while I was
scrolling.  (So the part that's progressively loading should be on-screen while
the scrolling is happening.)

STEPS TO REPRODUCE:
 * Load http://www.cira.colostate.edu/Special/CurrWx/g8full4.htm
 * While image loads, hit down arrow quickly, a bunch of times

ACTUAL RESULTS:
 * Some black stripes in the image.  They go away when the image finishes
loading (I guess the whole thing repaints).

EXPECTED RESULTS:
 * No black stripes.

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-10-08-08-M11

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot of problem (PNG)

Comment 2

[Crysgem]

A bug very like to this reported was witnessed at http://www.spaceviews.com/.
Differing my observation was, and thus: The platform, MICROSOFT WINDOWS 98; the
Apprunner build, 1999100908. The "stripe" included random bitwaste
(multi-colored "noise"), and would at whiles accumulate the pixels it scrolled
past, so that intact rows of pixels from other (valid) parts of the page would
mar the display.

[[e-mail] - "stripes" is not a search term I had conceived of; I
luckily discovered this report by searching the "Imagelib" component. May we
agree that "horizontal line" or "row" is more apt to the obvious-minded?]

Comment 3

[Eli Goldberg]

Wow, you're good; was about to write this up!

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Crysgem - From your description, it sounds like you're seeing a separate bug.
Did you look at the screenshot I attached?  If it's a separate bug, then it
should be filed as a separate bug.

The second sentence of your first paragraph doesn't make much sense to me.  Are
you saying that the stripe is being scrolled while the rest of the page is
stationary?

Also, were the stripes you saw only 1px thick?  It sounded from your first
sentence like they are, in which case this is definitely a different bug.

Comment 5

[Crysgem]

Sir - I did indeed suck in the photons of your screenshot.
My poorly crafted sentence was to have communicated: The stripe remains in
place (behaves as would a normal part of the document), scrolling with the page
as if the pixels were valid.
The stripes I witnessed measured more than 1 pixel of height.

Shall I file a seperate bug, [e-mail]? If so, allow me to establish the
report; else you are in violation of Bug 6001. >:+)

Comment 6

[Eli Goldberg]

[Hey, I just work here; what does Mr. Baron say? ;-]

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems they could be the same bug - the Linux compositor may initialize
drawing areas to black and the Windows one may not.  Something like that could
explain the difference...

Comment 8

[pnunn]

This is a dupe of #1248.
And a great test url for the problem.
-pn

*** This bug has been marked as a duplicate of 1248 ***

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems a bit different, but if it's the same problem underneath...

Comment 10

[Eli Goldberg]

Rubber-stamping as verified.

I'll double-check this bug upon verifying 1248 (so that it won't potentially
fall through the cracks.)

Comment 11

[Eric Rescorla (:ekr)]

Attachment: MozReview Request: Added patch

Added patch