1256211 - After switching tabs, background image is never drawn if the animation is continuing

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Alice0775 White]

Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/d1d47ba19ce9d46222030d491f9fe28dbf80be12
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 ID:20160313030418


Steps To Reproduce:
1. Open http://www.wcwraces.com/ in [tab A] and wait to load page
2. Open about:memory in [tab B]
3. Wait for few minutes (OR Click [Minimize memory usage] button)
4. Switch to [tab A]
5. Immediately after, 
   Move the mouse to the right side pane(bubalus) and then the left side pane(bike).
   And repeat it so that the animation continue

Actual Results:
Background landscape image(sky, snow and trees) is never drawn. but black and white.
See screen capture https://www.youtube.com/watch?v=bSkTf8S-zQU


Expected Results:
Background landscape image(sky, snow and trees) should be drawn after few seconds.



#1 Regression window(crash when mouse hover over bubalus)
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6312f4020b6d91372c9b4f69e5fa1c02bc1148ef&tochange=396e7cdc25393a818a8e3a07af49284655ad58a3

#1 Regressed by: b485a3749445	Seth Fowler — Bug 1251804 - Use the ImageContainer's size and not the intrinsic size when computing the transform in nsDisplayImage::ConfigureLayer. r=tn

#2 Regression window(the above crash was fixed, but background landscape image is never drawn):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dd1abe874252e507b825a0a4e1063b0e13578288&tochange=767e0126510e0f65798a53a29c6b7e1469a03139

#2 Regressed by: 767e0126510e	Seth Fowler — Bug 1255362 - Null-check GetContainer() before using it in image-related ConfigureLayer() methods. r=mstange a=Tomcat

Comment 1

[Timothy Nikkel (:tnikkel)]

Thanks Alice!

(In reply to Alice0775 White from comment #0)
> 3. Wait for few minutes (OR Click [Minimize memory usage] button)

You can also set the pref image.mem.surfacecache.min_expiration_ms to a small value so that decoded images that are not on screen get discarded quicker.

We should create a local copy that exposes this bug as that website is likely to change soon (no more snow, both those events are over now).

Comment 2

[Alice0775 White]

Attachment: archive html for the record

Comment 4

[u279076]

Alice, I assume this also affects Firefox 49. Can you please confirm?

Comment 5

[Alice0775 White]

(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #4)
> Alice, I assume this also affects Firefox 49. Can you please confirm?

I can still reproduce the problem on latest Nightly49.0a1

https://hg.mozilla.org/mozilla-central/rev/8c3fd523d75bd30f691ca2d6cfdad18d576392a1
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160429030215

(BTW, My PC was upgraded from Windows7 to Windows10)

Graphics
--------

Features
Compositing: Direct3D 11
Asynchronous Pan/Zoom: wheel input enabled; touch input enabled
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0)
Hardware H264 Decoding: Yes; Using D3D11 API
Direct2D: true
DirectWrite: true (10.0.10240.16430)
GPU #1
Active: Yes
Description: AMD Radeon HD 6450
Vendor ID: 0x1002
Device ID: 0x6779
Driver Version: 15.201.1151.1008
Driver Date: 11-4-2015
Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Subsys ID: 23111787
RAM: 1024

Diagnostics
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300

Comment 6

[u279076]

Thanks Alice. By the looks of http://support.amd.com/en-us/download/desktop/legacy?product=legacy3&os=Windows%2010%20-%2064 there might be a more recent driver version available. Could you please double check that you're using the current driver and that this issue still reproduces?

Comment 7

[Alice0775 White]

I updated Graphics driver.
And I can still reproduce the problem.


https://hg.mozilla.org/mozilla-central/rev/77cead2cd20300623eea2416bc9bce4d5021df09
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160502030207

Application Basics
------------------

Name: Firefox
Version: 49.0a1
Build ID: 20160502030207
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
OS: Windows_NT 10.0
Multiprocess Windows: 1/1 (Enabled by default)
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports (including 1 pending crash in the given time range)

Extensions
----------

Name: Firefox Hello
Version: 1.3.1
Enabled: true
ID: [e-mail]

Name: Multi-process staged rollout
Version: 1.0
Enabled: true
ID: [e-mail]

Name: Pocket
Version: 1.0
Enabled: true
ID: [e-mail]

Name: Web Compat
Version: 1.0
Enabled: true
ID: [e-mail]

Graphics
--------

Features
Compositing: Direct3D 11
Asynchronous Pan/Zoom: wheel input enabled; touch input enabled
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6450 Direct3D11 vs_5_0 ps_5_0)
Hardware H264 Decoding: Yes; Using D3D11 API
Direct2D: true
DirectWrite: true (10.0.10586.0)
GPU #1
Active: Yes
Description: AMD Radeon HD 6450
Vendor ID: 0x1002
Device ID: 0x6779
Driver Version: 15.301.1901.0
Driver Date: 2-26-2016
Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Subsys ID: 23111787
RAM: 1024

