white background with waveform 2.0

[Daniel Schürmann]

On the following system the waveform 2.0 background is white
* Atom CPU N270 @ 1.6GHz
* 2 GiB RAM
* Ubuntu Lucid
* QT Version Qt version 4.6.2.
* Intel 945GME

This seems to be depending with Bug #887269

It happens with "Filtered (GL)", "Filtered (GLSL)" and not with "Filtered"
"Filtered (GLSL)" has no waveforms, only the | bars.

[Daniel Schürmann (daschuer)]

Retested with lp:mixxx #3171:

The issue is still the same.
The new options pure GL are also effected

Filtered (GL)
Simple (GL)
Filtered - Qt (GL)
Simple - Qt (GL)

[Daniel Schürmann (daschuer)]

The attached patch solves the problem ont the device of #0.

I have changed drawPixamp to drawImage.

There is still a Pixamp version of the bitmap in Memory, to easy test the the performance on other Systems.
The patch includes the results from tests on #0 Netbook with Qt 4.6 and Intel GPU and a ubuntu desktop box with Qt 4.8 and Radeon driver.

It turns out that although we can read this:
http://qt-project.org/doc/qt-4.8/qimage.html
"QImage is designed and optimized for I/O, and for direct pixel access and manipulation, while QPixmap is designed and optimized for showing images on screen."

.. the drawImage version is significant faster and not at least Intel Qt 4.6 compatible.

If we find systems, where this is not the case we can include conditions for using drawPixamp. But for the moment this version is just fine. Or we may remove the Pixamp copys from memory later.

This patch works also on ubuntu 64 and 32 with nvidia driver and on WinXp in a Virtual Box.

[RJ Skerry-Ryan (rryan)]

I'm very confused by this bug. In general to render a QImage, Qt first converts it to a QPixmap. In the case of a QGLWidget, QPixmaps have to be transferred to the graphics card first. One speedup that Qt does under the covers is cache the transferred QPixmap on the graphics card in the GPU's RAM. I'm just pretty surprised it's faster to draw a QImage than a QPixmap in some of these cases. I think that using QPixmap's is the "right" thing design-wise but it's troubling we are seeing these corruption issues.

Did white waveforms happen with Qt 4.8.3 on the netbook?

[Daniel Schürmann (daschuer)]

