Hi @jonahwilliams
Now, per EntityPass will create a LazyGlyphAtlas. (If there are two EntityPass, will create two LazyGlyphAtlas).
If we move it to canvas, multiple EntityPass can reuse this single LazyGlyphAtlas. LMK if I missed something O(∩_∩)O

Oh I see, sorry I misunderstood. yes that will accomplish reuse.

We're going to end up with a few more objects that can be shared across entity pass, the tesselator to start with, and at some point some sort of geometry cache too. Is canvas.cc a reasonable place to put these for now, or should we create a separate class to hold them @chinmaygarde ?

From PR review triage: @jonahwilliams Do you have any thoughts about this PR?

Old comment stands:

We're going to end up with a few more objects that can be shared across entity pass, the tesselator to start with, and at some point some sort of geometry cache too. Is canvas.cc a reasonable place to put these for now, or should we create a separate class to hold them @chinmaygarde ?

Thanks @jonahwilliams. Sounds like this one is waiting for an answer from @chinmaygarde

I think it was setup this way because we expected to use an atlas per pass with the passes being setup concurrently from multiple threads. This will get in the way of that effort but we can rework that when the time comes.

That seems like a reason to hold off on this. I think what I'd like to know is if we have multiple passes (due to a platform view), does each pass collect glyphs for only their own pass - or all passes?

If its the former, we might not want to make this change.

I think what I'd like to know is if we have multiple passes (due to a platform view), does each pass collect glyphs for only their own pass - or all passes?

Sorry for my poor knowledge about that. Emm but why do platform views need to collect glyphs for only in their pass ?

not the platform view, but when there is a platform view in the tree the scene is divided in two. I'm unsure if each part collects glyphs individually or not

Got you. I m also not very sure on that........ @chinmaygarde maybe more know about this? Would you mind sharing your thought on that. O(∩_∩)O

I can do some research into that later this week. Either way, I'd be a bit concerned that the different passes would step on each other if they shared a glyph atlas. The only way to make that work would be to collect the glyphs for all passes up front.

Thinking a bit more about this, I don't think this is the model we want to go with for multiple passes. For one, this will make encoding multiple passes concurrently harder. But I am also not sure how this works when we submit one pass but keep adding to the texture atlas referenced by it for subsequent passes.

Closing this but will keep it referenced in the icebox for when we think about improving atlas management.

I think we should revisit this. its true it may not be the ideal behavior when platform views are involved, but actually today we're doing much worse than we should when there are multiple entity passes because we end up re-creating the glyph atlas N times per frame. this is part of the issue in flutter/flutter#121476

So LGTM to me, if @chinmaygarde is OK with it

@luckysmg if you're able to update the tests I think we can land this.

sgtm