This way, I can use immediate mode, which is way faster than using
buffers for some reason. Since I'm not using profiles anymore, I
dropped the minimum requirement to OpenGL 3.1. If a driver doesn't
support Legacy GL, then it can use the slow buffer code.
But seriously, I need to figure out why using buffers is so slow.
If this was a common problem, Modern OpenGL wouldn't have made it the
only option.
For some reason CPU usage is still double that of the SDLTexture
backend (SDL2 uses OpenGL 2.1, with glEnable/glDisable-style
immediate mode).
If I downgrade to OpenGL 2.1, and use VBO-less glDrawArrays, I get
great performance. I just wish I knew what the AMD driver is doing
that's so much faster.
Turns out performance is absolutely abysmal on my laptop's copy of
Windows 10 (AMD A9 APU).
This is only one of the weird bottleecks: glFramebufferTexture2D
is a CPU sinkhole, so don't call it often.
This fixes this weird thing you'd see in the enhanced branch if the
screen is scaled (happens if you resize the window).
When the screen is scaled, OpenGL uses linear interpolation. This
would cause it to fetch samples from outside the texture. IIRC, by
default, the default behaviour is GL_REPEAT, which causes it to blend
with samples from the other side of the texture, creating strange
pixels at the end of the screen.
