1184961 - Flickering on fast updating javascript pages due to DrawImage

Status: RESOLVED INVALID

(Core :: Graphics, defect, P3)

Description

[merlin.schumacher]

Attachment: Bildschirmfoto am 2015-07-17 um 12.55.04.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150706004011

Steps to reproduce:

Visit http://www.monsterzeug.de/Hochzeit-in-Echtzeit


Actual results:

Viewing the page on Firefox in Windows causes graphical glitches on some(!) machines. It looks as if a invisible square lies over the other boxes and causes them to glitch. Fonts also get smeared. This bug does not appear with Firefox in Linux, nor other Windows browsers.
The attached screenshot was made with firefox' internal screenshot function on windows. I've seen two machines so far showing this behaviour.


Expected results:

The page should be rendered flicker and glitch free.

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Hello

Post your Graphic section from about:support,
next make sure that you're using latest GPU drivers,
if not, update it and redo the STR and post info from about:support again.

Can you reproduce the issue in Safe Mode[1]?
If yes and you can reproduce the issue in Safe Mode,
can you still reproduce it even with clean new fresh profile without any addons (extensions and plugins)[2]?

You can also try a standard troubleshoot and diagnose procedure[3].



[1] = https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode
[2] = https://support.mozilla.org/kb/refresh-firefox-reset-add-ons-and-settings
[3] = https://support.mozilla.org/kb/troubleshoot-and-diagnose-firefox-problems
[4] = https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines

Comment 2

[merlin.schumacher]

Attachment: graphics_driver.png

I tried the site in safe-mode and it works. It does show the flickering when using a clean new profile. The graphics drivers are up-to-date. This attachment is a screenshot of the graphics driver

Comment 3

[u279076]

If this bug goes away in safe mode it's possible there's an add-on causing the issue. To debug this further please run Firefox normally and disable the add-ons one by one until the bug disappears. If the bug still exists with all add-ons disabled then that rules them out as the cause.

Comment 4

[merlin.schumacher]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #3)
> If this bug goes away in safe mode it's possible there's an add-on causing
> the issue. To debug this further please run Firefox normally and disable the
> add-ons one by one until the bug disappears. If the bug still exists with
> all add-ons disabled then that rules them out as the cause.

As i wrote it also happens with a new profile created through the profile manager of firefox. To make sure i disabled all plugins and addons, yet the issue persists.

Comment 5

[u279076]

Okay, but you said in comment 2, "I tried the site in safe-mode and it works." Does that mean the bug still reproduces in safe mode or it does not? Please clarify because I'm genuinely quite confused right now.

Comment 6

[merlin.schumacher]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #5)
> Okay, but you said in comment 2, "I tried the site in safe-mode and it
> works." Does that mean the bug still reproduces in safe mode or it does not?
> Please clarify because I'm genuinely quite confused right now.

Sorry for confusing you. The bug doesn't appear in safe mode. It appears when using Firefox in "normal" mode,it doesn't matter if it's in a new profile or a used one. Manually disabling all extensions in normal mode also doesn't help. 
Safe mode: bug gone
Everything else: flickering

Comment 7

[u279076]

Thanks for clarifying. I know that safe mode disables some things other than add-ons that may explain why this doesn't happen there but does in a new profile. Milan, do you have any insights to debug this further?

Comment 8

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

We should have an HD 3000 locally, I'll see if we can reproduce.  Kyle, can you take a look?

Comment 9

[Kyle Fung]

Was able to reproduce this on the X220 in the office with slightly different glitching:

Name: Firefox
Version: 42.0a1
Build ID: 20150722030205
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:42.0) Gecko/20100101 Firefox/42.0
Multiprocess Windows: 1/1 (default: true)
Safe Mode: false

Adapter Description: Intel(R) HD Graphics 3000
Adapter Drivers: igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Adapter RAM: Unknown
Asynchronous Pan/Zoom: none
Device ID: 0x0126

