avoid using grayscale base when mixing richer colors #2408
Conversation
lib/LaTeXML/Common/Color.pm
Outdated
| # have components discarded. | ||
| if ($base_model eq 'gray') { | ||
| my $enriched_base = $self->convert($mix_model); | ||
| return $enriched_base->mix($color, $fraction); |
There was a problem hiding this comment.
Interesting; looks like you've likely got the right idea. I'm wondering out-loud whether it might be slightly less convoluted than a return from the middle to start with my $base = $self; and then if gray, do $base = $self->convert($mix_model);, and do the last few lines with $base instead of $self ? That would seem to make more transparent that you're really just re-expressing self in a different color model.
There was a problem hiding this comment.
Good point, the extra recursion is just needless performance tax here. Now adjusted.
lib/LaTeXML/Common/Color.pm
Outdated
| my @a = $self->components; | ||
| my @b = $color->components; | ||
| my @b = $other->components; | ||
| return $self->new(map { $a[$_] + $b[$_] } 0 .. $#a); } |
There was a problem hiding this comment.
shouldn't the last 2 $self be $base? (like for mix)
There was a problem hiding this comment.
Duh. How did that slip happen? One quote I overheard this morning:
"If it isn't tested, it is broken."
There was a problem hiding this comment.
Thank you for catching that and avoiding a very annoying encounter+report+debug cascade later on. Fixed.
dginev
force-pushed
the
avoid-grayscale-base-in-color-mix
branch
from
1939322
to
64349cc
Compare
* avoid using grayscale base when mixing richer colors * avoid needless recursion in color mixing/adding
Fixes #2407
The problem was that when a base model is grayscale, a
mixoperation withrgbwould remain in the base model - i.e. remain in grayscale. So whenmixoraddexecutes, the "richer" color model ought to be used.Suggestions welcome if my code should be structured better, I almost made a new
subto hold the model-switching logic. Are there more places that could benefit from this treatment?