Bug 46277 - No result from pixman_image_composite32() with bigger transform
Summary: No result from pixman_image_composite32() with bigger transform
Status: RESOLVED MOVED
Alias: None
Product: pixman
Classification: Unclassified
Component: pixman (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Siarhei Siamashka
QA Contact: Søren Sandmann Pedersen
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-19 02:48 UTC by Uli Schlachter
Modified: 2018-06-05 15:26 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Test case using just pixman (1.06 KB, text/plain)
2012-02-19 02:48 UTC, Uli Schlachter
Details
Test case using cairo (1.07 KB, text/plain)
2012-02-19 02:49 UTC, Uli Schlachter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uli Schlachter 2012-02-19 02:48:17 UTC
Created attachment 57269 [details]
Test case using just pixman

Attached are two tests programs. The cairo one should produce a file "out.png" completely filled with blue, but instead the PNG is transparent.

The pixman test does (more or less) the same calls to pixman as cairo does when executing the above test. This should output "ff0000ff", but instead just says "0".

The pixman test has an "#if 0" at the beginning. When that is replaced with "#if 1", the correct result is generated.
The cairo test has the equivalent of this "#if" in lines 21/22. Depending on which of the two lines is uncommented, the test works or doesn't work.
Comment 1 Uli Schlachter 2012-02-19 02:49:06 UTC
Created attachment 57270 [details]
Test case using cairo
Comment 2 Søren Sandmann Pedersen 2012-02-20 17:49:15 UTC
This is almost certainly because the transformation implies that coordinates outside of the 16.16 coordinate space are used. If so, it's a long-standing and hard-to-fix issue that probably involves using floating point for transformations.
Comment 3 Siarhei Siamashka 2012-02-24 06:02:23 UTC
In my opinion the issue is indeed hard to fix, but not impossible. This can be probably handled by generalizing fixed point support in the code (allow representations other than 16.16) and making sure that as many problems as possible are detected by the test suite. Using some toy 8.8 fixed point representation as a default can be used to check how the corner cases are handled and experiment with automatic promotion to something bigger (16.16 or more).

Floating point coordinates are also an option. They are harder to test due to non-bitexact results. But if the code is first adapted to support multiple fixed point representations, then just dropping in another representation (floating point one) should be much less painful.
Comment 4 Siarhei Siamashka 2014-09-21 22:24:10 UTC
Now this particular problem should be easier to fix after the introduction of http://cgit.freedesktop.org/pixman/commit/?id=c3deb8334a71998b986a7b8d5b74bedf26cc23aa
Comment 5 GitLab Migration User 2018-06-05 15:26:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pixman/pixman/issues/1.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.