Display Issue - Horizontal blue lines in application windows

cambsGooner wrote:

As you can see from the image below I have blue horizontal lines appearing within my Chrome application window

2019 Macbook Pro 16

https://discussions.apple.com/content/attachment/8a8d52eb-2aef-487c-90b7-53ddf997baac

The application is the latest build of Chrome Version 80.0.3987.163 (Official Build) (64-bit)

It has happened 3 times now - each time appear to be after the laptop has been left running overnight.

Not it is not the full display affected only the application window. I've also only seen this in the chrome browser (I've also posted this to the Chrome support site) it sometimes goes away simply by killing Chrome but this time required a reboot.

Anyone seen this before - got any ideas??

https://discussions.apple.com/content/attachment/ab77ce96-f73e-4e12-a741-ff66ffd7525c

Try resetting NVRAM/PRAM http://support.apple.com/kb/ht1379

I was having the same issue. I found a post on Google Support which worked for me.

I went into Chrome settings and toggled off the "Use hardware acceleration when available" option. Then hit the "relaunch" button next to the hardware acceleration toggle and the problem was fixed - no blue tint anymore.

I just "upgraded" to the 16" MBP and this blue line issues started. It so far has only effected Notion, must be the browser the Mac app is using. Chromium? 🤷🏼‍♂️ Anyway I am somewhat relieved this is a known issue. At lease it is not just my unit. Hopefully an OS update fixes it. I have also, been having overheating and fan issues, might be related to this.

Has anyone tried to reset the SMC?

https://support.apple.com/en-us/HT201295

For the record, I cleared NVRAM or "PRAM" several times in a row yesterday and left my computer on overnight. For the first time in a while there was no message about the computer restarting unexpectedly or any funky lines in my apps that have hardware acceleration in the morning. Seems to be working so far.

How to reset NVRAM or PRAM on your Mac -> https://support.apple.com/en-us/HT204063

I take that back. If it fixed anything, it was temporary. It's right back to the same problems.

joshintosh wrote:

For the record, I cleared NVRAM or "PRAM" several times in a row yesterday and left my computer on overnight. For the first time in a while there was no message about the computer restarting unexpectedly or any funky lines in my apps that have hardware acceleration in the morning. Seems to be working so far.

How to reset NVRAM or PRAM on your Mac -> https://support.apple.com/en-us/HT204063

This fixed it. It was set on the default.

OpenGL is being deprecated with Metal taking its place. Looking forward (Chrome Canary) there are reports this flag will be removed.

https://developer.apple.com/metal/

Everybody with this issue, please use https://www.apple.com/feedback/ and tell them your problems. The more attention this gets, the more likely it will be fixed. They do not monitor the community it seems.

Resetting NVRAM/PRAM is a temporary fix.

Disabling graphics acceleration is not a solution,

1. Not every application allows disabling graphics acceleration
2. Even if you disable it, the computer fan goes nuts and battery life goes down, and your laptop crawls like a $200 PC laptop.

The common denominator here is MBPro16". Apple needs to fix this bug.

You're getting a kernel panic and it's causing a restart.

