> Looks good to me. A few minor quibbles:
>
> In thumbnailerimageresponse.cpp, there is a stale comment in textureFactory().
Fixed.
>
> The test writes to ~/.cache/unity-thumbnailer. It would be good to write to a
> different cache dir. (Setting XDG_CACHE_HOME for the test should take care of
> it.)
Which test are you referring to?
> In Fixture.qml. line 113:
>
> return Qt.rgba(data[pos] / 255, data[pos+1] / 255, data[pos+2] / 255,
> data[pos+3] / 255);
>
> Might this be behind the failure on big-ending machines?
The data is documented to be in RGBA order, which matches the order of the arguments to Qt.rgba():
> Looks good to me. A few minor quibbles: eresponse. cpp, there is a stale comment in textureFactory().
>
> In thumbnailerimag
Fixed.
> unity-thumbnail er. It would be good to write to a
> The test writes to ~/.cache/
> different cache dir. (Setting XDG_CACHE_HOME for the test should take care of
> it.)
Which test are you referring to?
> In Fixture.qml. line 113:
>
> return Qt.rgba(data[pos] / 255, data[pos+1] / 255, data[pos+2] / 255,
> data[pos+3] / 255);
>
> Might this be behind the failure on big-ending machines?
The data is documented to be in RGBA order, which matches the order of the arguments to Qt.rgba():
http:// doc.qt. io/qt-5/ qml-qtquick- canvasimagedata .html#data- prop
Even this data was in an endian dependent format, it wouldn't explain why we're reading out black pixels on the problem architectures.