Does it make sense to remove most/all of the global dynamic theme styles?

[Gitoffthelawn]

The dynamic theme has over a dozen global styles that get applied to every website (when the dynamic theme is being used, of course).

I think it's a safe to approximate that over 99.9% of websites don't need those styles, but they use memory and reduce performance a little on every website in every browser tab.

Does it make sense to remove any/all of them?

[bershanskiy]

If you want to, you can remove most of data within the global dynamic theme, but you should still keep the dynamic theme (with pattern *). It is used internally as the base theme which gets extended with site-specific themes.

[Gitoffthelawn]

Thanks. That's interesting to learn.

Would the first item in the DR dynamic theme devtools then just be the following?

*

================================

[bershanskiy]

If you observe Dark Reader consuming a lot of resources, please file a performance bug.

Would the first item in the DR dynamic theme devtools then just be the following?

No, empty fixes like that are invalid and are automatically removed. Instead, you can specify something that will never be matched, e.g.:

*

CSS
#thisElementDoesNotExist {
    none: none;
}

================================

[Gitoffthelawn]

If you observe Dark Reader consuming a lot of resources, please file a performance bug.

I'm happy to file a performance bug, but I honestly don't think it would be fair of me to do so.

Dark Reader consumes a lot of resources, but it does a lot, so I expect that it will. Similar to something like uBO that consumes a lot of resources, but needs to in order to get its job done.

Can DR be optimized more? Likely, as almost all software can. Is it a bug or worth it? That depends on how much time/effort people want to contribute (and I'm quite grateful for every contribution!).

I'm hesitant to file a bug for something that may be working as expected. (Of course, I always file bugs when it isn't!)

On this topic, I experimented with DR years ago, and I loved it's functionality, but it was just too slow to use regularly. I decided to use Dark Background Light Text instead because it is quite fast & efficient. But the performance of DR has improved so much over the years that I now use it regularly. And I find the quality of DR's Dynamic Mode impossible to beat (except by custom site-specific themes, which I create for many sites).

Would I like DR to be faster? Yes. Would I like it to be more efficient? Yes. Would I consider it a bug that it can be improved? Honestly, not really (am I being too kind?).

I push web browsers to the limit, and often beyond their limits. Although I consider all modern popular browsers to be quite stable in a general sense, I manage to crash the current release of every major browser several times per week. But when this happens, I almost always have the browser's devtools open, Stylus open and writing code for it, Dark Reader running, and several other extensions running. Without scientifically narrowing down all the variables to determine what's causing the crashes, it's anybody's guess. I'm 100% certain something has a memory leak or is not freeing memory as it should, but I can only speculate as to the culprit (and my speculation is that it has to do with Stylus, but that's only a guess based on what I'm most often doing when it happens).

Would the first item in the DR dynamic theme devtools then just be the following?

No, empty fixes like that are invalid and are automatically removed. Instead, you can specify something that will never be matched, e.g.:

*

CSS
#thisElementDoesNotExist {
    none: none;
}

================================

