Posting any message to parent seems to be pointless. That might break
parent window.
Regardless of the posting, parent window can catch mouse event
and also any keyboard events will be handled by parent window by default.
It's currently the only sane way we can use MoltenVK functions to
integrate with Metal API.
It also removes the need to specify the VK_ICD_FILENAMES environment
variable pointing to MoltenVK_icd.json.
Includes a new GstVulkanHandlePool base class for pooling different
resources togther. The descriptor cache object is ported to
GstVulkanHandlePool with the exact same functionality.
A new GstVulkanFenceCache is also implemented for caching fences
which is used internally by GstVulkanDevice for creating or reusing
fences.
The existing GstVulkanTrashFenceList object now caches trash objects.
Part 1 is a base class (vkvideofilter) that handles instance, device,
queue retrieval and holding that has been moved to the library
Part 2 is a fullscreenrenderquad that is still in the plugin that
performs all of the previous vulkan-specific functionality.
Weak refs don't quite work here correctly as there is always a race with
taking the lock between find_view() and remove_view(). If find_view()
returns a view that is going to removed by remove_view() then we have an
interesting situation.
In theory, the number and type of views for an image are relatively
constant and should not change one they've been set up which means that
it is actually practical to perform pool-like reference counting here
where the image holds a pool of different views that it can give out
as necessary.
The major functionality gain this provides is proper reference counting
for a descriptor set. Overall this allows us to create descriptor sets
when they are needed (or reused from a cache) without violating any of
vulkan's object synchronisation requirements.
As there are a fixed number of sets available in a pool, the number of
descriptors in elements is currently hardcoded to 32. This can be extended
in a future change to create pools on the fly if that limit is ever overrun.
Allows a cleaner control flow when there is no fence available for use
with the trash list. An always signalled fence type will always return
TRUE for gst_vulkan_fence_is_signalled.
Serve two purposes:
1. refcounting of vulkan handles with associated destruction. When
combined with the trash list, the user can ensure destruction at
the correct time according to the vulkan rules.
2. avoids polluting our API with 32-bit vs 64-bit integer/pointers
differences as exposed through the vulkan API. on 32-bit, vulkan
non-dispatchable handles are 64-bit integers and on 64-bit, they
are pointers.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
* Fix meson build script for Windows. Since the Vulkan dependency
object was declared by us in case of Windows, the dependency object
shouldn't be used for finding header
* Fix build error by including Windows specific header
gstvkdisplay.c(563): error C2065: 'VK_KHR_WIN32_SURFACE_EXTENSION_NAME': undeclared identifier
