Are we just "forgiving" transparent base colors if a solid follows?

NoSloppy · August 15, 2025, 8:55pm

and only if there’s only 2 arguments ?

profezzorn/ProffieOS/blob/e0868ab82d2f96df9d942d9e2a59b7e09a897151/styles/layers.h#L79


      
            OverDriveColor dealpha(const RGBA& color) { return OverDriveColor(color.c, color.overdrive); }
          public:
            auto getColor(int led) -> decltype(dealpha(layer_.getColor(led))) {
              return dealpha(layer_.getColor(led));
            }
          };
          
          
          template<class BASE, class ... LAYERS> struct LayerSelector {};
          template<class BASE> struct LayerSelector<BASE> { typedef BASE type; };
          template<class BASE, class L1> struct LayerSelector<AlphaL<BASE, Int<0>>, L1> { typedef L1 type; };
          template<class BASE, class L1> struct LayerSelector<BASE, L1> { typedef Compose<BASE, L1> type; };
          template<class BASE, class L1, class ... REST> struct LayerSelector<BASE, L1, REST...> {
            typedef typename LayerSelector<Compose<BASE, L1>, REST...>::type type;
          };
          
          template<class BASE, class... LAYERS> using Layers = typename LayerSelector<BASE, LAYERS...>::type;
          
          #endif

This allows a style like this to compile:
StylePtr<Layers<AlphaL<Blue,Int<16384>>, Red>>() and we just discard the first color and show the solid color.
But this will error at compile time:
StylePtr<Layers<AlphaL<Blue,Int<16384>>, Red, AlphaL<Green,Int<16384>>>>()

I was looking at making some static assert error messages for the cryptic RGBA_um_nod& / DISAMBIGUATE_OVER errors, so I’m wondering if this should instead be:

template<class BASE, class L1> struct LayerSelector<AlphaL<BASE, Int<0>>, L1> { typedef Compose<AlphaL<BASE, Int<0>>, L1> type; };

and force the error instead of “letting it go”?

profezzorn · August 15, 2025, 9:37pm

Let me try to straighten a few things out:

Layers<> has nothing against transparent base layers. It allows it just fine. However, the result is transparent, which is not allowed for StylePtr<>
The line you point at only matches if the base layer is 100% transparent, it should not match the examples you provide, since they have Int<16384> instead of Int<0>.
LayerSelector gets recursively broken down, so if you have layers A, B, C, it becomes LayerSelector<LayerSelector<A, B>, C>, so it eventually always runs on pairs of layers.
Assuming I did it correctly, the line you point at is an optimization and should have no impact on what is allowed and what isn’t. (It does have an impact of which run() functions are executed though, which might not be expected.)

Have you actually tried your examples, or you just assuming that they will work or throw errors?

NoSloppy · August 15, 2025, 11:04pm

Yeah I tested with Int<0> and changed it for this post for whatever reason, and that was my undoing.
Duh it says right there in the template Int<0>.
So bottom line is since AlphaL<Blue,Int<0>> is nothing anyway, it can be discarded if it’s the first color. Other transparencies a solid are considered.
All good.
PR incoming.