Use a 'virtual backbuffer' in specific circumstances

[slime73]

Original report by Alex Szpakowski (Bitbucket: slime73, GitHub: slime73).

---

There are some cases where the system-provided OpenGL backbuffer isn't quite enough for what LÖVE does:

• On Android, OpenGL ES 3 contexts support sRGB framebuffers and textures, but the OS doesn't provide a way to treat the backbuffer as sRGB when rendering to it.

• On Windows, the Microsoft APIs for enabling high-dpi support for the backbuffer are very limited: high-dpi mode cannot be disabled once it's enabled, and it's global per-process.

• It might be nice to provide support for multiple 'resolutions' when desktop-fullscreen mode is used.

All 3 of those cases could be solved by rendering to an OpenGL framebuffer instead of the system backbuffer, and then using glBlitFramebuffer to blit the framebuffer's contents to the real backbuffer.

Adding code for that would probably make the interactions between love.window (and love.event) and love.graphics a bit more messy, unfortunately. glBlitFramebuffer is also not guaranteed to be supported by the systems LÖVE is capable of running on (which is important for points 2 and 3), and the extra blit would add some pixel-processing overhead for GPUs.

[slime73]

love 12 does this when MSAA is used now. We changed our high dpi API to be more Windows-friendly, and newer Android devices expose native sRGB backbuffer support so I think that covers the important cases. I'm not overly excited about adding love code to support fake desktop-fullscreen resolutions since that can be done in user code, so this is all done IMO.