Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atom Dark Layout Issue on MacOS Sierra GM #12634

Closed
iphoneintosh opened this issue Sep 8, 2016 · 47 comments
Closed

Atom Dark Layout Issue on MacOS Sierra GM #12634

iphoneintosh opened this issue Sep 8, 2016 · 47 comments

Comments

@iphoneintosh
Copy link

@iphoneintosh iphoneintosh commented Sep 8, 2016

Prerequisites

Description

The Atom Editor uses a darker grey background color in the edited area of the editor and in the untouched area a normal grey color. This issue occurs in

  • Atom Dark
  • One Dark
  • Solarized Dark

bildschirmfoto 2016-09-08 um 16 53 23

### Steps to Reproduce 1. Open Atom 1.10.2 on MacOS Sierra Golden Master Release 2. Use a dark layout

Expected behavior: single backgound color grey

Actual behavior: 2 different background colours in one editor (dark and light grey)

Versions

Atom : 1.10.2
Electron: 0.37.8
Chrome : 49.0.2623.75
Node : 5.10.0
OS: MacOS Sierra Golden Master 64bit

@Greenek
Copy link

@Greenek Greenek commented Sep 14, 2016

The same problem with atom-material-ui. Glitches are pretty random and sometimes after window resize problem disappears for a while.

zrzut ekranu 2016-09-14 o 14 46 52

Atom: 1.11.0-beta5
Electron: 0.37.8
Chrome: 49.0.2623.75
Node: 5.10.0
OS: macOS Sierra GM

@simurai
Copy link
Member

@simurai simurai commented Sep 16, 2016

Just from a gut feeling, this looks like some GPU rendering issue. Like if the textures that get sent to the GPU are missing in some places. Also because the width seems to be 256px and I think that's how large GPU tiles are? /cc @as-cii

screen shot 2016-09-16 at 9 08 33 am

Electron (+ Chromium) just got updated, so that might fix this issue in Atom 1.12.

@Greenek
Copy link

@Greenek Greenek commented Sep 16, 2016

I made a little investigation and I found that problem affects probably all electron applications with dark elements, but only at monitors with custom color profiles (for example with non-native gamma value). This issue didn't occur before, so I guess it can be related with Wide Color support introduced in Sierra.

Edit: It's probably Chromium bug - #633805

@thomasjo
Copy link
Member

@thomasjo thomasjo commented Sep 16, 2016

This is indeed caused by https://bugs.chromium.org/p/chromium/issues/detail?id=633805. Good find @Greenek!

@atom/feedback I marked this as electron, but technically speaking this is caused by rendering bug in Chromium. Do we leave this open here until it gets resolved upstream and ultimately makes it way through to us?

@thomasjo thomasjo added the blocked label Sep 16, 2016
@Greenek
Copy link

@Greenek Greenek commented Sep 16, 2016

BTW bug looks to be fixed in Chromium 54.0.2840.27 (beta) and higher. For now, the only solution for affected users is changing monitor's color profile.

@iolsen
Copy link
Member

@iolsen iolsen commented Sep 16, 2016

Do we leave this open here until it gets resolved upstream and ultimately makes it way through to us?

Yeah let's leave it open until we get the Chromium fix or find another workaround.

@Greenek
Copy link

@Greenek Greenek commented Sep 16, 2016

I found the solution. Problem disappears when Chromium has GPU rasterization enabled, so running Atom (or any other Electron app) with --force-gpu-rasterization or --enable-gpu-rasterization does the trick.

Related: #3787

@pedantic79
Copy link

@pedantic79 pedantic79 commented Sep 22, 2016

Another solution is to run atom with --disable-gpu.

@thomasjo
Copy link
Member

@thomasjo thomasjo commented Oct 4, 2016

Just a quick update; the underlying problem in Chromium has been fixed, and should be released with Chromium 54.

This means once Electron bumps to that release, we'll resolve this issue once we bump to the corresponding Electron release.

@schrej
Copy link

@schrej schrej commented Dec 13, 2016

