Closed
Bug 1256211
Opened 8 years ago
Closed 8 years ago
After switching tabs, background image is never drawn if the animation is continuing
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox47 | --- | unaffected |
firefox48 | --- | wontfix |
firefox49 | --- | wontfix |
firefox50 | --- | wontfix |
People
(Reporter: alice0775, Assigned: seth)
References
Details
(Keywords: regression, Whiteboard: gfx-noted)
Attachments
(1 file)
929.59 KB,
application/x-zip-compressed
|
Details |
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•8 years ago
|
||
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).
Reporter | ||
Comment 2•8 years ago
|
||
Updated•8 years ago
|
Whiteboard: gfx-noted
Updated•8 years ago
|
Assignee: nobody → seth
Alice, I assume this also affects Firefox 49. Can you please confirm?
status-firefox49:
--- → ?
Flags: needinfo?(alice0775)
Reporter | ||
Comment 5•8 years ago
|
||
(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
Flags: needinfo?(alice0775)
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?
Reporter | ||
Comment 7•8 years ago
|
||
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: loop@mozilla.org Name: Multi-process staged rollout Version: 1.0 Enabled: true ID: e10srollout@mozilla.org Name: Pocket Version: 1.0 Enabled: true ID: firefox@getpocket.com Name: Web Compat Version: 1.0 Enabled: true ID: webcompat@mozilla.org 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.
(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 :)
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.
Flags: needinfo?(tnikkel)
Flags: needinfo?(seth)
Comment 11•8 years ago
|
||
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.
Flags: needinfo?(tnikkel)
Comment 12•8 years ago
|
||
(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.
Assignee | ||
Comment 13•8 years ago
|
||
(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.
Flags: needinfo?(seth)
Comment 14•8 years ago
|
||
(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.
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.
Alice, is the problem gone with the build from comment 15?
Flags: needinfo?(alice0775)
Reporter | ||
Comment 17•8 years ago
|
||
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
Flags: needinfo?(alice0775)
Reporter | ||
Comment 18•8 years ago
|
||
There are no similar bug, So, I think it is no longer tracking is necessary
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox50:
--- → wontfix
tracking-firefox48:
+ → ---
tracking-firefox49:
+ → ---
Resolution: --- → WONTFIX
Comment 19•8 years ago
|
||
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.
Flags: needinfo?(alice0775)
Reporter | ||
Comment 20•8 years ago
|
||
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
Flags: needinfo?(alice0775)
You need to log in
before you can comment on or make changes to this bug.
Description
•