Ah! Thank you! I might file a little issue report that this probably should not be required (or at least documented, if it isn't!), but it might not be a big deal. The big downside I see is that this forces DR to perform extra work on every site, even when there are no site fixes for it.

BTW, little things like this don't make any perceivable difference when you are loading a single site in a single tab in a single web browser on a system that isn't doing much else. But when you have many tabs all refreshing in multiple browsers on a multitasking system, you want every bit of optimization reasonably possible.

[bershanskiy]

I'm happy to file a performance bug, but I honestly don't think it would be fair of me to do so.

Would I like DR to be faster? Yes. Would I like it to be more efficient? Yes. Would I consider it a bug that it can be improved? Honestly, not really (am I being too kind?).

Bug reports are at actionable and therefore preferred. Even if your bug is caused by weird interaction of multiple extensions, please file a bug with as many details as you can and we might be able to fix it.

Ah! Thank you! I might file a little issue report that this probably should not be required (or at least documented, if it isn't!), but it might not be a big deal. The big downside I see is that this forces DR to perform extra work on every site, even when there are no site fixes for it.

This behavior is odd and we might change it in the future. For now, we have unit tests to make sure configs always have a generic fix.

BTW, little things like this don't make any perceivable difference when you are loading a single site in a single tab in a single web browser on a system that isn't doing much else. But when you have many tabs all refreshing in multiple browsers on a multitasking system, you want every bit of optimization reasonably possible.

Dark Reader indeed handles case of many tabs poorly. It currently performs a lot of work all at once right when it switches ON/OFF state or applies new fixes from DevTools. (It sends calculates required fixes and sends a message to every tab, even if the tab is hidden from sight. I plan to fix this problem before the next major release (see #6639).

[Gusted]

The dynamic theme has over a dozen global styles that get applied to every website (when the dynamic theme is being used, of course).

Hm? That seems to be a misunderstanding the styles that are within the devtools are only applied to the matching site. So most of the styles will never get applied to the sites your browsing. @bershanskiy Has made performance improvements into getting the fixes and improve memory so I wouldn't worry as much.

[bershanskiy]

Yes, but that is a very small amount of code, which does not use any "expensive" CSS like background images, gradients or alike. It is very lightweight. In fact. I would be surprised if you could produce a trace demonstrating any observable performance impact of this CSS. There are other things which have much larger impact.

[Gitoffthelawn]

Yes, but that is a very small amount of code, which does not use any "expensive" CSS like background images, gradients or alike. It is very lightweight. In fact. I would be surprised if you could produce a trace demonstrating any observable performance impact of this CSS. There are other things which have much larger impact.

I have one quality reference that I trust on the topic of what makes an individual CSS ruleset expensive or not. Do you have other good references? I'm always interested in increasing my knowledge of that topic. I write a lot of CSS these days, and I like writing the most efficient code possible.

My understanding is that although things like background images and gradients are most certainly expensive when actually applied, the actual declarations within a CSS ruleset do not make any performance difference when they are not applied. It's the selectors themselves that determine whether or not a non-applied ruleset is expensive.

If those global rulesets are needed, and need to be applied globally, then I think they should be included. But if all/some are no longer needed, don't need to be global, or can be handled with a small JS tweak, it would be good to remove all/some of them.

[Gusted]

I have one quality reference that I trust on the topic of what makes an individual CSS ruleset expensive or not. Do you have other good references? I'm always interested in increasing my knowledge of that topic. I write a lot of CSS these days, and I like writing the most efficient code possible.

I've spend a fair bit into Firefox's CSS engine as Chromium's code base is bit too messy for me to understand sometimes. It's a lot of magic happening. But I don't really think there's a good blog or article that explains this.

It's the selectors themselves that determine whether or not a non-applied ruleset is expensive.

Well, and checking if it should apply is done very very easily. For firefox, It first goes trough a counting bloom filter[1]. Which will reject most selectors and only the maybe-positives will get a more expensive check.

1. https://searchfox.org/mozilla-central/source/servo/components/selectors/matching.rs#185

f those global rulesets are needed, and need to be applied globally, then I think they should be included. But if all/some are no longer needed, don't need to be global, or can be handled with a small JS tweak, it would be good to remove all/some of them.

I do tend to remove certain fixes when it's getting a patern and actually patch it up within the code. But creating a CSS fix is by far easier and faster than to create more JS logic and sometimes it just isn't possible.

[Gitoffthelawn]

But I don't really think there's a good blog or article that explains this.

Let's both keep our eyes out and share what we find.

Well, and checking if it should apply is done very very easily. For firefox, It first goes trough a counting bloom filter[1]. Which will reject most selectors and only the maybe-positives will get a more expensive check.

1. https://searchfox.org/mozilla-central/source/servo/components/selectors/matching.rs#185

Thank you for those links.

f those global rulesets are needed, and need to be applied globally, then I think they should be included. But if all/some are no longer needed, don't need to be global, or can be handled with a small JS tweak, it would be good to remove all/some of them.

I do tend to remove certain fixes when it's getting a patern and actually patch it up within the code. But creating a CSS fix is by far easier and faster than to create more JS logic and sometimes it just isn't possible.

Ya, I agree that more JS logic should be a last resort. I think finding out when the global rules were added and why will be beneficial? Do you happen to know? If not, I can find the pull and see if there's a matching issue report.

[Gusted]

I think finding out when the global rules were added and why will be beneficial?

Adding global patches rarely happens and only happens with good reasons, you can find the PR's for it with the blame tool.

Do you happen to know? If not, I can find the pull and see if there's a matching issue report.

If a certain issue happens on multiple sites, better said when it a issue is happening by a certain engine like MediaWiki, gerrit. Things that every site can use. Such fixes will then be applied to the global fixes as just addding upon adding the sites to the list is inefficient and certain websites will in the future need other fixes and add more "bloat" to the whole config.