Comment 4 for bug 1390890

Regarding point 3) (with the disclaimer that I have no idea about this); shouldn't that be just an implementation detail? I would think that the renderer just sits there until someone throws an object at it and tells it "draw this to the screen". How textures are stored and organized in-memory should be up to the individual renderer to figure out. Or would it require changes in the way textures are stored on disk? (Sounds like there might be an abstraction layer which isn't totally clear here, but fixing that might require a refactoring which might be too late/not worth it given the title of this report).

Point 5) I think the main reason for keeping the software renderer around was as a fallback in case the user didn't have graphics card/driver capable of using openGL. If support for openGL 2.1 is indeed widespread enough that this is no longer an issue, I agree that much of the basis for keeping it around disappears.

Btw, what's the current state of driver support for OpenGL on Microsoft Windows like? I got the impression it was a bit lacking some years back, since most Windows-software used DirectX anyways. I haven't followed this closely, though with the move to more cross-platform development (OS X, Steam porting, etc) the situation seem to have improved a lot. Though the main question would be whether it works for people running older hardware/operating systems and drivers.

I think the rest of the points are valid.