Add scaling support into BlurEffect::doBlur

Authored by davidedmundson on Mar 6 2017, 5:08 PM.



This patch caputres from the framebuffer using the framebuffer's
geometry, factoring in scale. We then keep the current normal DPI
framebuffer causing it to downsample there.

This is good because:

  • it keeps the code very simple
  • it's a performance optimisation. Blurring on 4k is naturally more

expensive than at regular DPI. Downsampling keeps it the same - and you
can't see a difference given it's high DPI and you're going to blur it

  • it keeps kernel sizes somewhat resolution independent so it will look

just as blurry across multiple screens.

::doCachedBlur still needs doing.

Test Plan

Ran an app
Ran the kwindowsystem blur test
Observed the right part of the window being blurred

Diff Detail

R108 KWin
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
davidedmundson created this revision.Mar 6 2017, 5:08 PM
Restricted Application added a project: Plasma. · View Herald TranscriptMar 6 2017, 5:08 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
fredrik added a subscriber: fredrik.Mar 7 2017, 5:22 PM

The blur shader is not designed to blur and scale simultaneously.

The sampled offsets are computed so that the shader samples between pixels, and the kernel weights are the sums of the gaussian function for the interpolated pixel values at each offset.

This only works when the source and destinations have the same scale.

Oh I see, rather than grabbing two texels and interpolating the average value
you're sampling between them and letting the GL return the relevant value.

My previous code would break that as I was effectively sampling between every other pixel,
rather than actually interpolating properly. Output looks OK, but technically wrong.

I still think the overall concept of downsampling high DPI buffers is the simplest, which gives two options:

  • we grab the scratch at native resoltion, then explicitly make a second scratch texture at half the size which

we render the first texture into.

  • we blit the framebuffer as that allows us to do the transformation all in the same pass.

GLRenderTarget::blit already has all the transformation code so it keeps the code super simple.

This patch does the latter.

It's faster than the extra pass, but has the obvious downside that not all hardware supports blitting, but
realistically any hardware that supports 4k output will.
The screenshot effect already relies on blit being supported, so I think it should be safe.

This revision was automatically updated to reflect the committed changes.