The common case this branch aims to deal with is when the detected order is "unknown" and the user must choose one (and usually HRGB will be a good guess).
We will need this branch only if the shell chooses to store the display config as a blob, so this setter would be required. If the shell goes to the trouble of translating the display config to its own storage format (with potential overrides) then yes this branch would not be required.
But there's another lesser use case of this branch, which is for shells (demo servers) that don't remember their configurations. For our demo servers, having a setter like this is the only way to avoid forcing the override and custom configuration logic into the toolkits (which is then an O(N) problem as opposed to an O(1) problem with this branch).
So to me this branch is useful right now. I understand it may prove to not be useful to Unity8, but it also doesn't hurt anyone to have this flexibility.
The common case this branch aims to deal with is when the detected order is "unknown" and the user must choose one (and usually HRGB will be a good guess).
We will need this branch only if the shell chooses to store the display config as a blob, so this setter would be required. If the shell goes to the trouble of translating the display config to its own storage format (with potential overrides) then yes this branch would not be required.
But there's another lesser use case of this branch, which is for shells (demo servers) that don't remember their configurations. For our demo servers, having a setter like this is the only way to avoid forcing the override and custom configuration logic into the toolkits (which is then an O(N) problem as opposed to an O(1) problem with this branch).
So to me this branch is useful right now. I understand it may prove to not be useful to Unity8, but it also doesn't hurt anyone to have this flexibility.