OpenTUI 0.8.4
A chat log often puts many CodeRenderable blocks in a ScrollBoxRenderable with viewportCulling: true. With streaming: true and drawUnstyledText: false, a block that gets new content keeps showing its old highlighted text until the new highlight is ready, so the reader never sees a flash of plain text. But a block starts its highlight from its update hook, and a frame calls no hooks on a block that the scroll box culls. In 0.8.3, a culled block therefore kept its old text in its buffer, and layout measured that old text. The scroll box reported a stale scrollHeight until the block scrolled back into view.
In 0.8.4, a block that gets new content first asks the scene whether the hooks of the next frame reach it. If they do, the block keeps its old highlight, as before. If they do not, as for a culled, hidden, or detached block, the block loads the new plain text at once, so layout measures the new content. It does not paint that text until the highlight is ready. The highlight starts in the first frame that reaches the block again. C hosts can ask the same question with ot_scene_reaches_hooks. It answers with the branch selection that the next frame uses.
Added
- native:
ot_scene_reaches_hookstells if the hooks of a frame reach a node. It selects culled branches as the next frame does. See C.
Fixed
- core: A culled streaming
CodeRenderablewithdrawUnstyledText: falsenow measures new content immediately. It does not paint that text until its highlight is ready. See Code.
API changes#
@opentui/core#
Added
method FFIRenderLib.sceneReachesHooks(context: NativeContextHandle, node: SceneNodeHandle): boolean
opentui.h#
Added
function ot_scene_reaches_hooks(ot_context *, const ot_handle *node, uint32_t *out_reached): ot_status