[Development] Fwd: [graphics] SG13 Chicago Meeting Minutes

[Zack Rusin]

On Sun, Sep 29, 2013 at 1:47 AM, Thiago Macieira
<thiago.macieira at 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