Various updates of Avalonia.Vulkan and SilkNetDemo projects #9885
Conversation
…n VulkanPlatformGraphics.TryCreate (VulkanDevice is created later from VulkanPlatformGraphics.CreateContext)
…vent rendering too small texture and then scaling it up
…Vulkan resources when the control is hidden (for example in TabControl)
…property dispose the control when the window is unloaded
…sed to wait in BeginRecording until the previous operation has finished. Also there should not be an option to use another Fence in Submit because this could leave _fence in unsignalled state and could wait forever (for example in WaitForFences that is called Dispose method)
| @@ -15,13 +15,18 @@ | |||
|
|
|||
| namespace Avalonia.Vulkan; | |||
|
|
|||
| public abstract class VulkanControlBase : Control | |||
| public abstract class VulkanControlBase : Control, IDisposable | |||
There was a problem hiding this comment.
I'm not quite sure that making a control to be disposable is a good idea. Any cleanup logic should happen in OnDetachedFromVisualTree
There was a problem hiding this comment.
OnDetachedFromVisualTree is also called when VulkanControlBase is inside a TabControl and when user changes Tabs. Also, if user decides to move the control from one parent to another, this should not dispose all Vulkan resources. Ok, the VulkanBitmapChain that is used by the VulkanControlBase could be disposed in OnDetachedFromVisualTree. But calling OnVulkanDeInit is too "heavy" - if user would be showing a complex 3D scene we should not dispose all Vulkan resources because the control was hidden or moved. The user of VulkanControlBase should be aware that this control creates a lot of unmanaged resources and that it is his responsibility to clear that (for example, when the MainWindow is closed - as in the updated SilkNetDemo). When using only a single VulkanControlBase, then there is actually no need to clean anything because the OS will clean all resources; but when using multiple VulkanControlBase objects, user will need to manually dispose the resources when he knows they will no longer be used.
There was a problem hiding this comment.
VulkanControlBase is responsible for managing a swapchain and associated resources. When it's detached the swapchain becomes invalid and any associated resources like framebuffers should be disposed as well.
I'm currently working on something like SwapChainPanel and generic non-primary context creation APIs that would allow to manually manage resources that are shared between different vulkan-powered controls.
There was a problem hiding this comment.
Ok, I will remove the IDisposable from VulkanControlBase and will update the code so that in OnDetachedFromVisualTree the resources created by the VulkanControlBase will be disposed: VulkanBitmapChain and VulkanCommandBufferPool. But I would not call OnVulkanDeInit because OnDetachedFromVisualTree does not mean that all Vulkan resources should be disposed (actually I think OnVulkanDeInit should be removed because the VulkanControlBase cannot know when the Vulkan resources should be disposed). I would preserve the manual disposal of the Vulkan resource that are created in the VulkanDemoControl (they are disposed when the MainWindow is Unloaded). Is this ok?
There was a problem hiding this comment.
It still needs to inform the user code that swapchain images are no longer valid and that corresponding framebuffers should be removed.
There was a problem hiding this comment.
Yes ok, I will update the PR with that.
There was a problem hiding this comment.
#9925 - see external memory interop spec.
…ges and frame buffers when control is detached. Renamed OnVulkanDeInit to OnSwapchainDisposing. Adding TabControl to VulkanDemo.axaml to test removing and adding the control to visual tree.
…ed between calling StartPresentation and EndPresentation
|
Closing this PR temporarily due to inactivity. Please ping me if this needs to be reopened. |
The PR improves using VulkanControlBase. See comments in the commits for more information.