Off-by-one(?) Dash blur appears to shift Desktop down and right

[Paul Sladen]

When toggling between the Dash blurred and the desktop, the contents off the desktop appear to shift 1-2 pixels down and to the right, which is subtle but slightly disturbing.

Ideally the filter/shader should work around the current pixels.

This is probably an off-by-1, or an off-by-0.5 type issue in the shader.

[Paul Sladen (sladen)]

Split screen of with and without blur.

Appears to be a ~2px apparently shift in both X and Y.

[Paul Sladen (sladen)]

For reference, this is a 2007-era ThinkPad X61 Tablet. lspci -vvn gives:

  Mobile GM965/GL960 Integrated Graphics Controller

The BackgroundEffectHelper::GetBlurRegion() appears to have two separate code paths, one of which only does the blur at 1/4 size (1/16 of the number of pixels).

My hunch is that the GetCopyTexture() might be lacking a -0.5,-0.5 offset to sample from the centre of the pixel, and that this error is then amplified by down_size_factor = 4.

(Of course, this might be barking up the wrong tree; Jay's guess is in the noise code, but I don't think Jay could see it, and this might fit wit the two codepaths).

[Paul Sladen (sladen)]

$ /usr/lib/nux/unity_support_test -p
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GM x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 7.11

Not software rendered: yes
Not blacklisted: yes
GLX fbconfig: yes
GLX texture from pixmap: yes
GL npot or rect textures: yes
GL vertex program: yes
GL fragment program: yes
GL vertex buffer object: yes
GL framebuffer object: yes
GL version is 1.4+: yes

Unity 3D supported: yes

[Daniel van Vugt (vanvugt)]

This kind of 1-2 pixel shift will always happen with an in-place blurring algorithm that uses the same buffer for its input as output. It's a side-effect of the blur shader/algorithm working top-to-bottom and left-to-right. It's normal and probably not worth fixing because that would require double the memory and more CPU time.