Closed
Bug 1146195
Opened 9 years ago
Closed 9 years ago
Graphics issues: painting outdated or corrupt tiles (rendering artifacts)
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
People
(Reporter: bgstandaert, Assigned: nical)
References
Details
(Whiteboard: gfx-noted)
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150320030211 Steps to reproduce: Since updating to latest nightly (to 3/20/15 from 3/11/15), there have been large amounts of graphical issues with the browser. Actual results: I can't find exact steps to reproduce. Sometimes part of a tab looks selected and part doesn't. Sometimes part of the urlbar field has a blue highlight around it and looks selected, and part doesn't. Sometimes part of the tabstrip looks like it is the active window, and part doesn't. I will try to attach a screenshot the next time this happens. Expected results: These things shouldn't happen.
Comment 1•9 years ago
|
||
I've been seeing this a lot in the past one or two weeks.
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics: Layers
Ever confirmed: true
Product: Firefox → Core
Hardware: x86 → All
Summary: graphics issues in latest nightly → Graphics issues: painting outdated or corrupt tiles (rendering artifacts)
Comment 2•9 years ago
|
||
Here's a screenshot of a halfway-switched tab. I was able to capture a profile with layer contents, and it looks like this is a compositor bug: The compositor has up-to-date content, it's just not compositing the right tile.
Comment 3•9 years ago
|
||
This happens more frequently if my machine is under heavy load.
Comment 4•9 years ago
|
||
Dupe of bug 1067470?
Comment 5•9 years ago
|
||
Don't think so - that bug is Windows only, and this one looks related to tiles, and we're not using tiling on Windows.
Comment 6•9 years ago
|
||
Nical, do you have time to take a look at this? Something must be different between how the profiler gets the tile texture contents and how the compositor decides what textures to paint for a tile (or what tile to paint)... I don't have a good grasp on how exactly this works, but maybe you can find something by code inspection, or suggest places where we can add sleep calls to make this reproduce more easily.
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 7•9 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #6) > Nical, do you have time to take a look at this? Something must be different > between how the profiler gets the tile texture contents and how the > compositor decides what textures to paint for a tile (or what tile to > paint)... I don't have a good grasp on how exactly this works, but maybe you > can find something by code inspection, or suggest places where we can add > sleep calls to make this reproduce more easily. I am currently looking into something that may be related to this.
Assignee: nobody → nical.bugzilla
Flags: needinfo?(nical.bugzilla)
Reporter | ||
Comment 8•9 years ago
|
||
Seen this on 10.9.5, just in case we thought it was specific to 10.10. I'll attach a screengrab next time it happens. I want to track this for 39, it probably started in that release, judging by comment 1. Nical, is this DrawTargetTiled that we're hoping fixes it?
status-firefox39:
--- → affected
status-firefox40:
--- → affected
tracking-firefox39:
--- → ?
tracking-firefox40:
--- → ?
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 11•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #10) > > Nical, is this DrawTargetTiled that we're hoping fixes it? DrawTargetTiled is already enabled on OSX, so no. I am in the hope that maybe understanding the R14 intermittent that has been haunting me for a quarter will help with this, or that understanding this will help with the R14 issue (both problems seem to be tiling related with proper content on the child side and wrong things displayed by the compositor, although with different "wrong things").
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 12•9 years ago
|
||
Oh my. I think we are just releasing the copy-on-write locks before uploading the textures on the host side.
+1 on tracking this for 39.
Assignee | ||
Comment 15•9 years ago
|
||
(In reply to Nicolas Silva [:nical] from comment #12) > Oh my. I think we are just releasing the copy-on-write locks before > uploading the textures on the host side. Actually, I spoke too fast. Nevermind comment 12. I am working on a patch in bug 1150549 that simplifies TiledContentHost a lot and may fix this. If it does, depending on how long it takes me to get the patch landed we may want to uplift it or find a separate fix for 39 (but at least it will tell us that the problem is related to gfxSharedReadLock or texture uploads).
Assignee | ||
Comment 17•9 years ago
|
||
I have a good theory about this bug: we have an optimization in BufferTextureHost (used for tiling on mac) that avoid the texture upload in certain situations. Turns out this optimization has been tuned for the way we use TextureHost and TextureSource in ImageLayers specifically and there appears to be a subtle difference in tiled layers, which makes it so that this code thinks it can skip the upload even though it actually should not.
Updated•9 years ago
|
Whiteboard: gfx-noted
Comment 18•9 years ago
|
||
Sounds like this is likely a regression and we have a possible fix coming in bug 1150549. Nical, are you still going for a fix in 39 ?
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 19•9 years ago
|
||
(In reply to Liz Henry (:lizzard) from comment #18) > Sounds like this is likely a regression and we have a possible fix coming in > bug 1150549. > > Nical, are you still going for a fix in 39 ? Sorry, I forgot to update this bug. So my last few theories didn't turn out to be true. I am still looking into this but I don't have any ETA since I the cause of the problem is still unclear.
Flags: needinfo?(nical.bugzilla)
Related (or same) as bug 1158838?
Flags: needinfo?(nical.bugzilla)
Comment 21•9 years ago
|
||
Probably the same. Note that bug 1152468 has steps to reproduce.
Assignee | ||
Comment 22•9 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #20) > Related (or same) as bug 1158838? Could be, not sure. This shows garbage content so it could be something going wrong with binding the texture, or a bug with the update region on the compositor side (and we just happened to have created a texture which on gpu memory that was used for another tile before, and updated only a portion of it instead of the whole thing). If it's the latter it could be the same bug.
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 24•9 years ago
|
||
Bug 1150549 which has a rather large impact on tiling just made it to central. For those who can reproduce this bug easily, please let me know if it still happens on the latest nightly.
Reporter | ||
Comment 25•9 years ago
|
||
So far, I can no longer reproduce. However, the frequency of this varies a lot, so I'll give it a few more days.
Comment 26•9 years ago
|
||
Wontfix for 39 at this point. Sounds like there is a good chance this may work now. Fingers crossed!
Reporter | ||
Comment 27•9 years ago
|
||
I still haven't seen this again, so I think it is fixed now.
Based on bug 1168371 which is a dup of this bug, adding a tracking flag for Firefox41 here.
status-firefox41:
--- → affected
tracking-firefox41:
--- → +
If this turns out to still be a problem, re-open; we have two bugs listed as (possibly) responsible for fixing it.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Comment 31•9 years ago
|
||
Marking status of 40 and 41 as fixed. We can revisit if this crops back up.
You need to log in
before you can comment on or make changes to this bug.
Description
•