Bug 16917

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 :)