Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

Showing line numbers disables sub-pixel AA on tabs, status-bar etc. #7904

Closed
simurai opened this issue Jul 15, 2015 · 6 comments · Fixed by #7957
Closed

Showing line numbers disables sub-pixel AA on tabs, status-bar etc. #7904

simurai opened this issue Jul 15, 2015 · 6 comments · Fixed by #7957

Comments

@simurai
Copy link
Contributor

simurai commented Jul 15, 2015

In atom/one-dark-ui#82, @Wiox noticed that sub-pixel anti aliasing is not only disabled for the tabs, but also on the fuzzy finder and the status bar.

sub-pixel

It seems it's caused by the line number tiles getting promoted to a GPU layer and probably related to #7101. Kinda strange that it affects different areas.

Something that might be worth looking into is using will-change. It also adds a GPU layer for the line numbers, but doesn't affect the rest. Notice the orange "composited layer borders" only appear in the status bar with -webkit-transform: translate3d(0px, 0px, 0px); but not with will-change: transform;.

tiles

Now, I heard that will-change should only be used when interacting, like on hover or so.. and not kept permanently enabled. So not sure if that would help. /cc @as-cii @nathansobo

Edit: Sorry, I just realized that the transform is needed to actually move line numbers. So can't be replaced. 😁

@as-cii
Copy link
Contributor

as-cii commented Jul 15, 2015

Hey @simurai, thanks for the thorough report and explanations.

I traveled back in time to 7e9e8e0 (namely, the commit before merging #7101) and I found out subpixel anti-aliasing was still not working as of that version and therefore I think we can exclude tiling as the cause of this issue.

Apparently the layer is being created because of two reasons:

screen shot 2015-07-15 at 15 44 15
screen shot 2015-07-15 at 15 43 55

I think the elements that “may overlap” are the tiles’ layers (or the whole line-numbers’s layer before #7101), but I am not sure what exactly should be squashed and why. Setting overflow: hidden or reducing the height of line-numbers doesn’t seem to improve the situation.

@simurai: would it be possible to simply give the status bar div a background color? That could enable us to get subpixel anti-aliasing back and hopefully stop worrying about the underlying layers creation. Nevertheless, I’d agree it may be interesting to understand why Chrome is automatically generating those layers.

@simurai
Copy link
Contributor Author

simurai commented Jul 15, 2015

would it be possible to simply give the status bar div a background color?

Yeah, that might work.

Or I randomly tried some stuff and adding z-index: 0; to the gutter seems to fix it.

atom-text-editor::shadow .gutter {
  z-index: 0;
}

tiles

@as-cii
Copy link
Contributor

as-cii commented Jul 15, 2015

I randomly tried some stuff and adding z-index: 0; to the gutter seems to fix it.

I think we can use it then, but let’s make sure to document it so that it’s 100% clear why we’re setting it. Not sure if we should still set the background-color property: on one hand it seems like it could let us forget about this layering problems in the future, but on the other hand it feels like a workaround that shouldn’t be needed at all (given that we don’t want the status-bar to have its own layer).

@simurai: thoughts? 💭 If setting the background-color property is super straightforward I would probably add it as well.

@batjko
Copy link
Contributor

batjko commented Jul 15, 2015

Sorry to bud in, but would the explicit setting of the background color potentially interfere with future changes to the status-bar?

I'm thinking of open requests like extending the status-bar to the whole workspace, rather than just within editors and who knows what people want to do with it.

@simurai
Copy link
Contributor Author

simurai commented Jul 15, 2015

Ok, adding background-color to the status bar seems to work, but only when also creating a layer at the same time:

.status-bar {
  background-color: #333;
  transform: translateZ(0);
}

Future changes should still be ok, but not sure if that's bad for performance because on every key stroke it has to repaint the line/column count and push another layer? Also, the same would need to be done for the tabs and maybe other places.

Doing the z-index: 0; seems cleaner, no? It's strange, because the gutter already has an overflow: hidden, so there shouldn't be any overlapping. But somehow Chrome is extra cautious. And just by creating another stacking context Chrome feels save?

Anyways.. It's not super urgent and we can first test some more.

simurai added a commit that referenced this issue Jul 18, 2015
Problem: The GPU layer added to the .gutter .tiles cause the surounding UI to also composite layers, like the tas or the status-bar. This disables subpixel anti-aliasing and text doesn't look that sharp.

Eventough the `.gutter` has `overflow: hidden`, it seems Chrome still thinks there is a chance of overlapping and thus creates the extra layers.

Solution: Creating an own stacking context for the `.gutter` seems to fix it.

Issue #7904
@lock
Copy link

lock bot commented Jan 21, 2019

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 as resolved and limited conversation to collaborators Jan 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants