The client creates its 3D view's window with it, so not adding it wasn't enough: covered entirely by the renderer's window, the client's window got no WM_PAINT and the client still drew about once a second. Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
1 parent
97b1d36466
commit
7bf29f3e4c
2 files changed
+6
-4
No files matched your search
@@ -30,7 +30,8 @@ creates (each 3D view, and again on room changes), the adapter:
|
||||
The renderer process draws into a child window it creates inside the client's window: window handles are valid in
|
||||
every process, and Windows allows child windows across processes (Chrome's GPU process works this way). The child
|
||||
is disabled so mouse input goes to the client's window under it. Its swap chain is a flip model one, which the
|
||||
compositor shows above the client's own drawing. The client's window must not clip its children (`WS_CLIPCHILDREN`):
|
||||
compositor shows above the client's own drawing. The client's window must not clip its children (`WS_CLIPCHILDREN`,
|
||||
which the client creates it with, so the adapter clears it):
|
||||
the client draws a frame when its window gets `WM_PAINT` (`SceneWindow.dll` invalidates it, and draws on the paint),
|
||||
and a window entirely covered by clipped children never gets one, so the client fell to about one frame a second.
|
||||
The process exits when the engine is destroyed or the client exits.
|
||||
|
||||
Reference in new issue
Block a user