This fixes the visual hang that would occur after going to the task
switcher and back.
After recreating the swap chain, all of its associated fences and sync
objects become invalid. Since we were not tracking this, FrameSkipper
was going into an infinite wait after the swap chain was created.
This removes the old getClientExtent stuff that I added a while back,
and replaces it with the strategy espoused by the MoltenVK author found
here:
https://github.com/KhronosGroup/MoltenVK/issues/428
I tested this PR on macOS with Vulkan and Metal. I tested both on high
and low DPI displays. I also tried dragging the window between the two
displays.
Android still has issues with rotation, I will deal with that next.
cleanup
This fixes a lot of flickering when SSAO and TAA are enabled.
SSAO TAA shouldn't be done based on a jittered depth buffer, but
rather on jittered samples.
while this started as a sample to demonstrate how to use the new
frame history feature, this is now solid enough to become a feature.
this version of TAA doesn't use motion vectors, so it is prone to
various artifacts (e.g. ghosting). It also has the typical issues
TAA has (e.g. transparents).
with that said, performace is good and quality is overall superior
to FXAA or MSAAx4.
In retrospect, I should've exposed ints to JS instead of entities.
Making this fix is already a TODO, but it will be a tedious change. For
now, this PR fixes two issues that were causing tiny but frequent memory
leaks, according to the emscripten memory leak widget.
(1) Do not include Entity in the list of classes that should only be
passed around by pointer.
(2) Clients should always call delete() on returned Entities.
This example has fallen out of date, I tried to resurrect it but it
turned out to be non-trivial, given the special nature of emscripten's
generated JavaScript wrappers.
It might be better to provide an example that uses rollup, since that's
the bundler that model-viewer uses, or a simple TypeScript example.
For now, I think our simple HTML + raw JS samples are sufficient.
We can now save an arbitrary (but decided at compile time) number of
entries containing information about previous frames and it for while
drawing the current frame. Typically this is used for such effects as
TAA, screen-space reflection, building probes over time, etc...
Currently the frame history consists of one frame per View. FView
provides a new (internal) getFrameHistory() method used to access
previous frames entries as well as to save the current's frame
information.
The FrameGraphPassResources (which is available in the execute closure
of a FrameGraph pass) has a new detach() method which can be used to
remove that resource from the FrameGraph lifetime management, at which
point it becomes the responsibility of the caller. Typically this
resource will be stored in the frame history.
The FrameGraph cannot store pointers internally because all objects
are stored in vectors. Unfortunately we were storing the writer of
resources as a pointer.
This is fixed by storing an index instead.
Sets of post-process materials are in their own folder now.
Also moved fxaa.fs from shaders/ to materials/ so it's next to the
material that includes it. This file is not shared with any other
material.
This prevents strange behavior with semi-transparent render targets,
which the model viewer team discovered when testing against the Khronos
alpha test conformance model.
