Running Xorg-1.4.99.902/Intel-2.3.2 I see blur on the y-axis also when scaling on the x-axis only, when billinear filtering is used. This does not happen using XAA/pixman, testcase attached. I took screenshots of the problem (the first two pictures belong to a different topic): Should be: http://picasaweb.google.de/linuxhippy/Transformations/photo#5224020903104218962 Is: http://picasaweb.google.de/linuxhippy/Transformations/photo#5224017614970060162 The Line with RepeatPad falls back to pixman, thats why its rendered correctly. Accoding to the mailing-list this bug does also happen with the latest version of the intel driver.
Created attachment 18026 [details] testcase
Clemens, thanks for filing a bug. would you please kindly follow the instructions at http://www.intellinuxgraphics.org/how_to_report_bug.html to provide us more information about your environment so that we can try to reproduce this bug? Seems a bug for Carl...
Ok ... here it is: Happends on Fedora 8, 9 and Rawhide with: Toshiba Tecra A8, Intel-945GM, i386, XOrg-1.4.99.905, Linux-2.6.25
I was unable to replicate the bug with the testcase on an i965 machine. I can try later with an i945 machine. in the meantime, it looks like the issue is not with "blur on y-axis", but probably more likely an issue with an off-by-one-half-pixel difference in the sampling location used somewhere. We have had various bugs like this in the X server and in pixman. Clemens, if you're still seeing this bug, a useful tweak to the test case would be to make the source something like 10x10 rather than 10x1. If the bug is what I'm thinking, then that should make the difference in behavior of the X and Y axes more apparent. Thanks, -Carl
Hi Carl, Thanks for looking into this. I attached the screenshot of the testcase with a 10x10 source pixmap, and a 5x scale on the x-axis. This is with Intel-2.3.2, so maybe its already fixed.
Created attachment 18320 [details] screenshot with 10x10 source
I can see this behaviour with xorg-git and at least for me its a serious show-stopper. Any updates on this? I attach two screenshot who the nimbus-lnf looks on pixman and with intel-git on my 945GM.
Created attachment 19758 [details] Nimbus theme, pixman composition
Created attachment 19759 [details] Nimbus theme, intel composition
Just tried the real-world use case on an i965 and it works perfectly, so it seems to be limited to i915 and maybe below.
Also reproduceable on i830 (855GM) with git from 2008-10-30
any chance to get this fixed anytime soon?
The same bug has been fixed in the radeonhd driver, by commit: http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=645a0a0a6e5e57a4bb77c3b9c7d20b58d4c9ec28 Because the bug caused exactly the same artifact, I thought posting the link here could maybe help to find the issue easier.
Reassigning to myself since I too feel this pain, just haven't found a way to fix this and not cause text regressions. :(
the pain is still there :/
Chris: Do you think it makes sence to add this test to rendercheck?
It's covered by the cairo test suite, in particular xcomposite-projection. cairo has the advantage of using reference images and we would need to similarly teach rendercheck to compare against pixman [and add the appropriate tests to pixman itself!] as the simplest method to extend rendercheck for this style of testing. I am satisfied that I have test coverage [for this bug, but not the entirety of the RENDER spec], and that testing also shows that I have not found a way to fix centre sampling without breaking alpha sampling. That is still puzzling me.
commit dc402334f4e9b0de624bc89cd77eae4ec7cf1708 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jun 1 23:03:19 2010 +0100 i915: Centre sampling. Use centre sampling of textures to match pixman, and remove numerous off-by-one and visual artefacts when rendering. The classic example for this is cairo/text/xcomposite-projection where the edge of the rotated rectangle is jaggy due to the incorrect sample position. Fixes: Bug 16917 - [i915] Blur on y-axis also when only x-axis is scaled billiear https://bugs.freedesktop.org/show_bug.cgi?id=16917 Finally! In the end it was a simple check in the code screwing up when the format was changed to include the sample bias and nothing to do with the GPU state at all.
Thanks a lot Chris, just tested 2.11.901 and well ... its just wonderful. I owe you a beer :)
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.