This makes it so that the PixelBufferDescriptor callback triggers at a
time consistent with other backends.
ReadPixels is still asynchronous in the sense that the callback is
triggered on the main thread. However, it is now guaranteed to trigger
during (or before) flushAndWait(), which is less surprising behavior.
You can now build Filament with support for both X11 APIs, or neither.
If both are supported, run-time selection is achieved using a SwapChain
flag.
Supporting only one API at build time (or neither) is useful because our
list of "required" VkInstance extensions can vary according to which
API's are supported. During VkInstance creation, we do not have a priori
knowledge about what kinds of swap chains will be created. (headless vs
non-headless, XCB vs XLIB, etc)
Note that some Vulkan implementation (e.g. some builds of SwiftShader)
only support XCB.
This avoids the following validation error when clients create then
immediately destroy vertex buffers, index buffers, and uniform buffers.
VUID-vkDestroyBuffer-buffer-00922
Cannot free VkBuffer that is in use by a command buffer.
Buffers that are used across multiple frames were fine, but
create-and-destroy scenarios were problematic.
This fixes a regression introduced by 548b28c6e manifesting as
intermittent assertions. The VulkanDisposer gc() should only be called
from the driver thread.
This change fixes an issue where ImGuiHelper would crash on destruction if you created more than one instance at the same time.
This crash occurred when ImGui::DestroyContext() was called, because when the second instance was destroyed there was no current context causing it to crash.
This fixes it by making ImGuiHelper store and manage it's own context.
Having two instances of ImGuiHelper is useful in cases where you want to use imgui with multiple views.
This adds support for more format conversions and removes a bogus
assert that prevented ReadPixels within beginFrame / endFrame.
This was tested with:
backend_test_mac --api vulkan --gtest_filter=BackendTest.ReadPixels
This adds a Dockerfile and a new bash script that makes it
east to invoke the appopriate Docker commands.
This does not yet enable a GitHub Action because of intermittent
issues that we have not yet ironed out.
This allows clients to build the Vulkan backend with either XLIB or XCB
support. I did a quick smoke test of the XCB option, but for now we are
continuing to default to XLIB. Note that the native window type used to
create the swap chain differs between these two API's.
The non-const getSkybox() method is especially useful to client code
that needs to change the clear color, but does not have direct
access to the Renderer object.
If hardware_concurrency() returned 2 while UTILS_HAS_HYPER_THREADING was
enabled, `mThreadCount` was resulting in zero, so jobs (such as texture
decoding) would simply never start. This problem was noticed with
GitHub Actions.
I tested this fix locally by replacing `hardware_concurrency()` with
fixed values like 1 or 2, and verified that the hang went away.
