Blur effect on live scene?

Jim Graham james.graham at oracle.com
Mon Aug 10 18:29:36 UTC 2015


Let me understand what is going on here.

I get the result you are trying to achieve - blur the scene as 
background for something.

I get that Mac and iOS seem to have direct support for this technique 
which appears to work faster than what we provide via the Effect mechanism.

I also get that attempts to make it appear better via snapshot will 
unfortunately involve a copy to main memory to produce the "Image" object.

If we had a "snapshot to texture" mechanism then that might reduce the 
memory copying of the work around technique.  I'd argue that we sort of 
do have something like that - it is the cache flag.  If a Node is cached 
then we do have a copy of it in a texture and that can help make the 
Blur Effect work more efficiently, but there may be some additional 
copies between textures if everything isn't set up right.  Still, that 
is an avenue for someone to check to see if there isn't a better way to 
achieve this effect in the short term...

There is the implication that one can add a shader to an overlay texture 
that will cause it to have a dynamic "blurred lens" effect.  I'm not 
familiar with how that would be done.  AFAIK, shaders work on inputs and 
produce an output which is transferred to the destination using the 
pixel transfer functions and you can't source the destination pixels in 
the shader in order to blur them.  I would imagine that the Mac/iOS 
technique is done by sourcing directly from the back buffer into the 
overlay texture using a blurring shader.  That gives the overlay texture 
a solid background that is a blurred copy of the back buffer.  They then 
draw the overlay contents (menu bar?) on top of that blurred background 
data and transfer the overlay texture back into the scene.  The blurred 
vision you are seeing is not "the pixels being blurred through the 
overlay texture" but rather a very quickly managed "blurred copy of" the 
data in the underlying buffer.  If the scene changes, then the entire 
process would need to be repeated on the new underlying pixels to get a 
new blurred copy of them as background in the overlay texture.  I can 
also imagine that they may have more direct support for blurring (there 
is an OpenGL EXT_convolution extension which we do not use - using our 
own convolution shaders instead - which may potentially work faster than 
what we do).  Also, they may be a little more efficient at managing the 
buffers involved in that dynamic operation (our Decora Effect engine 
isn't necessarily set up to use the "back buffer" as a source and so 
sometimes we may have to render parts of a scene an extra time specially 
to make an input texture for Decora).

If I'm understanding all of this correctly, then it seems that:

- it may be time to investigate tighter integration of Decora and Prism 
texture mechanisms (they use the same underlying objects, but don't have 
a good way to share pre-existing textures with each other).

- Node.cache may provide some additional short-term techniques for 
achieving this effect

- EXT_convolution may help us with performance if it is available

- if worse comes to worst, we might have to add "blurred parent" as a 
direct feature of a Node to streamline the processing of this effect, 
but hopefully we can get there with some combination of the above.

Or, if someone can enlighten me on some techniques they may be using 
that I'm not familiar with - please do!

			...jim



More information about the openjfx-dev mailing list