<p>There's no way around it. If you want the area behind the textboxes to appear blurry... you're gonna have to blur it.</p>

<p>One way to mitigate the performance cost is to be sure to use a 2-pass separable blur.</p>

<p>Another measure that will probably help (depending on how much of the screen your textboxes cover) is to use scissoring or a stencil test to only compute the blur in the areas of the screen that will later be covered by textboxes. If you do this, be sure to leave an extra vertical padding of at least half the width of your blur kernel, otherwise, the second blurring pass will try to sample uncomputed texels in the intermediate texture, leading to artifacts or darkening of the blur near the edges of the textbox areas. (This isn't an issue for the first pass since you'll be sampling from the original unmasked texture there.)</p>

CC BY-SA 3.0
2015-08-10T20:30:20.923Z
2015-08-10T20:30:20.923Z
yuriks
<p>I think you may want to take another look at the iOS user interface if you consider real-time blurs to be out of range of mobile hardware:</p>

<p><a href="https://i.sstatic.net/dRT54.png" rel="noreferrer"><img src="https://i.sstatic.net/dRT54.png" alt="iOS control center"></a>
<a href="https://i.sstatic.net/Dt2Sg.png" rel="noreferrer"><img src="https://i.sstatic.net/Dt2Sg.png" alt="iOS notification center"></a></p>

<p>Blurs are totally in range of mobile hardware. Yes, you need a fairly large number of texture samples for a blur with a large kernel, but the texture samples are also cached very well, and you can use a <a href="https://en.wikipedia.org/wiki/Separable_filter" rel="noreferrer">separable blur</a>, which effectively means that an MxN blur requires M + N samples, not M * N samples. You can also take advantage of hardware bilinear sampling to <a href="http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/" rel="noreferrer">reduce the number of samples</a> that your blur requires.</p>

CC BY-SA 3.0
2015-08-11T06:40:26.967Z
I know about the Notification Center and Control Center. But I doubt that these blurs are calculated in real time as the active app is frozen while one of them is shown (or at least it does not update the UI anymore). But the links look promising. Thanks!
Nero
CC BY-SA 3.0
2015-08-11T14:30:37.093Z
@Nero I suspect that's mostly for power reasons. When you swipe down from the Springboard to get to Spotlight, you get a variable-width blur depending on how far you've pulled down, and that's certainly real-time.
John Calsbeek
CC BY-SA 3.0
2015-08-11T05:07:01.950Z
2015-08-11T05:07:01.950Z
John Calsbeek
<p>While rendering my scene with OpenGL, I sometimes add an overlay which contains information, settings and a few draggable items. Currently, the overlay has a slightly transparent background to make text easily readable while still allowing the scene to shine through and to let the user see the scene behind/through the overlay.</p>

<p>I would like to replace the transparent background with a translucent background, which (as far as I know) requires the clear image of the scene to be heavily blurred*. And especially on mobile devices (e.g. iPad) with high resolutions and limited processing power, lots of texture lookups and real-time rendering don't work well together.</p>

<p>Is there a way to make real-time translucency feasible on mobile devices like the iPad? Or is there a way to avoid the need to heavily blur the scene in every frame?</p>

<p>Edit:</p>

<p>As suggested in the comments, here is an image I just found in the Wikipedia that describes the difference between transparency (right column) and translucency (middle column). </p>

<p><a href="https://i.sstatic.net/iKXOo.png" rel="noreferrer"><img src="https://i.sstatic.net/iKXOo.png" alt="Opacity, translucency and transparency"></a></p>

<p>(Image source: <a href="https://commons.wikimedia.org/wiki/File:Opacity_Translucency_Transparency.svg" rel="noreferrer">Wikipedia</a>)</p>

<hr />

<p><sup>*I know there is the two-pass blur (first blur in one and then in the other direction) to reduce texture lookups. But for translucency this still requires quite a large number of texture lookups.</sup></p>

CC BY-SA 3.0
2015-08-10T19:44:53.450Z
I'm not sure I'm understanding you. Slightly transparent == translucent. So you're already using translucency. Could you clarify what you're trying to do? Fully transparent background? (Aka, clear/invisible) Or translucent background? (Aka, you can see some stuff behind it, but covered with the background color)
RichieSams
CC BY-SA 3.0
2015-08-10T20:07:21.307Z
@RichieSams Currently I use a simple black background with an applied alpha transparency. So the scene can be seen, but is still sharp, which distracts the readability of the text. Thus I would like to change the simple alpha transparency to translucency. A real-world example maybe is the difference between looking through colored respectively iced glass.
Nero
CC BY-SA 3.0
2015-08-10T20:22:07.777Z
@Nero In graphics, "translucent" doesn't usually imply "frosted" or "iced", so I suggest making what your looking for clearer in your question, since I was also quite confused by it.
yuriks
CC BY-SA 3.0
2015-08-13T10:58:40.523Z
@yuriks `translucent: (of a substance) allowing light, but not detailed shapes, to pass through`. Translucent generally has the meaning used in the question, so this seems clear.
trichoplax is on Codidact now
<opengl><real-time><mobile>
Real-time translucency effect
Nero
# Real-time translucency effect

