Never make the client wait for drawing, or hold up its steps
CI / build (push) Successful in 1m15s

The renderer process now takes each view's chunks on a thread of its own as
they come, and draws the newest frame on its main thread: the client no longer
waits for the previous frame to be drawn (on a VM, 22 of a frame's 25 ms).

The adapter records the client's steps (SceneViewer::step, by replacing its
entry in the exported IFrameListener vtable, after checking it), and the frame
pacer doesn't ask for a frame that wouldn't end before the next step is due: a
late step made the client catch up two at once, which showed as hitches. While
the renderer process covers the view, the client's renderer doesn't begin or
present frames, which could wait for the display.

The engine's stats now include the time in the client renderer's methods.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
dhkatzandClaude Opus 5.5 committed 2026-10-28 21:30:46 -07:00
1 parent 399d934a08
commit 065c7e9300
11 files changed
+280 -78

No files matched your search

+31
View File
@@ -0,0 +1,31 @@
#pragma once
// Diagnostics: the time spent in the client renderer's methods (the engine's inner engine, and the resources it made),
// summed, so the stats can tell it from the rest of a frame.
#include <windows.h>
#include <cstdint>
namespace t5de {
// QueryPerformanceCounter ticks spent in the client renderer's methods so far.
inline std::int64_t innerTicks = 0;
// Adds its lifetime to innerTicks.
class InnerCall {
public:
InnerCall() { QueryPerformanceCounter(&start_); }
InnerCall(const InnerCall&) = delete;
InnerCall& operator=(const InnerCall&) = delete;
~InnerCall()
{
LARGE_INTEGER end;
QueryPerformanceCounter(&end);
innerTicks += end.QuadPart - start_.QuadPart;
}
private:
LARGE_INTEGER start_;
};
} // namespace t5de