Allow user to change Android Blit Type?

In my graphics/performance options, I’d like to offer my users the ability to toggle the blit type between Always/Auto/Never. I’m using 2020.2.0a15.

The performance of Never is amazing, but I realize leaving it set to this will mean compatibility issues… and thinking of offering a separate build just for the blit type makes me wonder if I’m missing something. Is what I’d like to do possible (leaving compatibility vs. performance to the user where the blit type is concerned)? Thanks

Does ‘Auto’ not work for you? It should give you the performance of ‘Never’ when possible.

Could we have a bit more information on how Auto decides if there’ll be a blit or not?

Yes, Auto works - my app functions as though Never were selected (on the Android device I’m testing with). However, I was wondering if there’s a way for the user to set the mode explicitly because I’ve had an issue with Always where the rendered world behind the UI gets stretched at orientation change, like it knows the device rotated but it doesn’t know the resolution changed (i.e. from 1920x1080 to 1080x1920). This issue only happens with Always and only on Android. I have found a way to get it back to normal - I can momentarily make the camera use a RenderTexture and then set it back to none and it’s fine again in the new orientation, but this requires knowing which blit type is currently being used/selected by Auto (is that possible?) or I’d always have to apply the workaround regardless of whether it’s actually needed.

Edit: The device this happens on with Always is an S5 with Android 6.0.1 (I don’t have another device to try on at the moment). I’m using URP 8.1.0, the pipeline asset has Depth texture disabled, Opaque texture disabled, MSAA disabled, render scale 1. Color space is Gamma, has the Graphics APIs of OpenGLES2 followed by Vulkan. scripting backend IL2CPP, API compatibility .NET Standard 2.0, Release configuration, target architecture is ARMv7. Minimum API Android 4.4, Target API is Automatic/highest installed. Resolution Scaling Mode is disabled, Render outside safe area is enabled. I’ve also had issues with Never where using a RenderTexture that’s not the same resolution of the screen, where there are clusters of black lines across the image - the spacing of the lines and thickness change based on the bit depth used in the RenderTexture (much thicker with 16 vs 24) and the exact resolution. I have seen suggestions related to this re camera clear and making sure it’s a solid color or skybox (which is it). Anyway this is off-topic now but I’m willing to provide examples / file bug reports if it’s helpful …I really just wondered if there’s a way to let the user troubleshoot this kind of thing with settings.

It’s possible this is related to the version of URP I’m using because prior to 8.1.0 I don’t believe I noticed anything like this - but I also wasn’t at the point where I was actively looking for anything I might have missed on platforms aside from WebGL.

‘Auto’ is same as ‘Always’ in the following cases:

  • Linear color space but device doesn’t support EGL_KHR_gl_colorspace (or known buggy Android versions)
  • MSAA changed at runtime and device doesn’t support EGL_KHR_no_config_context
  • The set backbuffer resolution is not applied correctly (usually only happens on some old devices)
1 Like

@adamgolden At the moment we don’t have a runtime switch for the ‘Blit Type’.

The issue that you are describing on the Galaxy S5 sounds like a major problem (basically auto rotation being broken). It would be great if you could report a bug with small repro project for this so that our QA can check this.

The behavior of blit type with URP changed a few times, but as far as I know this was mostly about linear/sRGB issues.

[USER=3279967]
Okay - I will create something minimal with the URP template in 2020.2.0a15 and attempt to reproduce what I’ve explained. I’ve been upgrading my own project through almost every 2020.2 alpha and have changed URP version at least 3 times, so it’s also possible that something has just come undone over time. Either way I’ll follow up here when I have more to say. Thanks for the quick response.[/user]

Thank you. Sounds reasonable.

I have been able to reproduce the first issue described above (with blit type Always) using the URP template. As noted, this is an S5 and I’m using 2020.2.0a15, URP 8.1.0.

Description: Orientation change while Android Blit Type is Always and Multithreaded Rendering is disabled causes the output to be stretched inappropriately. A portrait render is stretched to fit landscape, and a landscape render is stretched to fit portrait, after .targetTexture has been set to null once, on every subsequent orientation change.

Steps To Reproduce:

  1. Create a new URP template project
  2. Change platform to Android
  3. Change Blit Type to “Always”
  4. Uncheck “Multithreaded Rendering”
  5. Create a new GameObject
  6. Add this class:
    using UnityEngine;
    public class BlitTypeAlwaysBreaker : MonoBehaviour
    {
    void Start()
    {
    Camera.main.targetTexture = null;
    }
    }
  7. Build And Run

It is possible to correct this after an orientation change by changing camera output to a RenderTexture momentarily then changing back to null - but the problem persists when orientation changes again.

I have also been able to reproduce this issue with the standard emptyish 3D project (i.e. non-URP). The Blit Type was already set to Always by default:

  1. Create new 3D project
  2. Change platform to Android
  3. Uncheck “Multithreaded Rendering”
  4. Add a Sphere to the scene (or whatever to look at)
  5. Add the above BlitTypeAlwaysBreaker class to it
  6. Set “Main Camera” Z position to -1 (so the sphere will be visible)
  7. Build And Run

After the app loads, rotate the device any number of times to see the issue.

I’m not sure if this qualifies as a bug - maybe I should just be using an additional camera whenever I want the scene rendered to a texture, then I’d never have to touch .targetTexture of the main camera? According to the documentation as I understand it though, I should be able to just reuse the same camera and set .targetTexture back to null (which does work with other platforms and with blit type Never)… but maybe this isn’t typical / too much of an edge case to spend time on, especially if just using an additional camera is a solution. I’ll have to try that approach and see if it resolves the issue. Either way, exploring this further today has led to the possibility of a clean workaround and if it pans out I’ll make the switch to Auto and just forget about the original question re allowing user to toggle blit type :smile: