Support more context and framebuffer options

[einarf]

Some missing (imporant options). Trying to be conservative here. The are ordered by importance:

• depth_bits to specify resolution for depth buffer. The default 16 bits is often not enough.
• samples specifying the number of MSAA samples for the default framebuffer
• gl_version to specify a a minimum gl version the user expects.
• Maybe also a core and forward_compatible parameter. At least core is probably needed.
• Possibly a way to control vsync, but tkinter might be in control of that? (Not researched)

It can just be parameters to baseOpenGLFrame.

[jonwright]

I guess we need to setting up the full attribute lists depending on the gl version in use. Probably these need to be set up inside init instead of being common to the whole class.

Then create the Frame with the right pixel format. Frame has a visual argument already (http://effbot.org/tkinterbook/frame.htm) and I assume the "visual=" argument on Frame creation ought to reach Tk near here for getting the window right:
http://www.tcl.tk/man/tcl8.6/TkLib/GetVisual.htm
http://www.tcl.tk/man/tcl8.6/TkLib/SetVisual.htm
e.g. visual = "class name followed by an integer depth"

As I remember, windows remote desktop had a very old opengl and so it was not easy to always do the right thing by default...

[einarf]

Sounds like a plan. Keeping the current values as default is probably a good idea for backwards compatibility. I think it can be split into two sets to make it simple. GL 3.3+ core (programmable pipeline) or fixed pipeline (anything lower than 3.3). That way we don't break GL 1.x context provided over things like remote desktop or on computers only supporting cpu emulation.

That's basically how it works for OS X as well because they have separate drivers for fixed and core. You cannot do fixed pipeline calls with the core driver. (Requires gl_version=(3, 3), core and forward_compat flag set in the context)

With multisampling it's a bit more complicated because you have to query the supported pixel formats. Pyglet is a great reference for that. Only supporting that for 3.3+ context might be safer and simpler as a start.