Closed Bug 1158838 Opened 10 years ago Closed 9 years ago

Tile rendering bug observed on the Bugzilla Dashboard

Categories

(Core :: Graphics, defect)

Unspecified
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox38 - wontfix
firefox38.0.5 - wontfix
firefox39 + wontfix
firefox40 - wontfix
firefox41 - wontfix

People

(Reporter: ehsan.akhgari, Unassigned)

References

Details

(Whiteboard: gfx-noted)

Attachments

(3 files)

Like all of the tile rendering bugs that are currently affecting us, I can't reproduce this one either. :(
Whiteboard: gfx-noted
[Tracking Requested - why for this release]: I've been seeing unbelievable amounts of these types of issues for quite a while now. Nominating for release tracking.
Check about:support next time it happens, see if there are any comments or errors listed in the graphics section?
Flags: needinfo?(ehsan)
OS: Unspecified → Mac OS X
This is my about:supports from my current session: Asynchronous Pan/Zoom none Device ID 0x d26 GPU Accelerated Windows 4/4 OpenGL (OMTC) Supports Hardware H264 Decoding false Vendor ID 0x8086 WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 750M OpenGL Engine windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend quartz AzureFallbackCanvasBackend none AzureSkiaAccelerated 0 No special notes about any errors there right now...
Flags: needinfo?(ehsan)
Hi Florin, can you please try to repro this on a similar machine? Marking it as tracking for 39, 40 and 41.
Flags: needinfo?(florin.mezei)
(In reply to Milan Sreckovic [:milan] from comment #5) > Created attachment 8606288 [details] > An example error on MacBookPro Retina Survived bringing another window on top, getting back to it, etc.; it eventually went away, I think when mouse pointer moved over some area, but I'm not sure. I don't know if it would have gone away switching tabs, but I imagine it would. Nical, Markus, thoughts? Any areas where you would put debugging so that we could see potential failures in about:support?
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(mstange)
I can reproduce this fairly easily just clicking on different tests in tree herder.
As far as tracking - has anyone seen this on non-E10S build?
I only run e10s these days, so can't say whether it happens without it...
I saw some glitching with the TreeHerder progress bar in a non-e10s environment on 39.
This is too late for 38.
(In reply to Ritu Kothari from comment #4) > Hi Florin, can you please try to repro this on a similar machine? Marking it > as tracking for 39, 40 and 41. Assigning this to Bogdan - he'll have a look at this on our MacBook Pro with Retina.
Flags: needinfo?(florin.mezei)
QA Contact: bogdan.maris
I tried to reproduce this issue on a MacBook Pro (only Retina Mac machine we got here) using latest Nightly with e10s enabled and disabled, but with no success. Setup: MacBook Pro Retina, 15-inch, Late 2013 Processor 2 GHz Intel Core i7 Memory 8GB 1600 MHz DDR3 Graphics Intel Iris Pro 1024 MB Software OS X 10.9.5 (13F1077) Graphics Asynchronous Pan/Zoom none Device ID 0x d26 GPU Accelerated Windows 0/1 Basic (OMTC) Supports Hardware H264 Decoding false Vendor ID 0x8086 WebGL Renderer Intel Inc. -- Intel Iris Pro OpenGL Engine windowLayerManagerRemote true AzureCanvasBackend skia AzureContentBackend quartz AzureFallbackCanvasBackend none AzureSkiaAccelerated 0
(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #13) > I tried to reproduce this issue on a MacBook Pro (only Retina Mac machine we > got here) using latest Nightly with e10s enabled and disabled, but with no > success. > GPU Accelerated Windows 0/1 Basic (OMTC) Is hardware acceleration disabled for some reason? (Check about:preferences / Advanced.) I'd have expected to see something more like GPU Accelerated Windows 1/1 OpenGL (OMTC) on a retina mbpro.
(In reply to Milan Sreckovic [:milan] from comment #6) > (In reply to Milan Sreckovic [:milan] from comment #5) > > Created attachment 8606288 [details] > > An example error on MacBookPro Retina > > Nical, Markus, thoughts? Any areas where you would put debugging so that we > could see potential failures in about:support? If something bad is happening on the content side, it'd be interesting to see if we touch any of the NS_WARNING in TiledContentClient.cpp. If the issue happens on the host side, it'd be interesting to see whether my patch in bug 1150549 fixes the issue since it simplifies the code around update regions on the host side, by using the regions computed by the client rather than recomputing it.
Flags: needinfo?(nical.bugzilla)
(In reply to Nicolas Silva [:nical] from comment #15) > If the > issue happens on the host side, it'd be interesting to see whether my patch > in bug 1150549 fixes the issue since it simplifies the code around update > regions on the host side, by using the regions computed by the client rather > than recomputing it. There is a build with the patch here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/nsilva@mozilla.com-eeeb6afe9b49/try-macosx64/ If someone who can easily reproduce the issue can test this build it would be helpful.
(In reply to Milan Sreckovic [:milan] from comment #6) > Nical, Markus, thoughts? Any areas where you would put debugging so that we > could see potential failures in about:support? No idea, sorry. Nical is really the better person to comment on this code. The only piece of information I have is that the garbage was invisible to the texture dumping functions that the profiler uses, in the cases I managed to catch (assuming this really is bug 1146195).
Flags: needinfo?(mstange)
(In reply to Nicolas Silva [:nical] from comment #15) > (In reply to Milan Sreckovic [:milan] from comment #6) > > (In reply to Milan Sreckovic [:milan] from comment #5) > > > Created attachment 8606288 [details] > > > An example error on MacBookPro Retina > > > > Nical, Markus, thoughts? Any areas where you would put debugging so that we > > could see potential failures in about:support? > > If something bad is happening on the content side, it'd be interesting to > see if we touch any of the NS_WARNING in TiledContentClient.cpp. If the > issue happens on the host side, it'd be interesting to see whether my patch > in bug 1150549 fixes the issue since it simplifies the code around update > regions on the host side, by using the regions computed by the client rather > than recomputing it. Can you do a patch that changes that NS_WARNING to gfxCriticalError and we can look for it in about:support as we reproduce the problem? Also, if your patch to bug 1150549 fixes the issue, is there a patch you can put together for this bug that doesn't fix the issue but, again, does a critical error or even crash to alert us to the badness? I haven't looked at bug 1150549 to know whether this question makes any sense at all :)
Flags: needinfo?(nical.bugzilla)
There will be a build with the gfxCriticalErrors on the client side here https://treeherder.mozilla.org/#/jobs?repo=try&revision=bdfc23c3fcfa for the host code it's not clear where and what to assert, but this patch forces the first upload of a texture to be a full upload, which may affect the problem. I have been clicking around treeherder for 5 minutes on the mac I borrowed but I haven't managed to reproduce the issue there so if anyone can confirm or inform that the try the build on this comment and on comment 16 have an effect on this bug, it'd be great.
Flags: needinfo?(nical.bugzilla)
... and this one disables partial uploads entirely, which is probably not something we'd want to ship, but if it does fix the bug then it's very good to know. https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1c8bfac8128
I'd be good with landing the critical error change, leaving it "crashy" in the debug (the way it was written) so as to help us find a workflow to reproduce and see if the problems are related. Nical, can you land that change? Not the component alpha part, I presume, just the errors. I also see also'd bug 1166070, as it could make sense for these problems to be cross platform.
Flags: needinfo?(nical.bugzilla)
I did just see this on Dev Edition, so not E10S specific.
And if this https://bugzilla.mozilla.org/show_bug.cgi?id=1012547#c6 is the same problem, then it isn't tiling specific either.
Flags: needinfo?(nical.bugzilla)
Attachment #8609241 - Flags: review?(milan)
Comment on attachment 8609241 [details] [diff] [review] Add some gfxCriticalError logging. Review of attachment 8609241 [details] [diff] [review]: ----------------------------------------------------------------- The only minor change I would make would be to make the last three error messages unique (e.g., just add 1, 2, 3 somewhere in there) so that we know which one of the three triggered, since we don't get the line number reported from the gfxCriticalError.
Attachment #8609241 - Flags: review?(milan) → review+
Keywords: leave-open
It's getting late to take a fix for this in 39. We could still take a patch for 40.
I haven't seen this for a while - Ehsan?
Flags: needinfo?(ehsan)
I haven't either, but I have turned e10s off for a while, so it may also be because the bug doesn't happen in e10s...
Flags: needinfo?(ehsan)
Untracking it for 40 & 41. We didn't have most reports of this. We shipped 38 with it.
We're now past another couple releases without new reports of this issue. For now I'm closing this as incomplete. Please reopen if this is still an issue.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: