- Specifically request GL version when creating context. Just specifying core
profile bit results in the requested version defaulting to 1.0 which causes
the core profile bit to be ignored and an arbitrary compatability context to be
returned.
- Fix GL painting by removing GL calls that have been depricated by the 3.2 core
profile.
- Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
core.
https://bugzilla.gnome.org/show_bug.cgi?id=742953
This drops the maybe_allocate_buffers that re-allocates buffers
at any point. Instead we just set have_buffers to FALSE and have
the buffers re-created when needed.
This also makes the buffer creation code imdeponent and makes it
clean up no longer needed buffers in order to handle being called
multiple times due to the above.
We also ensure we re-allocate the buffers when we're resizing
and the buffers are already created.
This restructures the way buffers are allocated and bound in a way
that is more flexible.
Buffer operation happens in three phases:
create_buffer() - Creates the gl objects
allocate_buffers() - Allocates space for the buffers at a given size
attach_buffers() - Attaches the buffers to the framebuffer and makes
the framebuffer the default drawing target
And destroy via
delete_buffers()
We call all these the first draw, and after that we allocate buffers
each time the widget changes size until the buffers are deleted.
We delete the buffers at unrealize.
However, anyone that wants to manually control buffer allocation strategies
can manually call allocate/delete_buffers().
There are also some other changes:
* Support for stencil buffers.
* A manual render mode where ::draw doesn't render unless you manually
invalidated the previous rendering.
We had some code that tried to reuse the context over realize, but
that doesn't work as we need to share with the possibly new
paint context of the re-realized window.
Its not really reasonable to handle failures to make_current, it
basically only happens if you pass invalid arguments to it, and
thats not something we trap on similar things on the X drawing side.
If GL is not supported that should be handled by the context creation
failing, and anything going wrong after that is essentially a critical
(or an async X error).
