Stylesheet performance with the color macro and contrastcolour macro : should I use macro text subtitution, wikify or filter transclusion?

Hi everyone ! I was trying to use the contrastcolour macro in a stylesheet and I noticed that using the color macro shorthand as input was not working :

<$macrocall $name="contrastcolour" 

target=<<colour foreground>>
colourA=<<colour foreground>>
colourB=<<colour background>>
/>

This is because of the format of the input, the color macro output a transclusion instead of a color value :

<$transclude tiddler={{$:/palette}} index="foreground"><$transclude tiddler="$:/palettes/Vanilla" index="foreground"><$transclude tiddler="$:/config/DefaultColourMappings/foreground"/></$transclude></$transclude>

I ended up using a filter :

<$let
color="[{$:/palette}getindex<currentTiddler>]~[{$:/palettes/Vanilla}getindex<currentTiddler>]~[[$:/config/DefaultColourMappings/]addsuffix<currentTiddler>get[text]]~[<currentTiddler>]"
>

<$macrocall $name="contrastcolour" 

target={{{ [[foreground]reduce<color>] }}}
colourA={{{ [[foreground]reduce<color>] }}}
colourB={{{ [[background]reduce<color>] }}}
/>

</$let>

I see that the core use a wikify widget to get around this issue (here) or macro text substitution (there).

Since text substitution and the wikify widget are not great for performances, is it better to use a filter or should I use one of those two solutions ? Which one would you recommend and why ?

Thanks a lot for your help.


Note : I’m tagging this post with “developers” because this seems like a very technical aspect of tiddlywiki, but let me know if this is not appropriate and I’ll change it, or feel free to edit my post.

1 Like

Filter results are cached since some time, so they should be relatively performant. … There is also a new PR on the way that should improve filter performance even more. See: https://github.com/Jermolene/TiddlyWiki5/pull/6402#issuecomment-1031671165 … So you may give it a +1 :wink:

1 Like

Parse trees for macro definitions that don’t use $x$ or $(x)$ can also be cached since v5.1.23 … So only the wikify widget should be used carefully.

2 Likes

There are 2 rules for filters in TW:

  1. Reduce the number of possible results as soon as possible
  2. A working filter is better then a probably fast one which is broken :wink:

add 1)
Filters are evaluated from left to right. So “soon” means “at the start” of the filter string.

Most operators by default start with [all[tiddlers]...] even if that’s not needed to write.

TW does implement some “magic” for convenience reasons. Eg: [tag[HelloThere]] is interpreted as [all[tiddlers]tag[HelloThere]]

So it’s good to read the docs and experiment with filters a little bit. …

add 2)
There is no need to start with the “most performant” solution all the time. Work needs to get done. right?

So if something is shown by “user request” there is no problem if the result needs half a second to show up. …

If a filter delays user text input by half a second per key-stroke. … That is a problem. … So UI elements that are always shown and long visible lists need some attention.

just some thoughts

Correct. Essentially the idea A CSS stylesheet is one is complexified in TW by macro substitutions.

Regarding performance per se, it doesn’t seem to be too huge an issue (I only did modest tests).

TBH I think we need, as end-users, better insight / guidance into what to do to achieve what looks we want.

Just a comment
TT

Awesome ! I dont think it’s possible to achieve what I want without using variable text substitution so I think I will use the filter approach, thanks !

1 Like

Yes I get that it’s likely not a big deal, but I want my wiki to be as fast as possible and dynamic stylesheets can easily slow things down :slight_smile:

1 Like