Feature: don't render very transparent elements

[elsassph]

Context

Often we want an element to be invisible, yet we want its texture to load / remain loaded.

A pattern we use heavily is to make an element (or a tree of elements) to a very low opacity (like 0.001) to work around the activation logic. This ensures all the textures are loaded and remain in memory, so we avoid the texture loading delay when we need to show the element.

The issue with this pattern is that Lightning will effectively paint those invisible elements, which means they impact the rendering performance.

Solution

This PR adjusts the quad collection logic (and the mouse collection logic) to ignore elements at a low opacity.
The value 0.002 was chosen to avoid the usual JS floating bugs if one choses to animate an element to 0.001 alpha.

Alternatives considered

For the use case described, we could imagine introducing an Element flag to indicate that we want the texture to load/remain loaded even when it is invisible.

• This would in fact represent a lot of extra complexity and changes in sensitive code paths,
• It would be a burden for users, which would have to annotate every element in a sub tree which should be loaded.

To overcome the user-burden we might imagine that the flag could be inherited, but this would mean even more complexity and risks to introduce regressions.

[wouterlucas]

Quick and dirty for sure - I like it.

Though should we add this to the docs somewhere? Might make sense to at least refer to it somewhere so we can point to it if someone runs into an issue with this. As it ties rendering availability directly to the alpha property.

[michielvandergeest]

Nice idea indeed. If we can just add a note somewhere in the docs I think it's good to go.

Wondering if this is something we could use in the L3 renderer as well?

👆 @jfboeve for awareness - let's discuss this next time we're at the office!

[elsassph]

I guess it can be called a "rendering optimisation". Let's see where it could be noted in the doc.

[michielvandergeest]

@elsassph quick question before merging this in: does this PR also affect the loading of images on elements with a low alpha? Or it does still trigger an image fetch operation on elements with a src attribute and an alpha of 0.0001 ?

[elsassph]

@michielvandergeest elements/images are still considered visible/active at a very low alpha. The optimisation avoids rendering something invisible.

[michielvandergeest]

Ok, so using the "very low alpha to pre-load an image"-trick will still work then

[elsassph]

@michielvandergeest that's the whole point

[michielvandergeest]

yeah, just wanted to double check 😉

[girouxc]

hey @wouterlucas! do you think it would be interesting to add this feature to lightning 3 as well ? 👀

[wouterlucas]

hey @wouterlucas! do you think it would be interesting to add this feature to lightning 3 as well ? 👀

yeah that's something we can consider, though in L3 I'd rather solve this with a proper flag/API then using an low opacity value.

@jfboeve @michielvandergeest lets think about this for the L3 side. Something like a preload flag or "hide" flag to omit it from rendering but process all the other stuff Blits activation + Rendering basics (2D matrix/position/renderability/etc).

[michielvandergeest]

yeah agree - I see I mentioned in a previous comment that we should see if this is something to apply to L3 as well. Just don't think we've gotten around really looking into that.

Blits already has a show attribute, that currently maps directly alpha. We could introduce a show prop on the render as well and map to that, or we can follow the same approach and play with low alphas. That should be easy to wire up in Blits and make the show attribute into 'hidden', but still 'preloadable'

[philippe-wm]

We introduced a concept of "permanent" image, which means they never unload (until they are detached).

One important subtlety though is that the low alpha affects an entire subtree, and if something is visible false or alpha 0 it should still be unloaded.

[wouterlucas]

the L3 renderer already has the ability to mark a texture for prevent cleanup, so they won't be unloaded. Typically used with Font maps and some other core components.

and yeah good point, I think show should include the entire subtree. Alpha obviously does that for free, so we might be introducing something that just adds another check of the same. I just don't like the implicitness of it.