(Asked by: username_0 on 2015-08-10)

While rendering my scene with OpenGL, I sometimes add an overlay which contains information, settings and a few draggable items. Currently, the overlay has a slightly transparent background to make text easily readable while still allowing the scene to shine through and to let the user see the scene behind/through the overlay.

I would like to replace the transparent background with a translucent background, which (as far as I know) requires the clear image of the scene to be heavily blurred\*. And especially on mobile devices (e.g. iPad) with high resolutions and limited processing power, lots of texture lookups and real-time rendering don't work well together.

Is there a way to make real-time translucency feasible on mobile devices like the iPad? Or is there a way to avoid the need to heavily blur the scene in every frame?

Edit:

As suggested in the comments, here is an image I just found in the Wikipedia that describes the difference between transparency (right column) and translucency (middle column).

[![Opacity, translucency and transparency](https://i.sstatic.net/iKXOo.png)](https://i.sstatic.net/iKXOo.png)

(Image source: [Wikipedia](https://commons.wikimedia.org/wiki/File:Opacity_Translucency_Transparency.svg))

---

\*I know there is the two-pass blur (first blur in one and then in the other direction) to reduce texture lookups. But for translucency this still requires quite a large number of texture lookups.

**Tags:** opengl, real-time, mobile

> **Comments:**
> **username_1**: I'm not sure I'm understanding you. Slightly transparent == translucent. So you're already using translucency. Could you clarify what you're trying to do? Fully transparent background? (Aka, clear/invisible) Or translucent background? (Aka, you can see some stuff behind it, but covered with the background color)  
> **username_0**: @username_1 Currently I use a simple black background with an applied alpha transparency. So the scene can be seen, but is still sharp, which distracts the readability of the text. Thus I would like to change the simple alpha transparency to translucency. A real-world example maybe is the difference between looking through colored respectively iced glass.  
> **username_2**: @username_0 In graphics, "translucent" doesn't usually imply "frosted" or "iced", so I suggest making what your looking for clearer in your question, since I was also quite confused by it.  
> **username_3**: @username_2 `translucent: (of a substance) allowing light, but not detailed shapes, to pass through`. Translucent generally has the meaning used in the question, so this seems clear.  

---

## 2 answers

### Answer by username_4 on 2015-08-11. Score: 6 | Accepted answer

I think you may want to take another look at the iOS user interface if you consider real-time blurs to be out of range of mobile hardware:

[![iOS control center](https://i.sstatic.net/dRT54.png)](https://i.sstatic.net/dRT54.png)
[![iOS notification center](https://i.sstatic.net/Dt2Sg.png)](https://i.sstatic.net/Dt2Sg.png)

Blurs are totally in range of mobile hardware. Yes, you need a fairly large number of texture samples for a blur with a large kernel, but the texture samples are also cached very well, and you can use a [separable blur](https://en.wikipedia.org/wiki/Separable_filter), which effectively means that an MxN blur requires M + N samples, not M \* N samples. You can also take advantage of hardware bilinear sampling to [reduce the number of samples](http://rastergrid.com/blog/2010/09/efficient-gaussian-blur-with-linear-sampling/) that your blur requires.

> **Comments:**
> **username_0**: I know about the Notification Center and Control Center. But I doubt that these blurs are calculated in real time as the active app is frozen while one of them is shown (or at least it does not update the UI anymore). But the links look promising. Thanks!  
> **username_4**: @username_0 I suspect that's mostly for power reasons. When you swipe down from the Springboard to get to Spotlight, you get a variable-width blur depending on how far you've pulled down, and that's certainly real-time.  

---

### Answer by username_2 on 2015-08-10. Score: 4

There's no way around it. If you want the area behind the textboxes to appear blurry... you're gonna have to blur it.

One way to mitigate the performance cost is to be sure to use a 2-pass separable blur.

Another measure that will probably help (depending on how much of the screen your textboxes cover) is to use scissoring or a stencil test to only compute the blur in the areas of the screen that will later be covered by textboxes. If you do this, be sure to leave an extra vertical padding of at least half the width of your blur kernel, otherwise, the second blurring pass will try to sample uncomputed texels in the intermediate texture, leading to artifacts or darkening of the blur near the edges of the textbox areas. (This isn't an issue for the first pass since you'll be sampling from the original unmasked texture there.)


---

