And, unrelated, does PIXI uses off-screen rendering pass(es) for masks?
i.e. if a sprite has a mask on it, it needs to render its entire tree off-screen and not directly in the frame buffer, right? Then apply the mask, and only then render that entire output to the framebuffer?
And that's the case for each mask (for example if in that sprite, a descendant sprite has a mask, it does ANOTHER off-screen rendering pass to render it and all its children?
Masking doesn't require rendering the scene offscreen and then applying the mask.
For a WebGL Graphics mask, we use the stencil buffer to draw the mask then apply it using a color mask stencil operation, it interrupts the batch but doesn't require us to render the entire scene offscreen or anything
For Canvas Graphics we use clip, just draw the path and clip it
For Sprite (alpha) masks we use a custom shader that is applied as a filter, so again it interrupts the batch. Sprite (alpha) masking isn't available on Canvas
@englercj Can you perhaps answer my Rectangle question? I wonder about, one is why you "flatten" the Rectangle by having 4 floats instead of a "Point" object and a "Size" object to represent a Rectangle for example, and the second is why these stuff (Point, Rect, value-types...) is not immutable?
Sorry if this is unrelated.
I'm just going over some of the code and I was interested on some of the principles and design choices
Yes. But in cases like setters, you don't want it to behave like that. It can introduce very weird bugs. So you either flatten out the data structure (i.e. save x/y floats on your object instead of Point), or you copy the Point you get.
and only in very rare cases do i ever find a need to copy one to prevent that scenario
like with my current pixi project - i have a bunch of graphics and sprite objects. I update a lot of the internal data they store when i modify them so i can create my modifiable terrain. i'd have to do a ton of new object creation/swapping to achieve that
as it is now, i simply store a reference to the possible options - and when i update a tile to a different type, just pass it the new reference it should use for collision checks and rendering
i do understand the bugs it can cause, and the complications that arise.. i just don't think it should be up to the library developers to "protect" any other developer who uses their library away from that
gotta run for supper - but i think it's a topic where agreeing to disagree is likely going to need to happen, lol. i don't work on public projects very much.. so my experiences are limited to those types of problems
possibly, if i worked in public projects more, i'd think differently