| 16 Apr 2024 |
|  jp_2002_ | 21:05:07 |
| 17 Apr 2024 |
|  austn8r joined the room. | 01:50:55 |
|  eyeseepie joined the room. | 17:23:49 |
| 18 Apr 2024 |
|  beals joined the room. | 04:17:42 |
 kaymk11 | In xrDestroyInstance, it says if an instance is destroyed then all handles that are children of this instance are also destroyed.
Are swapchains considered children of XrInstance? | 07:25:19 |
 bornecrantz | Yes via the XrSession. So XrInstance -> XrSession -> XrSwapchain. | 16:17:27 |
 haagch | usually when a function call creates an object (something that is used as a handle), the first parameter in that function is going to be the parent | 16:18:57 |
| haagch | I wish the openxr spec made that more explicit | 16:19:16 |
| 19 Apr 2024 |
|  pirafier joined the room. | 07:48:45 |
|  ghj1214kr joined the room. | 15:29:28 |
|  hhsyskids joined the room. | 16:02:28 |
| 20 Apr 2024 |
|  anna_devminer joined the room. | 10:50:47 |
|  supreme__ changed their profile picture. | 15:26:23 |
|  ninja_ron1n joined the room. | 19:32:44 |
|  noisersup joined the room. | 20:37:09 |
|  cklance6443 joined the room. | 20:46:19 |
|  kekspls joined the room. | 21:01:41 |
|  6ax3dc changed their profile picture. | 21:24:37 |
| 22 Apr 2024 |
|  ali1379 joined the room. | 08:30:26 |
 vrtesterman | Until we have an openxr runtime loader/broker setup, where an OpenXR app or game, can run two independent VR headsets on the same PC at the same time, I don't see the point in this design for multiple xr sessions, or even swap chains. Can anyone tell me of a valid use case for this? One that actually works? IMO XrInstance and XrSession could be merged into one. Maybe I'm missing something. This reeks of over-engineering IMO. | 11:40:32 |
| vrtesterman | I can't even tell if there's a way to specify, in code at runtime, which loader you want to use on PC. On Android you override the loader.so file for a specific one. I'd much prefer having access to a list of available loaders in my app, and pick the one that suits my needs the best. Ex if AirLink is used, and SteamVR is running on top of it, the app developer should be able to pick which OpenXR runtime to use, Oculus or SteamVR, not using the value specified in the system. Why? Because end users most often don't know what they're doing, or the tradeoffs involved. Ex AirLink supports way more OpenXR extensions than SteamVR, but only if you have developer mode enabled. PC is a mess but OpenXR framework doesn't really have fixes for some of these problems, indeed it seems to be making things worse and an even bigger headache for developers. | 11:43:42 |
| bornecrantz | You need multiple swapchains, for color and depth. | 12:10:48 |
| vrtesterman | Redacted or Malformed Event | 12:52:19 |
| vrtesterman | Redacted or Malformed Event | 12:56:00 |
 korejan | i don't understand what you mean about choosing between multiple loaders, on desktop OSes there only needs to be a single loader per OS. It's suppose to be like this with Android but a standardized loader wasn't defined until later on after some vendors made a vendor specific ones but there are only a couple of those and they slowly going away.
Apps can choose statically link a version of the loader but it shouldn't matter either way. I think what mean is users having to set the active runtime for the loader | 13:00:58 |
| korejan | * i don't understand what you mean about choosing between multiple loaders, on desktop OSes there only needs to be a single loader per OS. It's suppose to be like this with Android but a standardized loader wasn't defined until later on after some vendors made vendor specific ones but there are only a couple of those and they slowly going away.
Apps can choose statically link a version of the loader but it shouldn't matter either way. I think what mean is users having to set the active runtime for the loader | 13:01:20 |
| korejan | * i don't understand what you mean about choosing between multiple loaders, on desktop OSes there only needs to be a single loader per OS. It's suppose to be like this with Android but a standardized loader wasn't defined until later on after some vendors made vendor specific ones but there are only a couple of those and they slowly going away.
Apps can choose to statically link a version of the loader but it shouldn't matter either way. I think what mean is users having to set the active runtime for the loader | 13:01:33 |
| korejan | * i don't understand what you mean about choosing between multiple loaders, on desktop OSes there only needs to be a single loader per OS. It's suppose to be like this with Android but a standardized loader wasn't defined until later on after some vendors made vendor specific ones but there are only a few of those and they're slowly going away.
Apps can choose to statically link a version of the loader but it shouldn't matter either way. I think what mean is users having to set the active runtime for the loader | 13:02:18 |
| korejan | * i don't understand what you mean about choosing between multiple loaders, on desktop OSes there only needs to be a single loader per OS. It's suppose to be like this with Android but a standardized loader wasn't defined until later on after some vendors made vendor specific ones but there are only a few of those and they're slowly going away.
Apps can choose to statically link a version of the loader but it shouldn't matter either way. I think what you mean is users having to set the active runtime for the loader | 13:03:58 |
| korejan | The android broker is basically an appified active runtime selector for non-system provided android runtimes or android systems with multiple runtimes that a user might want to switch between but that is very uncommon | 13:06:19 |