Diagnostics
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 300




Important Modified Preferences
------------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.frecency_experiment: 1
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 8
browser.startup.homepage_override.buildID: 20160502030207
browser.startup.homepage_override.mstone: 49.0a1
dom.apps.reset-permissions: true
extensions.lastAppVersion: 49.0a1
media.benchmark.vp9.fps: 67
media.benchmark.vp9.versioncheck: 1
media.gmp-manager.buildID: 20160502030207
media.gmp-manager.lastCheck: 1462231212
media.hardware-video-decoding.failed: false
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
security.sandbox.content.tempDirSuffix: {3bc3339a-67fd-4aa6-a9ba-27a3c1bda1a7}
ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found.

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.12
Version in use: 4.12

NSS
Expected minimum version: 3.24 Basic ECC
Version in use: 3.24 Basic ECC

NSSSMIME
Expected minimum version: 3.24 Basic ECC
Version in use: 3.24 Basic ECC

NSSSSL
Expected minimum version: 3.24 Basic ECC
Version in use: 3.24 Basic ECC

NSSUTIL
Expected minimum version: 3.24
Version in use: 3.24

Experimental Features
---------------------




***BTW***, I can also reproduce the problem with/without HWA.

Comment 8

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

Recent regression, tracking for 48+

Comment 9

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

