[Qt-interest] Qpainter or QtGLWidget

Michael Rice michaelarice at gmail.com
Fri Oct 21 20:56:57 CEST 2011


Ugh, it was so nice about 10 years ago working with SGI hardware that did all of this for you... someday the commodity hardware will catch up.

Until then, if your hardware doesn't support what you need, you might also look into writing a shader program. It may execute faster than a transform code you run in your Qt app.


On Oct 21, 2011, at 2:01 AM, Till Oliver Knoll <till.oliver.knoll at gmail.com> wrote:

> 
> 
> Am 21.10.2011 um 06:33 schrieb Konstantin Volkov <kv.russia at gmail.com>:
> 
>> Hello
>> i am going to write widget with faster changing context (picture on widget).
>> whether or not opengl faster than common Qpaint
> 
> That depends what you mean with "changing context": decoded video frames? Some (all nowadays?) graphic cards have hardware support for decoding e.g. h.264 - that's the big part of work. Displaying these decoded frames at say 30 FPS ("NTSC") should be doable with QPainter.
> 
> However there is another issue: colour space. Depending on the video format the frames might not be encoded in RGB, but say YUV ("Luminance and colour components"). Again there is harware support by certain (most) graphic cards, so use that if possible.
> 
> So far this has nothing to do with OpenGL (even though the task of decoding the video might actually be done on the GPU).
> 
> If however you also want to scale the video, then OpenGL is what you want!
> 
> 
> And so far we were only talking about "bitmaps" - mind you, you also need to upload the bitmap data from RAM to graphics card VRAM, which might also take some while, but there are OpenGL extensions (now part of the OpenGL 3 standard) which make this very fast and even asynchronous: "Buffer Objects".
> 
> If you need to repeatedly draw the same "textures", lots of lines, triangles and other geometric data then OpenGL is always faster. But also more effort!
> 
> My advice would be: stick to the high-level API of Qt of e.g. QPainter. Most often the performance is simply "good enough".
> 
> Or better: use a QGraphicsScene which already provides a solid graphic framework. If that is too slow then you can simply have it paint on a QGLWidget and there you go: OpenGL support without touching any glFunction yourself! Not as optimal as "raw OpenGL" code, but again: most often "good enough" (note that naturally the view QGraphicsView cannot optimise /every/ draw operation).
> 
> If you try OpenGL: "Remember to turn at least the light on when you point your camera into the opposite direction of a black cube on a black background!" ;)
> 
> Cheers, Oliver
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest



More information about the Qt-interest-old mailing list