Fixed blur leaking its textures on every resolution change

[dekrom]

Type of change

• Bug fix
• New feature

Description

Blur#createFbo wraps a fresh texture in a view and only keeps the view:

return RenderSystem.getDevice().createTextureView(RenderSystem.getDevice().createTexture(...));

The ResolutionChangedEvent listener closes that view and builds a new one, but closing a view
does not free the texture behind it. GlTextureView#close calls GlTexture#removeViews, which
only destroys when closed is already true, and the only thing that sets closed is
GlTexture#close. Nothing else holds the texture, so the GL name is orphaned with no way to get
it back.

Six mips at roughly 1.33x the framebuffer means about 11 MB of VRAM per event at 1080p and 20 MB
at 1440p. Minecraft#resizeGui fires the event on every step of a window drag, and the listener
is subscribed from the constructor whether or not Blur is enabled, so a couple of seconds of
resizing the window throws away a few hundred MB for every user, Blur on or off.

Grabbing the texture off the view before closing it and closing that too is enough. Order
matters: the view has to go first so the reference count is already 0 when the texture is
closed, otherwise destroyImmediately does not run.

Related issues

None that I found.

How Has This Been Tested?

Not measured with a VRAM monitor yet. The leak is visible in GlTexture: removeViews() only
destroys when closed is already set, and nothing calls GlTexture#close here. Builds clean
against current master.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.