multiple textures

[justingardner]

A few issues here.

1) There is an option to mglBlt multiple textures with a call (by passing in an array and arrays of parameters) - is this implemented yet? 2) When generating a lot of textures it seems like, maybe, something is going wrong - I say this because the mglTestText test function generates a number of textures, but the display doesn't seem to work properly. 3) Tangentially related - is mglDeleteTexture actually implemented? (as freeing memory could improve performance). Also, what happens in the case where you mglBlt the texture and then immediately delete it? This happens in mglTextDraw - but could also happen in people's call - we should have a way to cue the delete until after the Blt has run perhaps?

[justingardner]

mglTestText is the one that has a problem...

[benjamin-heasly]

1. let's start with a matlab for-loop to make the API compatible, then revisit if we find we need faster execution
2. see mglTestText
3. mglDeleteTexture is implemented, yes

[benjamin-heasly]

Commit 3b377ac26e28b26191f37411d11582afece37a1b should resolve part of this.

mglMetal now allows texture create and delete any time, inside or outside of its tight draw loop. This is tested in mglTestTextDraw.

For performance situations, we should consider using mglUpdateTexture instead.

[benjamin-heasly]

A note on mglDeleteTexture and memory management by mglMetal --

We had a concern that the create-blt-delete pattern would cause a race condition where a texture might get freed before actually being blt-ed to the screen.

I think this won't be a problem, however, because in the Cocoa / Swift environment deletes are implicit and based on reference-counting. We are free to release our own reference to the texture when we call our own "delete" code, and the current render pass will still hold the texture reference until the render pass itself is completed and deleted.

I put this to the test in mglTestTextDraw, and it seems to be working.

I also did a manual test with Activity Monitor to see if the story plays out. I'll outline it here in case we ever revisit this.

• Start up mglMetal and open it in the Activity Monitor.
• Note baseline "real memory" usage is about 45MB.
• Do a bunch of, say 300, mglTextDraw().
• See memory go up to about 75MB.
• Memory stays up, even though mglTextDraw() called "delete" on its textures.
• Call mglFlush().
• Textures appear in the window, and memory drops back to baseline around 45MB.

So this seems good to me, and consistent with the story of reference-counting memory management.

[benjamin-heasly]

With commit 0bd7a059f7a75d92e0fb2916f09c8d97554a0fa4 mglBltTexture supports passing multiple textures and parameters as arrays. For now, this is handled as an m-code loop.

[benjamin-heasly]

These may be resolved now, I'll leave open until we get a chance to re-test.

[justingardner]

Seems good to me. Closing.