(In reply to Alice0775 White from comment #0)
> ...
> 
> #2 Regressed by: 767e0126510e	Seth Fowler — Bug 1255362 - Null-check
> GetContainer() before using it in image-related ConfigureLayer() methods.
> r=mstange a=Tomcat

That's really strange - this patch stops us from having a null pointer crash; if something is wrong with it, that something used to be a crash before this change :)

Comment 10

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

How common is this problem?  Does it happen every time we switch tabs?  Is it a particular page setup that gets us to this?  Because if it's every background when we switch tabs, this is not a good regression to ship.

Comment 11

[Timothy Nikkel (:tnikkel)]

There is bug 1260324 which affects all background images when we switch tabs if the image has been discarded. In addition to suffering from that bug this testcase also appears to suffer from a longer lasting effect. It appears to be timing dependent as it doesn't happen in an official builds, but I can reproduce a similar effect in a debug build.

Using official builds I see approximating the same badness in release (which shouldn't have this bug according to the regression range in comment 0) and beta (which should have this bug).

I _think_ this problem is the result of the combination of bug 1260324 and the following problem:
when we layerize an image we will ask for a decoded copy without the high quality scaling flag, which forces us to only return a surface of the exact requested size. The background is increasing in size slightly, so there is a decoded copy a couple pixels smaller that we refuse to use. So instead we return a new surface of the exact requested size, but it's not decoded (or decoded partially) so the drawing is messed up. Seems like there is a lot of code that just assumes when we ask for a layerized version of the image that we get a full and complete copy of it. (For example in nsDisplayImageContainer::ConfigureLayer we always update our draw result to success, which is wrong if the image we are going to draw isn't decoded. This problem should only affect reftests, so it's not the problem we are looking for.)

If my diagnosis is correct, then https://hg.mozilla.org/integration/mozilla-inbound/rev/396e7cdc2539 is what caused this.

So I'm guessing this particular problem would be limited to images that are changing in size.

Comment 12

[Timothy Nikkel (:tnikkel)]

(In reply to Milan Sreckovic [:milan] from comment #9)
> (In reply to Alice0775 White from comment #0)
> > ...
> > 
> > #2 Regressed by: 767e0126510e	Seth Fowler — Bug 1255362 - Null-check
> > GetContainer() before using it in image-related ConfigureLayer() methods.
> > r=mstange a=Tomcat
> 
> That's really strange - this patch stops us from having a null pointer
> crash; if something is wrong with it, that something used to be a crash
> before this change :)

767e0126510e was a quick fix for a null crash introduced by the changesets from the first regression window. So, yes, the testcase crashed for the couple of days between the changesets. When the crash was fixed the regression from the 1st set of changesets was able to be observed.

Comment 13

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

(In reply to Timothy Nikkel (:tnikkel) from comment #11)
> If my diagnosis is correct, then
> https://hg.mozilla.org/integration/mozilla-inbound/rev/396e7cdc2539 is what
> caused this.
> 
> So I'm guessing this particular problem would be limited to images that are
> changing in size.

I'd buy that that's the proximate cause, but if your analysis is correct the actual issue is that we're never painting the updated ImageContainer. After all, as decoding continues we update the ImageContainer's contents. Why aren't those updates making it to the screen?

Matt, do you have an idea why updates to an ImageContainer in an ImageLayer wouldn't get painted? (The relevant code is in RasterImage::GetImageContainer() and UpdateImageContainer()).

I'm unfortunately on PTO and can't easily investigate this right now, but I'll try to offer what help I can. Timothy's theory makes sense to me.

Comment 14

[Timothy Nikkel (:tnikkel)]

(In reply to Seth Fowler [:seth] [:s2h] from comment #13)
> (In reply to Timothy Nikkel (:tnikkel) from comment #11)
> > If my diagnosis is correct, then
> > https://hg.mozilla.org/integration/mozilla-inbound/rev/396e7cdc2539 is what
> > caused this.
> > 
> > So I'm guessing this particular problem would be limited to images that are
> > changing in size.
> 
> I'd buy that that's the proximate cause, but if your analysis is correct the
> actual issue is that we're never painting the updated ImageContainer. After
> all, as decoding continues we update the ImageContainer's contents. Why
> aren't those updates making it to the screen?

I couldn't reproduce exactly what the video shows (the background image never getting drawn) so I couldn't debug that part. But I have a reasonable theory for what is happening.

If the machine Alice was testing on was not high end, then we would be flooding it with decode requests (one for each frame we draw to screen as the background size is animating) of a 4000x4000 image. So they could all be making very little progress while the main thread is also busy painting to the screen. So, in my theory, eventually they would show up if one waited long enough.

Imagelib has already been proven to have a lot of bad behaviour going on in this testcase that we should fix before making other engineers spend time on things that might not even be real problems.

Comment 15

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

This build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=186ab5eada01 has https://hg.mozilla.org/integration/mozilla-inbound/rev/396e7cdc2539 backed out - lets see if that get rid of the symptom we're seeing.

Comment 16

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

Alice, is the problem gone with the build from comment 15?

Comment 17

[Alice0775 White]

Umm, I can still reproduce the problem on the try build.

https://hg.mozilla.org/try/rev/186ab5eada0117be2785c5aa384bfa344a99b7ea
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 ID:20160704091847

Comment 18

[Alice0775 White]

There are no similar bug, So, I think it is no longer tracking is necessary

Comment 19

[Timothy Nikkel (:tnikkel)]

Alice, are you still able to reproduce this? I mean the flashing black and white part.

If we fail to paint the background and just paint white thats a different problem (kicking off too many decodes of the image at many different sizes and they all compete and so take forever to complete). Whereas the black and white issue should hopefully be fixed.

Comment 20

[Alice0775 White]

I can still reproduce on the Latest Nightly.

https://hg.mozilla.org/mozilla-central/rev/66a77b9bfe5dcacd50eccf85de7c0e7e15ce0ffd
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 ID:20160928030201