gpui: Add drop_image

[143mailliw]

This PR adds a function, WindowContext::drop_image, to manually remove a RenderImage from the sprite atlas. In addition, PlatformAtlas::remove was added to support this behavior. Previously, there was no way to request a RenderImage to be removed from the sprite atlas, and since they are not removed automatically the sprite would remain in video memory once added until the window was closed. This PR allows a developer to request the image be dropped from memory manually, however it does not add automatic removal.

Release Notes:

• N/A

[143mailliw]

It's worth noting that this can be kind of painful depending on use case, since on_release does not provide the WindowContext (for good reason, I suspect, unfortunately), and thus you cannot simply drop the image when the View is released.

[143mailliw]

I actually don't think it's possible to remove sprites from the atlas with the current structure of this code. This approach doesn't work, since the IDs change, and I can't think of one that would allow for this to work without substantially rewriting the atlas implementations.

[143mailliw]

I've rewritten parts of BladeAtlas and MetalAtlas to allow for pages to be deleted from the atlas.

I thought of two different solutions to this problem, and they both implement different ones. BladeAtlas uses FxHashMap instead of a Vec to index the pages, and MetalAtlas uses Vec<Option> instead of Vec. Both allow for pages to be removed without affecting other indexes.

The way I see it, the HashMap option (seen in BladeAtlas) has cleaner code but IDs can never be reused and performance is worse since the pages are now unordered. The Vec of Options maintains the page order, and IDs can be reused, but adds a fair bit of boilerplate code. I'm looking for feedback on this.

The other change that was made was counting allocations. Allocating space in a page now increments a counter, and removing the associated sprite decrements the counter. Note that removing the sprite does not deallocate it in the sprite map since BucketedAtlasAllocator does not allow for reuse of allocated space unless all items in the texture are deallocated, but since the texture is deleted when all items in the texture are dropped, there is no point deallocating each sprite.

The result of this is that the function cx.drop_image now works properly without affecting any other sprites.

[143mailliw]

I decided to use a Vec<Option<T>>. I considered using a SlotMap (from slotmap), but it didn't seem fit for purpose.

The PR should be good to merge now, as far as functionality goes. I don't get any warnings on it, either.

[143mailliw]

I have some concerns about not reusing atlas pages. I agree it's slower to reuse them, but not reusing them limits the amount of images that can ever be loaded.

I could see this being a problem for something like gpui-gradient, which creates an image every frame.

[mikayla-maki]

@143mailliw I don't see us having any limits on the length of the textures array, but I thought it would probably be good practice to keep those arrays dense anyway. This latest commit should be ready to go, could you test it out in your application and make sure it's still working well?

[143mailliw]

@mikayla-maki LGTM, tested and works as expected.