This happens because your computer is connected to an external monitor. (These machines don't play nice with external monitors, but that's a whole 'nother 100+ page can of worms.)

To prevent the kernel panics, you should

1. Disconnect from the external monitor before computer goes to sleep OR
2. Manually put the computer to sleep each time, instead of it letting it do it by itself AND
3. Disable power nap and wake by wifi

If you don't do number 3 and you leave it connected to an external monitor (as most who use external monitors do) your computer will routinely wake by itself and when it does that, it will obviously fall asleep by itself instead of you clicking the sleep button. That will eventually cause a kernel panic.

This has been reported in the Chromium bug tracker – Big Sur beta 10 has not addressed the issue, but no reports on 11.0.1: https://bugs.chromium.org/p/chromium/issues/detail?id=1068170#c185

I don't see any reason for me to install beta operating systems on my development machine that I rely on to make a living just to test if this big hot mess is resolved. Unfortunately, I don't have the luxury (or inclination) of having another identical mbp to conduct such tests either. I'm sure many others feel the same way too.

Here's a list of software that are confirmed to have this problem – feel free to add to this, everyone:

1. Google Chrome (specifically, WebGL content)
2. Adobe Lightroom
3. Microsoft Teams
4. Miro
5. Spotify

This is my current 'testing' routine that I run whenever glitches begin to occur in Chrome. I launch the applications in this list below to see if the glitch carries over to other applications – in all instances this has happened, the glitch shows up across the board.

Safari now added to the list too, with versions added.

Current list of software known to have the blue glitches (when it triggers):

1. Safari Version 14.0 (15610.1.28.1.9, 15610) (specifically, WebGL content)
2. Google Chrome 86.0.4240.111 (Official Build) (x86_64) (specifically, WebGL content)
3. Miro 0.4.2 – main window doesn't glitch, but Developer Tools does
4. Spotify 1.1.45.621.gdddebadc – main window doesn't glitch, but speaker selection popup does

Interestingly, these two applications below seem to have been 'fixed' – perhaps via a recent update from the developers? Did they figure out a way to work around the hardware acceleration glitch?

1. Adobe Lightroom Classic 9.3 Build [202005281810-476e492c]
2. Microsoft Teams 1.3.00.28778

So the signs point to something that is potentially fixable software-wise, which perhaps is a relief (compared to a hardware fault).

Hey Apple, Safari has now joined the blue glitch list. Can you raise this as a priority bug now to investigate?

Added Firefox to the list.

It's just a theory right now, but here's the following account of how my glitches occur:

1. Typically, the glitches trigger especially after the mbp wakes from sleep after a longish period (a few hours to overnight – this has been experienced rather consistently since April)
2. The likelihood of the glitch triggering is much higher if I have webGL / HW-accelerated graphic views actively rendered when the mbp goes to sleep
3. After the glitch triggers, any application that attempts to access hardware-accelerated graphics in a particular way/routine will result in the glitch in the application as well – in this case, Chromium being one candidate, but now we know that Safari and Firefox do the same too. For example, I could wake the mbp in the morning, get the glitch in Safari, and have this same glitch show up by opening any software in the list below
4. This problem is not necessarily tied directly to Chromium anymore. Could this be a deeper hardware fault?

Current list of software known to have the blue glitches (when it triggers, see above):

1. Safari Version 14.0 (15610.1.28.1.9, 15610) (specifically, WebGL content)
2. Firefox 82.0.2 (64-bit) (specifically, WebGL content)
3. Google Chrome 86.0.4240.111 (Official Build) (x86_64) (specifically, WebGL content)
4. Miro 0.4.2 – main window doesn't glitch, but Developer Tools does
5. Spotify 1.1.45.621.gdddebadc – main window doesn't glitch, but speaker selection popup does

As I mentioned in my previous comments, interestingly, the two applications listed below seem to not have the glitches anymore – perhaps via a recent update from the developers? Did they figure out a way to work around the hardware acceleration glitch, or simply chose not to rely on h/w acceleration for some of the views causing the problem?

1. Adobe Lightroom Classic 9.3 Build [202005281810-476e492c]
2. Microsoft Teams 1.3.00.28778

Added MS VS Code to the list.

It's just a theory right now, but here's the following account of how my glitches occur:

1. Typically, the glitches trigger especially after the mbp wakes from sleep after a longish period (a few hours to overnight – this has been experienced rather consistently since April)
2. The likelihood of the glitch triggering is much higher if I have webGL / HW-accelerated graphic views actively rendered when the mbp goes to sleep
3. After the glitch triggers, any application that attempts to access hardware-accelerated graphics in a particular way/routine will result in the glitch in the application as well – in this case, Chromium being one candidate, but now we know that Safari and Firefox do the same too. For example, I could wake the mbp in the morning, get the glitch in Safari, and have this same glitch show up by opening any software in the list below
4. This problem is not necessarily tied directly to Chromium anymore. Could this be a deeper hardware fault?

Current list of software known to have the blue glitches (when it triggers, see above):

1. Safari Version 14.0 (15610.1.28.1.9, 15610) (specifically, WebGL content)
2. Firefox 82.0.2 (64-bit) (specifically, WebGL content)
3. Google Chrome 86.0.4240.111 (Official Build) (x86_64) (specifically, WebGL content)
4. Microsoft Visual Studio Code 1.50.1 – main window doesn't glitch, but Developer Tools does
5. Miro 0.4.2 – main window doesn't glitch, but Developer Tools does
6. Spotify 1.1.45.621.gdddebadc – main window doesn't glitch, but speaker selection popup does

As I mentioned in my previous comments, interestingly, the two applications listed below seem to not have the glitches anymore – perhaps via a recent update from the developers? Did they figure out a way to work around the hardware acceleration glitch, or simply chose not to rely on h/w acceleration for some of the views causing the problem?

1. Adobe Lightroom Classic 9.3 Build [202005281810-476e492c]
2. Microsoft Teams 1.3.00.28778

I reckon all Electron-based application (that use Chromium for rendering) should be reported, to provide a clearer picture of the extent of the glitch and how it's impacting end-users. Not many folks know that Electron is the basis for many standalone web apps out there.

From the Chromium Bug Tracker, which is now closed to comments "for the time being":

Everyone: Apple has indicated that they have created a more reliable set of steps to reproduce this in-house and continue to investigate it.

Current list of software known to have the blue glitches:

1. Safari Version 14.0 (15610.1.28.1.9, 15610) (specifically, WebGL content)
2. Firefox 82.0.2 (64-bit) (specifically, WebGL content)
3. Google Chrome 86.0.4240.111 (Official Build) (x86_64) (specifically, WebGL content)

Electron/Chromium-rendered applications exhibit more 'targeted' glitching, i.e. in specific WebGL windows/views. But they all show similar behaviour. A sure-fire way to see the glitches, when they have been triggered, is to bring up the Developer Tools window (if it is available in the application).

Current list of Electron/Chromium software known to have the blue glitches:

1. Microsoft Visual Studio Code 1.50.1 – main window doesn't glitch, but Developer Tools does
2. Miro 0.4.2 – main window doesn't glitch, but Developer Tools does
3. Spotify 1.1.45.621.gdddebadc – main window doesn't glitch, but speaker selection popup does
4. Brave Browser Version 1.16.72
5. Notion.so Version 2.0.8 (2.0.8)

As I mentioned in my previous comments, interestingly, these two applications listed below seem to be resolved, despite them have past reports of having the glitch. Did the devs figure out a way to work around the hardware acceleration glitch, or simply chose not to rely on h/w acceleration for views that exhibit the glitch?

1. Microsoft Teams 1.3.00.28778
2. Adobe Lightroom Classic 9.3 Build [202005281810-476e492c]

@brain_ : Well, for starters, this discussion thread has been flagged by a Level 10 community member @leroydouglas with a solution that Apple has recommended.

It is very clear that this 'recommended solution' does not work. Unless you're happy resetting NVRAM every time the glitches appear. But the true workaround to resetting NVRAM is that the restart of your computer during said process is the step that temporarily fixes the issue. Nothing to do with NVRAM at all. I likened this previously to having your car mechanic change the engine oil for anything that's gone wrong; put in a decently complex reset keyboard sequence and most non-tech folks will probably see it as a legitimate initialisation cure-all. Granted it is a good troubleshooting step to perform, but it is not the solution here.

So, as long as there are folks here (and on the Chrome discussion list) claiming one of the following as 'fixes', we will never see an expedited resolution to this. Perhaps the next generation MBP will make us forget about it?

1. Disable H/W acceleration – this is actually needed to perform WebGL work
2. Toggle Automatic Graphics Switching – never worked for me (although others have claimed it does?)
3. Reset NVRAM – might as well go change the engine oil in your car while you're at it

For the devs out here still suffering from this issue, is it ok to suggest that you open a support case so that this can be heard more loudly from more of us. It just might be the fact that it's not on the priority list, or that it's being looked into actively, but we'll never quite know at this rate.