9144 - Bitwaste scanned within image bounds while loading

Status: VERIFIED DUPLICATE of bug 1248

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

Description

[Crysgem]

[Assigned to ImageLib with apologies to [e-mail]; please reassign
component as the cast flows]

Load any considerable image (preferably with a mortal's network connection).
Mark carefully the bounds of the image (the space within which it will appear
once fully presented). Scroll the area of the image, or about the image, while
it loads - fields of black will appear, as something of a refresh failure. A
suitable image for illustration of this stupor is
http://E.themes.org/pic.cgi?src=/technoir/desk1999-04-17.jpg, as the black waste
overrides the image background.

This proof was most recently tested with the 1999063008 Apprunner build.

Comment 1

[Eli Goldberg]

I can't reproduce, partially because I don't understand a lot of the bug report,
and probably because I don't have a slow network connection.

So...

* Could you possibly pass over a screen shot of what you're seeing?

* Are you sure that this a different bug from 1248?

Thanks!

Comment 2

[Eli Goldberg]

[Re-opening; Pam believed this was a duplicate of a known bug, but...]

Comment 3

[Crysgem]

[e-mail]:

The issue described in Bug 1248 is very like, aye. But consider again the image
at http://E.themes.org/pic.cgi?src=/technoir/desk1999-04-17.jpg, WITH A USER'S
NETWORK CONNECTION, if only to test the checks written of in the report of 1248.
I am able to observe the "bitgunk" appear in random, unconnected sections of the
unrendered image bounds, as opposed to the complete black field depicted in the
screen-shot I'm to append.

To illustrate the intended meaning:

(The outermost lines depict the boundaries of the image in the page)

_____________________________________________
|*******************************************|
|****[Portion of image completed]***********|
|*******************************************|
|*******************************************|
|-------------------------------------------|
|                                           |
|                                           |
| [Portion awaiting data; appears "blank"   |
|    according to default system color]     |
|                                           |
|                                           |
|                                           |
|___________________________________________|
|@(*#%&{Aô�½ºÛg*@#(&%(*”‘åÁ½ÿñ’—»Ë0À_Ëé×ÇfÇ,|
|#+)õ@%#[  Bitwaste; appears black  ](|é×Çfo|
|@*%@š#+)õ@%#+ÿ*@#Ä#%()*œ@#þ{“›ø%(*”‘å@*(#%&|
|___________________________________________|
|                                           |
|                                           |
|            [Blank/Default color]          |
|                                           |
|                                           |
|___________________________________________|
|@(*#%&{Aô�½ºÛg*@#(&%(*”‘åÁ½ÿñ’—»Ë0À_Ëé×ÇfÇ,|
|#(&%(*”‘å#%&-([  Bitwaste  ]#þ&{Aô�ÿñ’—»Ë0À|
|ÿ*@#Ä#%()*œ@#þ&{Aô�½ºÛg*@#(&%(*”‘åÁ½ÿñ’—»Ë0|
|___________________________________________|
|                                           |
|___________________________________________|

Comment 4

[Crysgem]

Attachment: Note the field of black, overriding the intended background

Comment 5

[pnunn]

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

Comment 6

[Eli Goldberg]

Rubber-stamping as duplicate based on descriptions.

crysgem, please re-open with your comments if you believe this is a different
bug; thanks!