GLRenderer unexpectedly generates mipmaps of the previous framebuffer #1788
Description
When a new framebuffer is set as current, the renderer will try to generate mipmaps for the attachments of the previous framebuffer if they are set to use mipmaps. This is an hack made probably for Filters but it is unexpected (setting a framebuffer shouldn't create mipmaps of another framebuffer...) and breaks when the previous framebuffer is used to render on a mipmap level, since this code will replace the rendered mipmap with one autogenerated from the first level.
I am not sure on how to fix this without breaking current code that relies on this behavior, maybe there should be a flag to tell the renderer if a framebuffer needs automatic mipmaps, but this might lead a developer to think that by setting it, the mipmaps will be generated after the framebuffer is used, while in truth they are generated only after another framebuffer is set in place of the one that needs the mipmaps