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
{{ message }}
Repository navigation
[DisplayList] DisplayListBuilder does not track singular matrices as a "NOP" state #178506
Currently the DisplayListBuilder will note that the state is in a "NOP" condition if the clip is reduced to empty. It does not track the same condition if the matrix becomes singular. Rendering operations with a singular matrix will not draw anything.
Not to be contrarian, but, does it matter? How much of an overhead is this really.
That is a good question. Noting and short-circuiting NOP situations has usually been a feature of graphics libraries, but we've never really measured the potential practical impact of various NOP conditions.
I am pretty sure that clipping content out is very common because we specifically have things like scrolling lists that construct widgets before they are inside the rendering area. Thus, we know that we can just ignore recording those items on a given frame until they intersect the clip, but we haven't measured the actual time savings of how early we detect that. Clearly the framework doesn't nip that in the bud so we aren't preventing it at the earliest point in the chain, but it does get omitted in the DisplayList.
NOP transforms? That would require some measurement to know if it matters. If someone wrote a transition that scaled the old view down to 0 scale, then left it in the widget hierarchy for a few frames, it would just be a waste of DL space during that time, but I don't actually know of any app or standard package transition that does that (I haven't really looked, though).
Similar questions arise about the importance of detecting attribute NOPs (things like blend mode kDst). Again, when would that be used? Another unanswered question.
On the other hand, these things are really easy to check. A NOP scale can be detected with just a couple of checks in one of the more common transform methods (scale(0?, 0?)). Noting that kDst blend mod NOPs everything is a really quick check in the setBlendMode method.
Activity
chinmaygarde commentedon Nov 17, 2025
Not to be contrarian, but, does it matter? How much of an overhead is this really.
flar commentedon Nov 17, 2025
That is a good question. Noting and short-circuiting NOP situations has usually been a feature of graphics libraries, but we've never really measured the potential practical impact of various NOP conditions.
I am pretty sure that clipping content out is very common because we specifically have things like scrolling lists that construct widgets before they are inside the rendering area. Thus, we know that we can just ignore recording those items on a given frame until they intersect the clip, but we haven't measured the actual time savings of how early we detect that. Clearly the framework doesn't nip that in the bud so we aren't preventing it at the earliest point in the chain, but it does get omitted in the DisplayList.
NOP transforms? That would require some measurement to know if it matters. If someone wrote a transition that scaled the old view down to 0 scale, then left it in the widget hierarchy for a few frames, it would just be a waste of DL space during that time, but I don't actually know of any app or standard package transition that does that (I haven't really looked, though).
Similar questions arise about the importance of detecting attribute NOPs (things like blend mode kDst). Again, when would that be used? Another unanswered question.
On the other hand, these things are really easy to check. A NOP scale can be detected with just a couple of checks in one of the more common transform methods (scale(0?, 0?)). Noting that kDst blend mod NOPs everything is a really quick check in the setBlendMode method.