[Interest] Quick2 OpenGL inefficiency?

[Filip Piechocki]

I don't know how you produce the video frames, but check that the software
you are using might be able to produce OpenGL texture directly (not the
buffer data). If not then here are some useful links:
http://stackoverflow.com/questions/9863969/updating-a-texture-in-opengl-with-glteximage2d
http://www.gamedev.net/topic/641283-fastest-way-to-stream-video-to-texture/

So basically you'll need to use glTexSubImage2D directly (and you probably
do not need QImage at all) and for custom OpenGL rendering you can use
QQuickFramebufferObject as your DisplayItem:
http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/

On Tue, Mar 8, 2016 at 7:00 AM, Jani Tykka <jtykka at broadsoft.com> wrote:

> I'm creating the image from buffer which is unsigned char buffer
> containing video frame data
> QImage( buffer, width, height, QImage::Format_RGB32 );
>
>
>
> On Mon, Mar 7, 2016 at 10:05 PM, Filip Piechocki <fpiechocki at gmail.com>
> wrote:
> >
> > How are you generating those images? What do they represent?
> >
> > On Mar 7, 2016 20:55, "Jani Tykka" <jtykka at broadsoft.com> wrote:
> >>
> >> Images are passed from another thread in rate 15-30 fps. Is there an
> example available how to achieve Image to OpenGL texture and use it in
> scene graph?
> >>
> >> On Mon, Mar 7, 2016 at 5:11 PM, Filip Piechocki <fpiechocki at gmail.com>
> wrote:
> >>>
> >>> And where it comes from? How frequent it happens? Probably the best
> thing here would be to generate this image as an OpenGL texture and then
> use in the Qt's scene graph.
> >>>
> >>> On Mon, Mar 7, 2016 at 4:04 PM, Jani Tykka <jtykka at broadsoft.com>
> wrote:
> >>>>
> >>>> Yes, the image is always changed when the update is invoked.
> >>>>
> >>>> On Mon, Mar 7, 2016 at 4:43 PM, Filip Piechocki <fpiechocki at gmail.com>
> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Why are you re-creating the texture on every node update? Does the
> m_Renderer->getImage() really changes? My first guess would be that the
> texture creation from image is the most costly part here (uploading the
> texture to GPU?) and I would do this only if necessary (the image really
> changes).
> >>>>>
> >>>>> BR,
> >>>>> Filip
> >>>>>
> >>>>> On Mon, Mar 7, 2016 at 3:04 PM, Jani Tykka <jtykka at broadsoft.com>
> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> We are rendering QImages on QQuickItem as following:
> >>>>>>
> >>>>>> QSGNode * DisplayItem::updatePaintNode( QSGNode * node,
> UpdatePaintNodeData * /*data*/ )
> >>>>>>
> >>>>>> {
> >>>>>>
> >>>>>> QSGSimpleTextureNode * n = static_cast< QSGSimpleTextureNode* >(
> node );
> >>>>>>
> >>>>>> if ( !n )
> >>>>>>
> >>>>>> n = new QSGSimpleTextureNode;
> >>>>>>
> >>>>>>
> >>>>>> n->setRect( 0, 0, width(), height() );
> >>>>>>
> >>>>>>
> >>>>>> delete m_Texture;
> >>>>>>
> >>>>>>
> >>>>>> m_Texture = window()->createTextureFromImage(
> m_Renderer->getImage() );
> >>>>>>
> >>>>>> n->setTexture( m_Texture );
> >>>>>>
> >>>>>>
> >>>>>> return n;
> >>>>>>
> >>>>>> }
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> It seems that computers with separate GPU there is a decent amount
> of CPU utilised. We are running into problems if the machine lacks GPU,
> then with large images the CPU usage grows drastically. Any suggestions how
> to improve large image painting on QQuickItem? With Quick1 and painting
> directly on HWND/CocoaWindow we didn't experience this high CPU usage.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> This email is intended solely for the person or entity to which it
> is addressed and may contain confidential and/or privileged information. If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, and
> destroy all copies of this message, along with any attachment, prior to
> reading, distributing or copying it.
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Interest mailing list
> >>>>>> Interest at qt-project.org
> >>>>>> http://lists.qt-project.org/mailman/listinfo/interest
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Jani Tykkä
> >>>> Development Manager | BroadSoft, Inc. | +358 44 596 0587 |
> jtykka at broadsoft.com
> >>>>
> >>>>
> >>>> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information. If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, and
> destroy all copies of this message, along with any attachment, prior to
> reading, distributing or copying it.
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jani Tykkä
> >> Development Manager | BroadSoft, Inc. | +358 44 596 0587 |
> jtykka at broadsoft.com
> >>
> >>
> >> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information. If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, and
> destroy all copies of this message, along with any attachment, prior to
> reading, distributing or copying it.
>
>
>
>
> --
> Jani Tykkä
> Development Manager | BroadSoft, Inc. | +358 44 596 0587 |
> jtykka at broadsoft.com
>
>
> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information. If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, and
> destroy all copies of this message, along with any attachment, prior to
> reading, distributing or copying it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160308/f0347743/attachment.html>