Closed Adolio closed 6 years ago
Wow — interesting! I'll look into it.
That should now be fixed!
The problem was that the BlurFilter doesn't work well with the resolution property in general. The issue you reported could e.g. even be reproduced without a RenderTexture with this simple code:
quad.filter = new BlurFilter(1, 1, 0.25);
quad.filter.alwaysDrawToBackBuffer = true;
What happens is that the filter, as part of an optimization process, draws directly to the back buffer in the final pass. That means, though, that the resolution of the input texture (0.25
) doesn't match the resolution it is rendered to (1.0
). And the blur algorithm doesn't like that at all! :wink:
The solution is to avoid that "optimization" when the resolution is not 1.0
.
Memo to myself: I also need to look at DropShadow- and GlowFilter. They support a resolution
parameter, but that leads to similar problems. It's just not as easily visible, since the blurred area is tinted in a single color.
I confirm that this is now fixed for the BlurFilter
. 😃 Nice catch!
Thanks for the quick reaction & the explanations @PrimaryFeather!
You're welcome, Aurélien! Thanks for trying it out! :smile:
Introduction
When playing around with
BlurFilter
resolution, I noticed a rendering quality difference from normal rendering versus usingRenderTexture
.Context
This has been tested on
AIR 26
withStarling master branch
&Starling v2.2
.How to reproduce?
Here is a sample code to reproduce: StarlingMain.as.txt
Results
The following images show the quality artefacts (with resolution of
0.25
):Normal rendering
Rendering through RenderTexture