Text.color can't be compared reliably

[Michał Sawicz]

Given the below QML:

import QtQuick 2.4

Text {
    id: text
    text: 'foobar'
    color: foobar

    property color foobar: Qt.rgba(0, 0, 0, 0.5)
    property color foobar2: foobar

    Component.onCompleted: {
        console.log("text:", text.color, foobar, Qt.colorEqual(text.color, foobar), text.color.a);
        console.log("property:", foobar2, foobar, Qt.colorEqual(foobar2, foobar), foobar2.a);
        /*
            qml: text: #80000000 #80000000 false 0.5019607843137255
            qml: property: #80000000 #80000000 true 0.5000076295109483
        */
    }
}

Seems that Text.color stores the colour with a different precision, resulting in Qt.colorEqual() returning false.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libqt5quick5 5.6.1-4ubuntu3~xenialoverlay1~1 [origin: LP-PPA-ci-train-ppa-service-stable-phone-overlay]
ProcVersionSignature: Ubuntu 4.4.0-36.55-generic 4.4.16
Uname: Linux 4.4.0-36-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Sep 1 14:40:27 2016
InstallationDate: Installed on 2016-05-06 (117 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: qtdeclarative-opensource-src
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lukáš Tinkl (lukas-kde)]

Interesting observation:

QColor::darker(int factor) versus QML's Qt.darker(color baseColor, real factor)

which might cause the discrepancy in the alpha floating point precision

[James Henstridge (jamesh)]

QColor stores RGB colour with 16 bits per channel, so "0.5" would convert to 32768 (i.e. round(0.5 * 65535)), or 0x8000.

If you convert down to 8 bits per channel, you'll have 0x80. If you convert that value back up to 16 bits per channel, you'll have 0x8080. And finally, converting that to floating point gives you 0.50196.

So you'll probably need to adjust the tests to accept an error on the order of 1/(2*255) in these values.

[Michał Sawicz (saviq)]

Yeah, we did that, however I'm not sure I agree that we should need to.