The title of disabled items is also greyscale:

If you know the background color precisely you can compute the opacity by blending colors together and thus avoid opacity which is likely causing the issue in this case.

Example:

I am using opacity in both the cases

@bpasero Do you suggest to use above computation instead of setting css opacity ? If so can you help me in understanding which colours to use for bending.

Yes I think #86192 (comment) is still a good solution, but you might need to be aware of wether your view is inside sidebar or panel now.

I am sorry if my question does not make sense - these are rendered inside the list widget and are you saying that every time I have to use opacity I have to do this computation?

I am assuming the list / tree widget takes care of this grey scale rendering and the elements inside it does not need to, is not it @joaomoreno ?

As far as I remember, any element with opacity will not be rendered with LCD anti-aliasing, thus if you know precisely what background color you are on top of, you can compute it manually to avoid this penalty from Chrome renderer.

Hm, I think disregard what I said, I can actually not reproduce the original issue when I tried just now on Windows:

So this still reproduces for me on Linux: only the publisher name is not using LCD rendering, though other lists that have text with opacity do not suffer from this issue as far as I can tell. So my suggestion for avoiding opacity might not be the correct solution after all.

I am assuming the list / tree widget takes care of this grey scale rendering and the elements inside it does not need to, is not it @joaomoreno ?

Not sure I understood the question. The tree/list doesn't prevent you from having subpixel AA. But it also doesn't guarantee it for its users, since there are things done on row content, eg opacity, which could prevent it.

Used the trick @bpasero suggested and it worked

Here are the layers rendered (which I got with the help of @joaomoreno)

As from @joaomoreno
It seems there are no new layers around publisher field it could be another bug altogether then and could even potentially be an electron issue

@bpasero @deepak1556 any idea if this is an electron issue and if not shall we have to follow this blending trick at all such places?

@sandy081 we have had a lot of discussion with the Chrome team in the past and I think Alex made a good list of conditions under which Chrome may decide to switch to greyscale rendering (https://bugs.chromium.org/p/chromium/issues/detail?id=1016062#c31). I doubt it is Electron to blame, rather Chrome, but then again unlikely to get a fix imho.

As for opacity in our code: this is not a guarantee for loosing LCD rendering. A lot of places use opacity and render just fine. However, in some specific cases we seem to be loosing LCD rendering and you can find all issues we filed via this query: lcd-text-rendering

As you can see, some of these issues are still open or closed "as designed", simply because the technical solution was not straight forward.

tl;dr;: we try our best to get LCD rendering, but by no means are we thinking that we get to 100%. Just to give an example: notification toasts do not render with LCD rendering because of many factors, such as animations, border shadow, etc. I did not have the energy to make it work there.

Ah, and btw other browsers are fine, Firefox always renders in LCD, no matter what. And this is even platform specific, e.g. I was not able to see this issue on Windows, only Linux.

@bpasero @sandy081 is there an easy way to verify this issue? It seems there's a lot going on here

This can be verified only on Linux.

• Open extensions view and zoom in and make sure publisher's name is not rendered with grey scale.

I had a bit of trouble with this until I realized the best way is to take a screenshot and then zoom in, not the other way around. Verified!