Closed ghost closed 3 years ago
The OS support determines which factories are supported, and having 5 but not 4 would be a very weird case, so it's reasonable to assume that wouldn't happen.
I've kept the feature tests independent to keep the DeviceResources code simple and easy to cut & paste from. Since these extra QIs only happen at device creation, they shouldn't pose any performance problem. It also keeps the implementation of the debug info messages simple.
You could optimize them by having them clear related flags early if a failed QI implies it couldn't be supported, but three QIs in a row here isn't going to take any noticeable time compared to one.
In DeviceResources::CreateDeviceResources you check a number of feature flags related to tearing and HDR. I have a question about the order of these checks - Is it possible for a device to fail to cast to factory4, but succeed in casting to factory5? That is, I'm putting these three checks into a function and I'm wondering if it's even necessary to check factory5 and factory5/allowTearing if you fail to cast to factory4. I've already put a return into the check for c_EnableHDR, if you FAIL on the cast to factory5 here, there's no reason to try to cast to factory5 for the c_AllowTearing check.