> .. I'm very confused by this bug. ..
Me to :-(

Jumping through Qt source we can see seen that it sometimes finally ends in qgl.cpp #2690:
(at least two times after start-up using gdb)

QGLTexture *QGLContextPrivate::bindTexture(const QPixmap &pixmap, GLenum target, GLint format, QGLContext::BindOptions options)
...
        QImage image = pixmap.toImage();
...

--------

I have tested Linux Mint 13 with Qt 4.8.1 on the Atom hardware and I do not have a white background there.

But anyhow I like to see this fixed in trunk because we build against Ubuntu Lucid and this is suffering the bug.
Lucid is supported until April 2013, so we should do it as well.

So we may make the fix depending to the Qt Version, until we found out in which conditions drawImage() is faster than drawPixamp() on Machines with a current Qt version.

[Daniel Schürmann (daschuer)]

Hello,
when working on https://bugs.launchpad.net/mixxx/+bug/981210, It turns out
that at least on my hardware QPixamp is drawed slower than QImage. This
seems differ to that, what is stated in the Qt documentation.

Attached you will find a test QT project which shows the issue with two
Mixxx logos.
I would be pleased if you can post your results at
https://bugs.launchpad.net/mixxx/+bug/981210, so we are able to decide how
we will fix this bug.

My results are:
Qt4.8 Ubuntu Precise, nVidia 310.19, NVS 3100M:
QPixamp: min 38 µs mean 115 µs
QImage: min 22 µs mean 58 µs

Qt4.8 WinXp in a VBox
QPixamp: mean 55 µs
QImage: mean 39 µs
(It seams there is a Problem with Timing measurement in the VBox because
the Minimum Values are about 0.)

Thank You

Daniel

[Max Linke (max-linke)]

I found this

http://stackoverflow.com/questions/10307860/what-is-difference-between-qimage-and-qpixmap

The behaviour described in the last comment is exactly what I can reproduce.

For an Image that is just painted once, QImage is faster and QPixmap is faster when I want to draw something fast more then once. I've adjusted your test project a bit to also show the time for the first rendering and to throw away the first 100 measurements for the mean (the mean is now visibly more stable instead of decaying over time)

Qt 4.8 Debian Wheezy
QPixmap: min 56 mus , mean 116 mus, first render 31804 mus
QImage: min 54 mus, mean 120 mus, first render 26442 mus

But I doubt how valid this test is since I get the same results if I render both times a QImage/QPixmap

[Daniel Schürmann (daschuer)]

Thank you Max, which Driver and GPU you are using?
It looks like the result depends on the used driver. Maybe your results are the same because the underlying implementation is the same?

I have also tested without the first 100 measures with this result:
Qt4.8 Ubuntu Precise, nVidia 310.19, NVS 3100M:
QPixamp: min 58 µs mean 74 µs
QImage: min 26 µs mean 55 µs

Qt4.8 WinXp in a VBox
QPixamp: mean 35 µs
QImage: mean 21 µs

Attached you will find the new Version I have used.

[Daniel Schürmann (daschuer)]

Oh now I understand painting the right Logo takes always longer than painting the left one regardless of using QPixmap or QImage.

Attached you will find a version with four logos. I think the lower row is now significant.

Result:
Qt4.8 Ubuntu Precise, nVidia 310.19, NVS 3100M:
QPixamp: min 14 µs mean 35 µs
QImage: min 14 µs mean 33 µs

[Daniel Schürmann (daschuer)]

An here the result from WinXP in VBox:
QPixamp: mean 21 µs
QImage: mean 21 µs

[Max Linke (max-linke)]

With your new Version they are both around 26 mus

My Graphics Card Info(official AMD Driver), I will try this later on my laptop

kain88@640X4:2dpainting$ fglrxinfo
display: :0 screen: 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon HD 7700 Series
OpenGL version string: 4.2.11762 Compatibility Profile Context

[Daniel Schürmann (daschuer)]

Here results from a Win2000 System, Intel Q33
QPixamp min 16 µs mean 20 µs
QImage min 13 µs mean 17 µs

[Max Linke (max-linke)]

Debian Wheezy Intel (i think it is) GMA45 ~47 mus for both in the last row

[Daniel Schürmann (daschuer)]

Ubuntu Precise, Qt 4.8.1, Radeon Driver 1.6.2 on AMD RV710
QPixamp min 41 µs mean 69 µs
QImage min 40 µs mean 62 µs

Ubuntu Lucid QT 4.6.2. Intel 945GME
QPixamp White Display
QImage min 65 µs mean 69 µs

[Daniel Schürmann (daschuer)]

Hello,

Now we have results from various Win and Linux.

Is there one who what's to run the test on Mac OS and Win7?
Than we can finally decide how to fix this bug.

Please help, thank you!

The test source can be found at https://bugs.launchpad.net/mixxx/+bug/981210.

Kind regards,

Daniel

2012/12/4 Daniel Schürmann <email address hidden>

> Hello,
>
> Please do not use the attached Project from my last Post. Max found out
> that the results are not reliable.
> I have prepared a improved version attached to
> https://bugs.launchpad.net/mixxx/+bug/981210,
>
> Thank you,
>
> Daniel
>
>
>
> 2012/12/4 Daniel Schürmann <email address hidden>
>
>> Hello,
>> when working on https://bugs.launchpad.net/mixxx/+bug/981210, It turns
>> out that at least on my hardware QPixamp is drawed slower than QImage. This
>> seems differ to that, what is stated in the Qt documentation.
>>
>> Attached you will find a test QT project which shows the issue with two
>> Mixxx logos.
>> I would be pleased if you can post your results at
>> https://bugs.launchpad.net/mixxx/+bug/981210, so we are able to decide
>> how we will fix this bug.
>>
>> My results are:
>> Qt4.8 Ubuntu Precise, nVidia 310.19, NVS 3100M:
>> QPixamp: min 38 µs mean 115 µs
>> QImage: min 22 µs mean 58 µs
>>
>> Qt4.8 WinXp in a VBox
>> QPixamp: mean 55 µs
>> QImage: mean 39 µs
>> (It seams there is a Problem with Timing measurement in the VBox because
>> the Minimum Values are about 0.)
>>
>> Thank You
>>
>> Daniel
>>
>>
>>
>

[Adam Davison (adamdavison)]

Hey,

I have Qt 4.6.1 installed on my computer, which I know isn't the
version which ships with Mixxx any more but I was able to test on a
mid-2010 macbook pro, OSX 10.7.4.

The 4 mean values it displays are:

881ns 966ns
499ns 545ns

Adam

On 8 December 2012 14:21, Daniel Schürmann <email address hidden> wrote:
> Hello,
>
> Now we have results from various Win and Linux.
>
> Is there one who what's to run the test on Mac OS and Win7?
> Than we can finally decide how to fix this bug.
>
> Please help, thank you!
>
> The test source can be found at
> https://bugs.launchpad.net/mixxx/+bug/981210.
>
> Kind regards,
>
> Daniel
>
>
>
>
>
> 2012/12/4 Daniel Schürmann <email address hidden>
>>
>> Hello,
>>
>> Please do not use the attached Project from my last Post. Max found out
>> that the results are not reliable.
>> I have prepared a improved version attached to
>> https://bugs.launchpad.net/mixxx/+bug/981210,
>>
>> Thank you,
>>
>> Daniel
>>
>>
>>
>> 2012/12/4 Daniel Schürmann <email address hidden>
>>>
>>> Hello,
>>> when working on https://bugs.launchpad.net/mixxx/+bug/981210, It turns
>>> out that at least on my hardware QPixamp is drawed slower than QImage. This
>>> seems differ to that, what is stated in the Qt documentation.
>>>
>>> Attached you will find a test QT project which shows the issue with two
>>> Mixxx logos.
>>> I would be pleased if you can post your results at
>>> https://bugs.launchpad.net/mixxx/+bug/981210, so we are able to decide how
>>> we will fix this bug.
>>>
>>> My results are:
>>> Qt4.8 Ubuntu Precise, nVidia 310.19, NVS 3100M:
>>> QPixamp: min 38 µs mean 115 µs
>>> QImage: min 22 µs mean 58 µs
>>>
>>> Qt4.8 WinXp in a VBox
>>> QPixamp: mean 55 µs
>>> QImage: mean 39 µs
>>> (It seams there is a Problem with Timing measurement in the VBox because
>>> the Minimum Values are about 0.)
>>>
>>> Thank You
>>>
>>> Daniel
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
>
>
> Mixxx-devel mailing list
> <email address hidden>
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel

[RJ Skerry-Ryan (rryan)]

Mac OSX Mountain Lion (10.8.2) w/ Qt 4.8.3

Min:
40706 36105
35359 35496

Mean (top 3 digits)
55.9us 50.3us
47.3us 47.0us

[RJ Skerry-Ryan (rryan)]

I get different result (in terms of whether QImage or QPixmap is faster) each time I run the program but I haven't shut down all other programs while running this test yet.

It would be good to calculate the max and the variance in addition the mean and min. We should know how noisy the measurement is.

Also, even though the QGLWidgets are not drawing concurrently I wonder if we should just have 1 widget and run the program twice (once with QImage and once with QPixmap).

[RJ Skerry-Ryan (rryan)]

Oh, also the only QGLFormat change is just using sample buffers. I wonder if we should take the QGLFormat we set as default form WaveformWidgetFactory.

[Daniel Schürmann (daschuer)]

Fist of all: thank you all testers.

For me, we have now already enough information to decide.

On most systems drawing QPixamp and QImage takes approximately the same time.
Then we have at least on system , where drawing QPixamp is buggy and some systems where QPixamp takes longer.

All test systems have run the test application and I have made test results from within the original Mixxx code that are verifying the results.

I do not expect any surprise from further investigations.

So for me, it should be save to change drawPixamp calls to draw Image. This will:
* Fix the bug
* Saves some CPU Time on some systems
* does not take significant more CPU time on other systems
* gains drawing on an optimized for IO QImage for all off screen renderer

Do you agree?
Then I would prepare an optimized patch.

[RJ Skerry-Ryan (rryan)]

Given the data I agree with Daniel -- it's safe to swap our QPIxmap for QImage and it will fix some systems where we have white backgrounds.

An additional benefit is that if we move rendering to a thread in a future version of Mixxx we won't be using QPixmap which is not safe for use outside the main thread.

[RJ Skerry-Ryan (rryan)]

Now that the QPixmap's are gone, is it safe to close this bug?

[Daniel Schürmann (daschuer)]

Wspinny is still suffering this issue, I will fix it soon and than close this bug and Bug #792237.

[Daniel Schürmann (daschuer)]

finally fixed in lp:mixxx/1.11 #3622

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6363