Closed Bug 15891 Opened 25 years ago Closed 25 years ago

stripes in image if scroll while loading

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED DUPLICATE of bug 1248

People

(Reporter: dbaron, Assigned: pnunn)

References

()

Details

Attachments

(2 files)

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
Attached image screenshot of problem (PNG) (deleted) —
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. [DBaron@fas.harvard.edu - "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?]
Wow, you're good; was about to write this up!
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.
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, elig@netscape.com? If so, allow me to establish the report; else you are in violation of Bug 6001. >:+)
[Hey, I just work here; what does Mr. Baron say? ;-]
Status: NEW → ASSIGNED
Target Milestone: M13
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...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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 ***
It seems a bit different, but if it's the same problem underneath...
Status: RESOLVED → VERIFIED
Rubber-stamping as verified. I'll double-check this bug upon verifying 1248 (so that it won't potentially fall through the cracks.)
Attached file MozReview Request: Added patch (deleted) —
Added patch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: