On Sun, Sep 29, 2013 at 1:47 AM, Thiago Macieira <thiago.macie...@intel.com> wrote: > Is there anyone who would be willing to offer our expertise in QWindow, > QOpenGLContext, QBackingStore, QPainter, etc.?
"Don't do it". Don't get me wrong, I love the sky's the limit attitude ("simple and accessible to beginners, but also usable to experts as well (avoid glass ceiling if possible)"), which seems to be completely devoid of any realistic knowledge of how this stuff actually works, but this isn't going to amount to anything but a toy api. In general any graphics library that tries to wrap other graphics api's ends up as a disaster. You don't wrap them, you enable them. Actually let me rephrase that, wrapping has its place, if you have a library with a very specialized intent, e.g. this is a visualization toolkit for stock data, or this is a library to teach programming. Graphics api's aren't the problem, graphics is simply complicated. Writing a generic library that's wrapping graphics apis isn't solving a problem of its inherent difficulty, it's simply introducing a library that's severely limiting in what it can be used for. We really don't need to standardize those. That example that was shown in the "One C++" keynote is a great example: one vb uploaded on every frame - so easy! Yes, and so terrible. I cringe every time anyone says that they want to write an immediate mode graphics library. From graphics perspective QML on top of scene-graph is pretty much as good as it gets for graphics apps - simple, yet, exposing full power of the underlying api (OpenGL). So, fwiw, from what I've read and the presentation I just watched, this just doesn't look useful to anyone. z _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development