It looks like our HD 3000's have a slightly different device ID. Turning off D2D 1.1 made the glitching go away, so it's probably a bug in our D2d 1.1 code.

merlin, can you try going to about:config and turning gfx.direct2d.use1_1 to false, and then restarting the browser?

Comment 10

[Kyle Fung]

Attachment: glitching_on_x220.png

Comment 11

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

Kyle, feel free to keep looking at this, and we'll rope Bas into it as well.

Comment 12

[merlin.schumacher]

(In reply to kfung from comment #9)
> Was able to reproduce this on the X220 in the office with slightly different
> glitching:
> 
> Name: Firefox
> Version: 42.0a1
> Build ID: 20150722030205
> Update Channel: nightly
> User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:42.0) Gecko/20100101
> Firefox/42.0
> Multiprocess Windows: 1/1 (default: true)
> Safe Mode: false
> 
> Adapter Description: Intel(R) HD Graphics 3000
> Adapter Drivers: igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32
> igd10umd32
> Adapter RAM: Unknown
> Asynchronous Pan/Zoom: none
> Device ID: 0x0126
> 
> It looks like our HD 3000's have a slightly different device ID. Turning off
> D2D 1.1 made the glitching go away, so it's probably a bug in our D2d 1.1
> code.
> 
> merlin, can you try going to about:config and turning gfx.direct2d.use1_1 to
> false, and then restarting the browser?

I did. Setting it to false fixes the issue.

Comment 13

[u279076]

[Tracking Requested - why for this release]: Regression since Firefox 37 which can be worked around by disabling D2D1.1. Can we blocklist/hotfix this until a proper fix can be found?

Comment 14

[Kyle Fung]

Attachment: SkeletonD2D.trace

The problem is that we are using an ImageBrush (created by DrawTargetD2D1::CreateBrushForPattern) to draw, and Intel's drivers seem to be having problems with ImageBrushes. This is the apitrace of a simple skeleton application filling a rect using an ImageBrush.

Comment 15

[Kyle Fung]

Attachment: SkeletonD2D.zip

The code for the skeleton application is here.

Comment 16

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

Adding David in case we can do something based on comment 15 code as a startup test for "should we blocklist this combo".
Bas, do we have an alternative to using ImageBrushes?

Comment 17

[David Anderson [:dvander] - inactive, e-mail if emergency]

If the bug can be determined by a readback from Kyle's demo, yeah it would be very reasonable to do a startup test to get some telemetry data.

In a 1% sample of release pings (773409 sessions):
  34969 have one of these device IDs.
  8770 have the driver version in comment #0.
  3698 have one of those devices with that driver.

But we don't really know exactly which drivers/devices this fails for yet.

Comment 18

[Kyle Fung]

(In reply to David Anderson [:dvander] from comment #17)
> If the bug can be determined by a readback from Kyle's demo, yeah it would
> be very reasonable to do a startup test to get some telemetry data.
> 

The bug is not actually exhibited in the demo. This was just to get an idea of how drawing with ImageBrushes are implemented. Coming up with a reduced test case that only exhibits the bug seems kind of impossible at this point.

Comment 19

[Bas Schouten (:bas.schouten)]

(In reply to kfung from comment #18)
> (In reply to David Anderson [:dvander] from comment #17)
> > If the bug can be determined by a readback from Kyle's demo, yeah it would
> > be very reasonable to do a startup test to get some telemetry data.
> > 
> 
> The bug is not actually exhibited in the demo. This was just to get an idea
> of how drawing with ImageBrushes are implemented. Coming up with a reduced
> test case that only exhibits the bug seems kind of impossible at this point.

Is there anything we could do in the callers for this case to reduce the usage of imagebrushes?

Comment 20

[u279076]

Bas, are you still working on this?

Comment 21

[Bas Schouten (:bas.schouten)]

(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #20)
> Bas, are you still working on this?

Nope.

Comment 22

[Bas Schouten (:bas.schouten)]

No longer relevant with WR.