You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It could be feasible to keep a single "fully transparent" pixel, that we could compare against in the render methods. It's just an if per draw call, with three comparisons, so the performance impact is probably negligible. The comparison in render methods would avoid (best case scenario) 3 table accesses (caching the pixel contents) and render-time transparency comparison. Worst case scenario, it would avoid 2 comparisons done at render time (3 transparency values, minus the == for the pixel itself). Note that when #11 is resolved, the parent == target check should go next to this pixel comparison.
The text was updated successfully, but these errors were encountered:
It could be feasible to keep a single "fully transparent" pixel, that we could compare against in the render methods. It's just an if per draw call, with three comparisons, so the performance impact is probably negligible. The comparison in render methods would avoid (best case scenario) 3 table accesses (caching the pixel contents) and render-time transparency comparison. Worst case scenario, it would avoid 2 comparisons done at render time (3 transparency values, minus the == for the pixel itself). Note that when #11 is resolved, the
parent == target
check should go next to this pixel comparison.The text was updated successfully, but these errors were encountered: