On Thu, Sep 4, 2014 at 4:04 PM, Stephen Gutekanst wrote:
The goal is having a great OpenGL interface that just works with the
qml package, no matter the platform. That's not currently available
Yeah, I did gather that much from your blog post. I am sorry though - I did
a poor job communicating my questions clearly:
1. Which OpenGL bindings have you looked at and what were the problems using
2. Have you already seen/looked at Glow and what problems did you experience
using it with QML? Was it literally incompatible with QML for some reason --
or was it mostly API preferences?
QML with them?
I've tried go-gl, for example , and there were symbol resolution
problems due to how GL defines the API but not the symbol names, or
the library names, or which versions are supported by which systems,
in which local paths, and so on. These are common problems when
dealing with GL, and they're already solved by Qt itself, which the
qml package relies upon for its basics.
Creating the API value is cheap. Don't worry about it.
I have an existing project which uses non-QML OpenGL bindings (Glow GL 2.0)
and I think I should be able to use it with QML without creating an entirely
new version using QML-specific OpenGL bindings (that sounds like a lot of
Porting from/to the OpenGL interface of the qml package to/from any
other sanely designed OpenGL package should be trivial, since they're
just a thin layer on top of the system libraries. That said, if you
have an application entirely designed to work with OpenGL alone, then
I'd recommend not using the qml package. It's just an unnecessary
overhead if you're not using the convenience of the qml framework to
build the application.
4. Can you provide any insight as to why QML does invalidate the OpenGL
It's not just about invalidating the context, but also about being
able to have GL logic working properly on multiple threads, with
multiple GL contexts active. When a specific API version is requested,
the entry points are cached and associated with a GL context, so that
API(p) call is simply a good hook point for us to be able to do that
kind of analysis, and can be easily optimized away to become a NOOP in
5. If the context is truly invalid upon each Paint -- aren't all resources
associated with it also invalidated (textures, etc)? Those can surely be
pretty expensive to upload every paint?
The GL context is not invalidated on each Paint. That'd be very unreasonable.
gustavo @ http://niemeyer.net
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.