target_synchronous(3)

πŸ“¦
version 0.7.1 Β· 2 versions
, in nixos 26.05

πŸ’… target_synchronous (3) ✨

okay bestie, welcome to the Arcan Lua API β€” this one's a little spicy so buckle up πŸŽ€


🌸 NAME 🌸

target_synchronous β€” enforce synchronous transfers, no cap πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

target_synchronous( dstvid, state )

✨ DESCRIPTION ✨

okay so real talk: this function is potentially dangerous 😭 β€” there's a genuine tradeoff between responsiveness and reliable readbacks for recordtargets. here's the vibe: if the frameserver isn't ready to receive when a readback from the GPU has been completed, the frame gets discarded. gone. poof. πŸ’€ that's the async-discard behavior, and you can alter it on a single frameserver by calling target_synchronous.

what does it change? it switches up the synchronization behavior so that processing will not continue until the frameserver is ready to receive. the way that this works means an untrusted frameserver implementation can potentially livelock the main engine 😳 and it'll also introduce additional jitter between rendered frames. so like... highkey be careful, bestie.

but wait 🫢 β€” if this is performed on a frameserver in decode mode, the "discard if PTS is too old" behavior gets disabled, and the last presented timestamp will be set to the frame that would've otherwise been discarded. iconic, honestly.


πŸ‘‘ switching it on and off πŸ‘‘

this behavior can be switched on or off dynamically by setting state to:

  • 1 / true β€” the default, bestie πŸ’– (synchronous mode, obvi)
  • 0 / false β€” off, back to the async life 🌈

⚠️ friendly reminder that this is the potentially-dangerous one β€” livelock and jitter are absolutely on the menu if you're not careful πŸ™ˆ

πŸ“ SEE ALSO πŸ“

  • targetcontrol πŸ’œ

later bestie 🫢 this page came from the Arcan Lua API, dated October 2026 β€” go forth and synchronize responsibly, mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from