1204470 - Horizontal "blank" lines when decoding some large images

Status: VERIFIED WORKSFORME

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

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

[Tracking Requested - why for this release]: Regression

STR:
1. Open some page with large images like photographs
2. Open image in new tab
3. Force reload page with Shift+Ctrl+R some times too see horizontal "blank" lines when image decoding happens

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: 1.png

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Using a trunk build from today, I haven't been able to reproduce this yet on my Win10 system. I'm trying to load http://i.4cdn.org/g/1442224840164.jpg as shown in the attached screenshot.

Virtual_ManPL, do you happen to know how recently this was working? Would you be interested in trying out the mozregression tool to help narrow it down?

Comment 3

[Seth Fowler [:seth] [:s2h]]

Looks like an invalidation problem. This is for sure a platform-dependent problem.

Virtual_ManPL, could you let us know the details of your machine (what CPU and what OS) and the graphics info from about:support?

Comment 4

[Seth Fowler [:seth] [:s2h]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #2)
> Virtual_ManPL, do you happen to know how recently this was working? Would
> you be interested in trying out the mozregression tool to help narrow it
> down?

This is almost certainly a regression from bug 1060609.

Comment 5

[Seth Fowler [:seth] [:s2h]]

(In reply to Seth Fowler [:seth] [:s2h] from comment #4)
> This is almost certainly a regression from bug 1060609.

No wait, the fact that the screenshot is a PNG threw me off. Looks like we are hitting this problem on JPEGs, which have been using DDD for six months, so it's probably not DDD.

Gotta agree with Ryan on this one: Virtual_ManPL, if you're willing, running mozregression would be a huge help in tracking down the source of the bug.

Comment 6

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: Graphics from about;support.txt

Comment 7

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: PC specs.txt

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm always posting regression ranges in bugs that I report,
but unfortunately, I won't be having time to find a regression range in about 3 weeks.
I think that regression started in few weeks ago and version 42 is unaffected, but it need to be diagnosed further.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

(In reply to Virtual_ManPL [:Virtual] from comment #8)
> but unfortunately, I won't be having time to find a regression range in
> about 3 weeks.

Any chance you're able to bisect this now? :)

Comment 10

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

This was one hella a ride with this regression search, as it was kinda very hard to reproduce in normal way, so so much time consuming, but in the end, I finally found the way to reproduce it 100% each time. The key to do this was to disable all caches (RAM, disc and etc. in about:config).


So let's go to the main part;

Regression window (mozilla-central)
Good:
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/07/2015-07-19-03-02-19-mozilla-central/

Bad:
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/07/2015-07-20-03-02-13-mozilla-central/

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9c919ce631ea&tochange=5df788c56ae7

Probably caused by:
Bug #1151359 - Predict size at which nsImageFrame's images will be drawn for downscale-during-decode
or
Bug #1176124 - Add placeholders in the SurfaceCache to track when we've started decoding a frame, even if we haven't allocated it yet



[Tracking Requested - why for this release]: Regression

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Thanks for tracking this down! A Herculean effort :)

Comment 12

[Seth Fowler [:seth] [:s2h]]

Thanks so much for the regression range! The cause isn't immediately obvious to me, but since you also posted instructions on how to reproduce reliably, hopefully this is enough information to get this tracked down and fixed.

Comment 13

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Based on my simple observation, I think that "bug-free" Firefox builds decoded images in partial way, compared to "bugged" Firefox builds, which decode images faster and constantly producing results. So maybe it's too fast to decode with no data to render. That's why it maybe gave sometime these free horizontal "blank" places.

Comment 14

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

FYI - nearly identical issue was in Bug #1145560

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Seth, I guess you are going to be the one working it.
Seems that 42 is going to be released with this bug.

Comment 16

[Seth Fowler [:seth] [:s2h]]

(In reply to Virtual_ManPL [:Virtual] from comment #14)
> FYI - nearly identical issue was in Bug #1145560

The visual effect was the same there, but the cause is something different. (And unfortunately, we still don't know what the cause is.)

(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> Seth, I guess you are going to be the one working it.
> Seems that 42 is going to be released with this bug.

Yep. There wasn't enough time to address this issue during this cycle.

Comment 17

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Seth Fowler [:seth] [:s2h] from comment #16)
> (In reply to Virtual_ManPL [:Virtual] from comment #14)
> > FYI - nearly identical issue was in Bug #1145560
> 
> The visual effect was the same there, but the cause is something different.
> (And unfortunately, we still don't know what the cause is.)
Any more things that I can do to help diagnosing this?
Maybe some debug build with console that shows what's going on?

Comment 18

[Seth Fowler [:seth] [:s2h]]

(In reply to Virtual_ManPL [:Virtual] from comment #17)
> Any more things that I can do to help diagnosing this?
> Maybe some debug build with console that shows what's going on?

If you're able to make builds yourself, finding the exact regressing commit would be a huge help. Both of the image-related patches in the regression range you found so far are pretty complicated, so it'd be really helpful to know which one to investigate more closely.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Builds for rev f52a8f3b15ed (bug 1176124): https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b23f5b7ad19d

Builds for rev 03be986cf1aa (bug 1176124 + bug 1151359): https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-56784829a8e5

Comment 20

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Seth Fowler [:seth] [:s2h] from comment #18)
> If you're able to make builds yourself, finding the exact regressing commit
> would be a huge help. Both of the image-related patches in the regression
> range you found so far are pretty complicated, so it'd be really helpful to
> know which one to investigate more closely.

Unfortunately I'm unable to make builds by myself and I will need some help with it.


(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #19)
> Builds for rev f52a8f3b15ed (bug 1176124):
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ryanvm@gmail.
> com-b23f5b7ad19d
> 
> Builds for rev 03be986cf1aa (bug 1176124 + bug 1151359):
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ryanvm@gmail.
> com-56784829a8e5

These URLs aren't valid, even if I will add "/" at the end.
Looking deeply even inside
https://ftp-ssl.mozilla.org/pub/firefox/try-builds/[e-mail]-56784829a8e57906695f18120e6a656a1bee9b8e/try-win32/
and
https://ftp-ssl.mozilla.org/pub/firefox/try-builds/[e-mail]-b23f5b7ad19dbef9f8c43a2beb96df0e1b55a633/try-win32/
I'm seeing no builds.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

(In reply to Virtual_ManPL [:Virtual] from comment #20)
> These URLs aren't valid, even if I will add "/" at the end.
> Looking deeply even inside

Looks like our Try post-push commit hook is broken, whee. Try these links instead :)

Rev f52a8f3b15ed (bug 1176124):
https://queue.taskcluster.net/v1/task/sv28loNTSxmRFC_1dC9PDg/artifacts/public/build/firefox-42.0a1.en-US.win32.zip

Rev 03be986cf1aa (bug 1176124 + bug 1151359):
https://queue.taskcluster.net/v1/task/DT3SdeN1RU-ghSik47ujIA/artifacts/public/build/firefox-42.0a1.en-US.win32.zip

Comment 22

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #21)
> Rev f52a8f3b15ed (bug 1176124):
> https://queue.taskcluster.net/v1/task/sv28loNTSxmRFC_1dC9PDg/artifacts/
> public/build/firefox-42.0a1.en-US.win32.zip

Unaffected


(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #21)
> Rev 03be986cf1aa (bug 1176124 + bug 1151359):
> https://queue.taskcluster.net/v1/task/DT3SdeN1RU-ghSik47ujIA/artifacts/
> public/build/firefox-42.0a1.en-US.win32.zip

Affected

Comment 23

[Milan Sreckovic [:milan] (needinfo for best results)]

Seth, should we be backing out bug 1151359, or at least putting that behaviour behind a pref so that we can verify this is the cause?  if it is, this got introduced during 42, which we just released; I'd like not to have too many releases with this bug, even if it is difficult to reproduce.

Comment 24

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like 43 will ship with this, pinging seth again for his thoughts on where to go from here. 
We could likely still take a patch for 44.

Comment 25

[Seth Fowler [:seth] [:s2h]]

(In reply to Milan Sreckovic [:milan] from comment #23)
> Seth, should we be backing out bug 1151359, or at least putting that
> behaviour behind a pref so that we can verify this is the cause?  if it is,
> this got introduced during 42, which we just released; I'd like not to have
> too many releases with this bug, even if it is difficult to reproduce.

That bug cannot actually be the cause, because it has nothing to do with invalidation or drawing the image. Regression ranges are very misleading here. The bug is definitely in painting or invalidation, and it's just being tickled because timing is different.

Comment 26

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Given that inactivity on this bug and the fact that we haven't had more end-users complaining about this, I do not think this is release blocking for FF44, wontfixing as such. If a fix is ready sometime soon, I'd be happy to uplift. Also wondering if we need to track this any more given that this is a wontfix for over 3 releases now. (!)

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Sorry but I don't see the point of tracking it... We released 2 major releases with it and the impact has not been important. Not tracking.

Comment 28

[Seth Fowler [:seth] [:s2h]]

Virtual_ManPL, can you still reproduce this on Nightly? The original image on 4chan is gone, so I can't test with that image. I've clicked around a lot on imgur and haven't been able to reproduce. If you can still reproduce, could you post a new URL? It's not clear to me whether bug 1145560 fixed this, and so much code has changed in the last few months in this area that it may have been fixed by something else even if bug 1145560 didn't do the job.

Comment 29

[Seth Fowler [:seth] [:s2h]]

Note that I'm seeing no dupes for this bug, so people do not seem to be hitting this frequently, if at all, which suggests to me that it's probably fixed, but I'd like to know for sure.

Comment 30

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Yes, I could still reproduce the issue 2 days ago.
I will try to upload the image here and URL, if I see that it happens with it frequently.

Comment 31

[u279076]

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #30)
> Yes, I could still reproduce the issue 2 days ago.
> I will try to upload the image here and URL, if I see that it happens with
> it frequently.

It's been over a month, do you have a status update?

Comment 32

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I can still reproduce it, but it's very hard to reproduce it on the same file.

So my STR:
1. disable all caches for RAM, disc, image and etc. in about:config.
2. go to website page with many images, like for example http://boards.4chan.org/p
3. go the the bottom of the page and click "All" to toggle infinite scroll
4. when the page will be loading, press "Page Down" keyboard button to get all next pages loaded into this one
5. click on some thumbnails to get bigger image and in 1/20 or less you probably will be able to reproduce the issue

Comment 33

[u279076]

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #32)
> I can still reproduce it, but it's very hard to reproduce it on the same file.

Thanks.

Milan, it looks like this issue is still valid. Is Seth or someone else able to work on this?

Comment 34

[Milan Sreckovic [:milan] (needinfo for best results)]

Eventually :)

Comment 35

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 36

[Liz Henry (:lizzard) (relman/hg->git project)]

This is a lot of wontfixes in a row without any progress. Dropping it from regression triage.

Comment 37

[Mike Taylor [:miketaylr]]

I'm gonna remove the regression keyword since it doesn't seem useful to track it as such (and keeps getting punted from release to release).

Comment 38

[Mike Taylor [:miketaylr]]

(going to remove regression keyword -- we've been shipping this so long it should just be considered a product bug)

Comment 39

[Pablo]

Hi virtual_manPL

im unable to replicate this on windows10 64bit using firefox 94.0.1
Perhaps I am doing it incorrectly but i am following comment #32 and disabled some of the browser.cache

I know it is a really old bug but we are trying to see if it is still a valid one. Im wondering if you can still reproduce it using the latest firefox release.
please let me know

regards.

Comment 40

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm confirming that the bug cannot be longer reproduced in Mozilla Firefox Nightly 97.0a1 (2021-12-20), so I'm marking this bug as WORKSFORME.