Qt-interest Archive, August 2007
High performance drawing
Message 1 in thread
Hello group,
I have a big problem.
I need to show Images (PNGs with size: 808x750 px) with an average framerate
of 14 Frames per second. I tested all this just on Linux:
1.) with the Graphics-View-Framework but I got only 4.2 Frames per second
(65% CPU usage of X11)
2.) with a QWidget and drawing in paintEvent but I got only 3.9 Frames per
second (65% CPU usage of X11)
3.) with drawing the image in the paintEvent of the MainWindow with
setAttribute(Qt::WA_OpaquePaintEvent) but I got only 10 Frames per second
Is there a possibility in Qt which allows a high-speed-drawing such as
DirectDraw under Windows?
Hope for your help...
Best Regards,
Patrick Feistel
--
[ signature omitted ]
Message 2 in thread
> I need to show Images (PNGs with size: 808x750 px) with an average
> framerate of 14 Frames per second. I tested all this just on Linux:
> 1.) with the Graphics-View-Framework but I got only 4.2 Frames per second
> (65% CPU usage of X11)
> 2.) with a QWidget and drawing in paintEvent but I got only 3.9 Frames per
> second (65% CPU usage of X11)
> 3.) with drawing the image in the paintEvent of the MainWindow with
> setAttribute(Qt::WA_OpaquePaintEvent) but I got only 10 Frames per second
Some questions/suggestions:
- PNG might not be a proper format to do this. Try mplayer mf://*.png and you
will notice that it has trouble keeping up, or will at least use much more
processorpower than the average video format. How fast can mplayer play your
png files ?
- There is a big difference between a QPixmap and a QImage when putting things
to screen. The documentation states that QPixmap should be used for drawing.
Which one of both did you use ?
With kind regards,
--
[ signature omitted ]
Message 3 in thread
Hi again,
I took QImage because I get the data as QImage and a conversion to QPixmap
would take to much time...
But I solved the problem with the performance.
I just did an error in the QWidget::paintEvent method and after removing
this, I get 14.2 Frames per second...
Regards,
Patrick
"Werner Van Belle" <werner@xxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:200708061253.00380.werner@xxxxxxxxxxxxxxxxxx
>> I need to show Images (PNGs with size: 808x750 px) with an average
>> framerate of 14 Frames per second. I tested all this just on Linux:
>> 1.) with the Graphics-View-Framework but I got only 4.2 Frames per second
>> (65% CPU usage of X11)
>> 2.) with a QWidget and drawing in paintEvent but I got only 3.9 Frames
>> per
>> second (65% CPU usage of X11)
>> 3.) with drawing the image in the paintEvent of the MainWindow with
>> setAttribute(Qt::WA_OpaquePaintEvent) but I got only 10 Frames per second
>
> Some questions/suggestions:
> - PNG might not be a proper format to do this. Try mplayer mf://*.png and
> you
> will notice that it has trouble keeping up, or will at least use much more
> processorpower than the average video format. How fast can mplayer play
> your
> png files ?
> - There is a big difference between a QPixmap and a QImage when putting
> things
> to screen. The documentation states that QPixmap should be used for
> drawing.
> Which one of both did you use ?
>
> With kind regards,
>
> --
> Dr. Werner Van Belle
> http://werner.yellowcouch.org/
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 4 in thread
Patrick Feistel schrieb:
> Hi again,
>
> I took QImage because I get the data as QImage and a conversion to QPixmap
> would take to much time...
A QImage - when painted with a QPainter - is always converted to a
QPixmap in the end. That's what the last parameter
Qt::ImageConversionFlags is for.
Hence QPainter::drawPixmap is always faster, since a QPixmap is in the
screen's "native" format.
In general:
QImage: stores the "real" image data (32 bit with alpha or colour
indexed). Used for direct pixel access and manipulation.
QPixmap: Uses the colour resolution of the screen (e.g. just 16bit or
even 8bit) and is used for fast drawing. No direct pixel access (data is
aligned/packed in screen "native" format)
Cheers, Oliver
--
[ signature omitted ]
Message 5 in thread
This is also important:
"On X11 and Mac, a QPixmap is stored on the server side while a QImage
is stored on the client side"
So once you have transferred a QPixmap to the X-server (i.e. your
display) the drawing is fast, while a QImage always has to be first
converted and sent (possibly over the network) to the X-server before it
can be shown.
Cheers,
Peter
> -----Original Message-----
> From: Till Oliver Knoll [mailto:oliver.knoll@xxxxxxxxxxx]
> Sent: Monday, August 06, 2007 3:44 PM
> To: Qt Interest List
> Subject: Re: High performance drawing
>
> Patrick Feistel schrieb:
> > Hi again,
> >
> > I took QImage because I get the data as QImage and a conversion to
> QPixmap
> > would take to much time...
>
> A QImage - when painted with a QPainter - is always converted to a
> QPixmap in the end. That's what the last parameter
> Qt::ImageConversionFlags is for.
>
> Hence QPainter::drawPixmap is always faster, since a QPixmap is in the
> screen's "native" format.
>
> In general:
>
> QImage: stores the "real" image data (32 bit with alpha or colour
> indexed). Used for direct pixel access and manipulation.
>
> QPixmap: Uses the colour resolution of the screen (e.g. just 16bit or
> even 8bit) and is used for fast drawing. No direct pixel access (data
is
> aligned/packed in screen "native" format)
>
> Cheers, Oliver
>
--
[ signature omitted ]
Message 6 in thread
Hi again,
my problem is that I get the data from another thread as QImage because I
can't get it as QPixmap, otherwise I would get an "unexpected asynch reply"
of X under Linux.
Is there a faster possibility as QPixmap::fromImage() to convert a QImage to
a QPixmap because I don't reach my 14F/sec when doing this.
Regards,
Patrick
"Peter Prade" <prade@xxxxxxxxxxx> schrieb im Newsbeitrag
news:1C5B9B48EC79514FB4F4A7884ACFCB9F22456D@xxxxxxxxxxxxxxxxxxxxxxx
This is also important:
"On X11 and Mac, a QPixmap is stored on the server side while a QImage
is stored on the client side"
So once you have transferred a QPixmap to the X-server (i.e. your
display) the drawing is fast, while a QImage always has to be first
converted and sent (possibly over the network) to the X-server before it
can be shown.
Cheers,
Peter
> -----Original Message-----
> From: Till Oliver Knoll [mailto:oliver.knoll@xxxxxxxxxxx]
> Sent: Monday, August 06, 2007 3:44 PM
> To: Qt Interest List
> Subject: Re: High performance drawing
>
> Patrick Feistel schrieb:
> > Hi again,
> >
> > I took QImage because I get the data as QImage and a conversion to
> QPixmap
> > would take to much time...
>
> A QImage - when painted with a QPainter - is always converted to a
> QPixmap in the end. That's what the last parameter
> Qt::ImageConversionFlags is for.
>
> Hence QPainter::drawPixmap is always faster, since a QPixmap is in the
> screen's "native" format.
>
> In general:
>
> QImage: stores the "real" image data (32 bit with alpha or colour
> indexed). Used for direct pixel access and manipulation.
>
> QPixmap: Uses the colour resolution of the screen (e.g. just 16bit or
> even 8bit) and is used for fast drawing. No direct pixel access (data
is
> aligned/packed in screen "native" format)
>
> Cheers, Oliver
>
--
[ signature omitted ]
Message 7 in thread
> my problem is that I get the data from another thread as QImage because I
> can't get it as QPixmap, otherwise I would get an "unexpected asynch reply"
> of X under Linux. Is there a faster possibility as QPixmap::fromImage() to
> convert a QImage to a QPixmap because I don't reach my 14F/sec when doing
> this.
Yes, I have a similar experience with QPixmap/QPixmaps. I had also to fall
back to a QImage because bitblt'ng to a QPixmap seems not possible (or I
didn't find how to do it anyway).
With kind regards,
Werner,-
--
[ signature omitted ]
Message 8 in thread
Is OpenGl an option?
Thomas
Am Dienstag, 7. August 2007 07:12 schrieb Patrick Feistel:
> Hi again,
>
> my problem is that I get the data from another thread as QImage because I
> can't get it as QPixmap, otherwise I would get an "unexpected asynch reply"
> of X under Linux.
> Is there a faster possibility as QPixmap::fromImage() to convert a QImage
> to a QPixmap because I don't reach my 14F/sec when doing this.
>
> Regards,
> Patrick
--
[ signature omitted ]
Message 9 in thread
Thomas LÃbking schrieb:
> Is OpenGl an option?
I doubt so: displaying a QImage with OpenGL requires a conversion of the
QImage data into OpenGL data (QGLWidget::convertToGLFormat()) and I
don't think this is significantly faster than converting a QImage to a
QPixmap, but I could be wrong.
The bottleneck really seems to be converting QImages to a displayable
data structure, not the painting itself. OpenGL accelerates the painting
only, once the data is available in a suitable format.
14 FPS doesn't seem to be a too high performance requirement on a fast
hardware, for a reasonably sized QImage (let's say 800 x 600 pixels),
no? But then again, modern video player software uses the video card
hardware directly as to decode colour information (YUV to RGB or
whatever) from the encoded video stream (okay, decoding a video stream
itself also takes a lot of CPU, depending on the video format, so this
is not a 1:1 comparison off course), and I bet there is a very good
reason for it ;)
Cheers, Oliver
--
[ signature omitted ]
Message 10 in thread
Till Oliver Knoll wrote:
> Thomas LÃbking schrieb:
>> Is OpenGl an option?
>
> I doubt so: displaying a QImage with OpenGL requires a conversion of
> the QImage data into OpenGL data (QGLWidget::convertToGLFormat()) and
> I don't think this is significantly faster than converting a QImage to
> a QPixmap, but I could be wrong.
>
> The bottleneck really seems to be converting QImages to a displayable
> data structure, not the painting itself. OpenGL accelerates the
> painting only, once the data is available in a suitable format.
>
You may not need to convert to an OpenGL format, you can pass the image
data to OpenGL as luminance rectangular texture, and then write a small
pixel shader to convert that data into color information. This way, the
conversion will take place on the GPU.
Paul.
--
[ signature omitted ]
Message 11 in thread
On 8/7/07, Patrick Feistel <Feistel@xxxxxxxxxx> wrote:
> Hi again,
>
> my problem is that I get the data from another thread as QImage because I
> can't get it as QPixmap, otherwise I would get an "unexpected asynch reply"
> of X under Linux.
> Is there a faster possibility as QPixmap::fromImage() to convert a QImage to
> a QPixmap because I don't reach my 14F/sec when doing this.
Have you tried QPainter::drawImage(QImage*) to draw the image into a
widget? I've worked on an app that achieves 640x640 at well over 40fps
on a machine with the lowest of low-end Intel integrated graphics.
808x750 at 14fps shouldn't be a problem at all, as far as displaying
image data is concerned. If there's a bottleneck, it's more likely in
your acquisition or processing code.
--
[ signature omitted ]
Message 12 in thread
On 8/7/07, Andrew Medico <a.medico@xxxxxxxxx> wrote:
> On 8/7/07, Patrick Feistel <Feistel@xxxxxxxxxx> wrote:
> > Hi again,
> >
> > my problem is that I get the data from another thread as QImage because I
> > can't get it as QPixmap, otherwise I would get an "unexpected asynch reply"
> > of X under Linux.
> > Is there a faster possibility as QPixmap::fromImage() to convert a QImage to
> > a QPixmap because I don't reach my 14F/sec when doing this.
>
> Have you tried QPainter::drawImage(QImage*) to draw the image into a
> widget? I've worked on an app that achieves 640x640 at well over 40fps
> on a machine with the lowest of low-end Intel integrated graphics.
> 808x750 at 14fps shouldn't be a problem at all, as far as displaying
> image data is concerned. If there's a bottleneck, it's more likely in
> your acquisition or processing code.
Another demo does 1024x768x32bpp @ 33fps (including generating the raw
bitmap frame in realtime) on the same low-end graphics hardware, so
what you are asking is well within the capabilities of Qt's 2D
graphics system.
--
[ signature omitted ]
