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?


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

(Image source: Wikipedia)

*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.

  • $\begingroup$ 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) $\endgroup$
    – RichieSams
    Commented Aug 10, 2015 at 19:44
  • $\begingroup$ @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. $\endgroup$
    – Nero
    Commented Aug 10, 2015 at 20:07
  • $\begingroup$ @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. $\endgroup$
    – yuriks
    Commented Aug 10, 2015 at 20:22
  • $\begingroup$ @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. $\endgroup$ Commented Aug 13, 2015 at 10:58

2 Answers 2


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 iOS notification center

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, 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 that your blur requires.

  • 1
    $\begingroup$ 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! $\endgroup$
    – Nero
    Commented Aug 11, 2015 at 6:40
  • 1
    $\begingroup$ @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. $\endgroup$ Commented Aug 11, 2015 at 14:30

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.)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.