1146195 - Graphics issues: painting outdated or corrupt tiles (rendering artifacts)

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[bgstandaert]

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

[Markus Stange [:mstange]]

I've been seeing this a lot in the past one or two weeks.

Comment 2

[Markus Stange [:mstange]]

Attachment: screenshot

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

[Markus Stange [:mstange]]

This happens more frequently if my machine is under heavy load.

Comment 4

[Guilherme Lima]

Dupe of bug 1067470?

Comment 5

[Markus Stange [:mstange]]

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

[Markus Stange [:mstange]]

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.

Comment 7

[Nicolas Silva [:nical]]

(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.

Comment 8

[bgstandaert]

Attachment: another example. Part of the text is the default "search or enter address", and part it the title of a previous page I was on

Comment 10

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

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?

Comment 11

[Nicolas Silva [:nical]]

(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").

Comment 12

[Nicolas Silva [:nical]]

Oh my. I think we are just releasing the copy-on-write locks before uploading the textures on the host side.

Comment 13

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

+1 on tracking this for 39.

Comment 14

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

Tracking this for 39+.

Comment 15

[Nicolas Silva [:nical]]

(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).

Comment 17

[Nicolas Silva [:nical]]

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.

Comment 18

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

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 ?

Comment 19

[Nicolas Silva [:nical]]

(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.

Comment 20

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

Related (or same) as bug 1158838?

Comment 21

[Markus Stange [:mstange]]

Probably the same. Note that bug 1152468 has steps to reproduce.

Comment 22

[Nicolas Silva [:nical]]

(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.

Comment 24

[Nicolas Silva [:nical]]

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.

Comment 25

[bgstandaert]

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

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

Wontfix for 39 at this point. Sounds like there is a good chance this may work now. Fingers crossed!

Comment 27

[bgstandaert]

I still haven't seen this again, so I think it is fixed now.

Comment 29

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

Based on bug 1168371 which is a dup of this bug, adding a tracking flag for Firefox41 here.

Comment 30

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

If this turns out to still be a problem, re-open; we have two bugs listed as (possibly) responsible for fixing it.

Comment 31

[Lawrence Mandel [:lmandel] (use needinfo)]

Marking status of 40 and 41 as fixed. We can revisit if this crops back up.