As it seems to take a long time until Electron adopts Chromium 54 because there are some difficulties (see electron/electron#7744 and the project), would it be possible to automatically start atom without GPU rendering when the os is MacOS Sierra?

@lee-dohm
Copy link
Member

@lee-dohm lee-dohm commented Dec 15, 2016

@schrej That isn't something that we would add to Atom as a default, no, because not everyone on macOS Sierra experiences this problem.

@andrrra
Copy link

@andrrra andrrra commented Dec 15, 2016

@lee-dohm I don't think everyone on Sierra experiences this issue. I know a lot of people who don't.

@lee-dohm
Copy link
Member

@lee-dohm lee-dohm commented Dec 15, 2016

@zachbpd Yes, that's exactly my point.

@schrej
Copy link

@schrej schrej commented Dec 16, 2016

@lee-dohm @zachbpd Ah all right, i wasn't aware of that. Maybe this is related to which graphics are built into the macs (dedicated GTX 750M for me)?
Maybe a config option to disable gpu rendering would be an idea then if thats possible and not too hard to do? Or are there any macOS tricks i'm not aware of?

If you don't care for such temporary issues i'm fine with that by the way, just looking for a good solution as it is really annoying to start with --disable-gpu all the time and electron with chrome 54 will need a few months i guess.

@Greenek
Copy link

@Greenek Greenek commented Dec 16, 2016

@schrej:

I found that problem affects probably all electron applications with dark elements, but only at monitors with custom color profiles (for example with non-native gamma value).

@lee-dohm
Copy link
Member

@lee-dohm lee-dohm commented Dec 17, 2016

@schrej Yeah, adding an option just to take it out again in a couple of releases isn't something that we want to do. Additionally, we prefer if --disable-gpu remains as an advanced user option rather than something that anyone can accidentally click on and then the performance of Atom is significantly impacted ☹️

@erwstout
Copy link

@erwstout erwstout commented Dec 22, 2016

I don't think everyone on Sierra experiences this issue. I know a lot of people who don't.

I'm also experiencing this issue, for what its worth.

screen shot 2016-12-22 at 10 50 50 am

@diedummydie
Copy link

@diedummydie diedummydie commented Dec 26, 2016

As per @Greenek's advice, a temporary workaround if you launch Atom from the Terminal is to create an alias that always sets the enable-gpu-rasterization flag:

vim ~/.bash_profile

(or nano ~/.bash_profile if you're not a fan of vim)

Append the alias:

# added to fix Electron gpu tiles with macOS 10.12
alias atom="atom --enable-gpu-rasterization"

Save and close the file, then reload your profile:

source ~/.bash_profile
@aomega08
Copy link

@aomega08 aomega08 commented May 17, 2017

Hi, running on 1.17.0. The problem appears only on external displays. If I move the window to the main Macbook display, it's ok. If I move it to the other screen, appears again.

atom --enable-gpu-rasterization did not solve for me. My Mac has "Radeon Pro 450 2048 MB
Intel HD Graphics 530 1536 MB"

@schrej
Copy link

@schrej schrej commented May 17, 2017

@aomega08 As mentioned here a few times already, the issue appears on Screens with custom color profiles. You could just disable the custom profile on your external monitor. Also try --disable-gpu (also mentioned a few times already).

@montanaflynn
Copy link

@montanaflynn montanaflynn commented May 17, 2017

It happened on my external asus display, I switched the custom profile to sRGB IEC61966-2.1 and the problem went away or at least ins't noticable. None of the other color profiles worked though.

@reaver585
Copy link

@reaver585 reaver585 commented May 18, 2017

Correction to my above post:

In fact atom --enable-gpu-rasterization does not solve the problem, atom --disable-gpu does.
I am also using external display.

@xenio
Copy link

@xenio xenio commented May 18, 2017

I can't change the monitor profile, I need my calibrated monitor profile, and both --enable-gpu-rasterization / --disable-gpu doesn't work, my atom window is full of blocks :(

Edit: this is working (I had to restart terminal) but it is sloooowww :(
--disable-gpu

@epogue
Copy link

@epogue epogue commented May 18, 2017

The latest Chromium/Electron changes seem to have fixed the issue in VSCode. Here's hoping those same changes make it into Atom soon! 😄

For what it's worth, --enable-gpu-rasterization half-fixes the problem for me, but I still see some discoloration in inactive areas and during rendering. --disable-gpu seems to work, but I'm concerned that would cause a performance hit. Certain display color profiles also work, but then my screen looks like 💩.

@tlmurphy
Copy link

@tlmurphy tlmurphy commented May 18, 2017

I'm using two ASUS VH242H external monitors and changing the display profile worked for me.

@50Wliu
Copy link
Member

@50Wliu 50Wliu commented May 18, 2017

We are working to upgrade to an Electron version that fixes this issue - see #12696. It's taking a long time because we want to leverage new features that will improve overall editor performance as well as fix as many regressions as we can find before finishing the upgrade.

@50Wliu
Copy link
Member

@50Wliu 50Wliu commented May 20, 2017

#12696 has been merged; master is now on Electron 1.6.9/Chrome 56 which fixes this issue. Atom 1.19.0 should contain the updated Electron version when it is released.

@50Wliu 50Wliu closed this May 20, 2017
@50Wliu 50Wliu mentioned this issue May 20, 2017
@MikeShi42
Copy link

@MikeShi42 MikeShi42 commented May 22, 2017

fwiw I've been able to work around this by using rgba with a non-one alpha value to get around the tiling issue. Not sure why it works.

ex.

atom-text-editor {
  background-color: rgba(36, 39, 46, 0.99);
}
@jonathonw
Copy link

@jonathonw jonathonw commented May 22, 2017

I don't understand why, but I appear to also be able to work around this by forcing tab bar close icons to always be visible:

li.tab div.close-icon {
    transform: scale(1.0) !important;
}

Unlike the above, this doesn't leave artifacts in the text view gutter or in the tree view, and respects the editor background color set by the theme.

[edit] This worked to fix the issue on my MacBook Pro's (retina) internal monitor (while it was the only display connected), but doesn't appear to have any effect on my (non-retina) external monitor. Strange.

@olehermanse
Copy link

@olehermanse olehermanse commented May 30, 2017

@xenio :

@diedummydie Is there a way to have the alias with --enable-gpu-rasterization and also have parameter passed to Atom via command line?
I like to open file from terminal but also have --enable-gpu-rasterization
ie:
atom ~/.bash_profile
this isn't working if I have the alias with gpu enabled :(

I found out that for some reason the option --enable-gpu-rasterization has to come after the file path.

This doesn't work:

atom --enable-gpu-rasterization ~/some_project 

This works:

atom ~/some_project --enable-gpu-rasterization

So a bash function that works for one argument is:

function atom-gpu {
    atom $1 --enable-gpu-rasterization ;
}

(Have to call it something else so it doesn't call itself recursively)

This might be a bug (?) as atom --help clearly states:

Usage: atom [options] [path ...]

( Of course you could also use the color profile fix that is mentioned above).

@frankny
Copy link

@frankny frankny commented Jun 6, 2017

As reco'd by previous posters,

I test out all three of these:

atom --enable-gpu-rasterization
atom --force-gpu-rasterization
atom --disable-gpu

The only one that seems to have completely cleared the problem is disable-gpu. The other two dont get rid of the shading below the text. Image attached for reference.

screen shot 2017-06-05 at 9 34 02 pm

@psabeckis
Copy link

@psabeckis psabeckis commented Jun 8, 2017

Hello,

Until Atom hits 1.19 I solved this issue by applying opacity on the body tag in the styles.less. Didn't notice any incompatibilities and works great.

Code:
body { opacity: 0.99 }

@carlca
Copy link

@carlca carlca commented Jun 13, 2017

Thank you @psabeckis. Your solution works a treat! It wasn't a serious problem because Atom still worked ok, but it annoyed me nonetheless. I'm happy now!

@Smexhy
Copy link

@Smexhy Smexhy commented Jun 19, 2017

Hoping for a fix soon!

@schrej
Copy link

@schrej schrej commented Jun 20, 2017

@Smexhy closed issue == issue fixed already
It's just not released yet, you'll have to wait for Atom 1.19 as written above multiple times.

@Smexhy
Copy link

@Smexhy Smexhy commented Jun 20, 2017

@schrej oh, allright, sorry.

@rsese rsese marked this as a duplicate of #15083 Jul 25, 2017
@rsese rsese mentioned this issue Jul 25, 2017
1 of 1 task complete
@lock
Copy link

@lock lock bot commented Apr 1, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked and limited conversation to collaborators Apr 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.