Macos software renderer wrong `depth_size` reported?
alexheretic opened this issue · 8 comments
My config selection logic is not working on macos. I expect depth=24, stencil=8, however in my macos vm (software renderer) I see depth size as 32, which seems wrong.
// macos vm the only Config
config.depth_size() = 32
config.stencil_size() = 8
Can you tell me if this something that can be fixed in glutin or shall I work around it?
We get the values from the macOS itself and the config you request is a suggestion, and macos basically replies based on that suggestion.
It decided that you don't have a config with the depth 24, while you could try manually playing with glutin config requests and see whether it's possible to get something different, I'm not sure we can do anything to prevent it, because of how macOS works and that it exposes only a single config at a time, so you basically try to create them until it kind of works...
Maybe there's a better way to deal with that which and I'm just not familiar with it.
There is only one Config to use in this environment :(. I shall work around it then, thanks for the quick response!
I mean, maybe there're more, we can't get more than one at the time no macOS because that's how macOS works....
Re requesting 32 in the config and getting a config with 24, ""shouldn't"" it error that no compatible config is found?
A similar thing happened on Android; I have a native window/surface with RGB565, no alpha. Put that in the EGL ColorBufferType::Rgb{} config, but it still returns all configs, including 8-bit and 10-bit formats :(
(Filtering does work when specifying one of the 10-bit or 8-bit formats...)
The way config matching works is that it sorts + filters config based on what you passed (if you read the EGL/GLX/WGL) spec.
I intentionally decided that we should just do what spec is doing and it's documented that it gives you at least. Maybe we should have an option for matcher to alter the behavior, but I don't think that starting to filter is a good idea without adding option.
and it's documented that it gives you at least
Ah you are right, for some attributes it gives you configs that are equal or higher (at least on EGL). Not sure how the sorting works, for RGB set to 8 and depth set to 0 I get the 10-bit configs first followed by 8-bit configs, but when setting RGB to 0 too I get 565 and 444 RGB formats before some 888 and 101010 formats intertwined
Not saying that we should change glutin for this, letting the user filter is fine, though we might provide Ord helpers in some places to make it more trivial?
Not saying that we should change glutin for this, letting the user filter is fine, though we might provide Ord helpers in some places to make it more trivial?
Geneeral Ord could be opinionated, but for individual types it's probably fine. Though, I'm not sure how you'd sort e.g. rgb components, by sum? There's also luminance, etc.
Exactly, RGB is nontrivial though it could be implemented with PartialOrd (i.e. return None when comparing Rgb to Luminance, or if there is an unlikely case where one component is higher and the other is lower. Most formats are 444, 555, 565, 888 or 101010 though).