EffectScheduler

Remarks

This is the difference ADR-007 gives for not depending on SignalsDotnet, and it is worth restating: a game engine's UI has to flush effects at a precise point in the frame — after input, before layout, never mid-render — on a known thread, with a hard budget. An effect that ran the moment a signal was written would mutate the element tree while the renderer was walking it.

So writing a signal only ever queues. Flush is what runs anything, and the UI system calls it once per frame in one place.

Fields and properties (5)

• public static EffectScheduler Default

  The scheduler an effect uses when it is not given one.

• public int MaximumRunsPerEffect

  How many times one effect may run in a single flush before it is suspended.

• public int MaximumRunsPerFlush

  How many effect runs one flush may perform before deferring the rest to the next.

• public int PendingCount

  How many effects are waiting to run.

• public bool IsFlushing

  Whether a flush is running right now.

Methods (3)

• public EffectScheduler(ILogger? logger = null)

  Creates a scheduler.

• public int Flush()

  Runs every queued effect, and anything they queue in turn.

• public void Post(Action work)

  Runs on the owning thread at the start of the next flush.

Used by (17)

• AsyncComputedVixen.Ui.Reactive
• AsyncComputedTestsVixen.Ui.Reactive.Tests
• CollectionSignalTestsVixen.Ui.Reactive.Tests
• CompositionTestsVixen.Ui.Tests
• EffectVixen.Ui.Reactive
• EffectPassTestsVixen.Ui.Tests
• EffectTestsVixen.Ui.Reactive.Tests
• EmitterTestsVixen.Ui.Markup.Tests
• GraphTestsVixen.Ui.Reactive.Tests
• HotReloadTestsVixen.Ui.HotReload.Tests
• LinkedSignalTestsVixen.Ui.Reactive.Tests
• ReactiveGraphVixen.Ui.Reactive
• SignalTestsVixen.Ui.Reactive.Tests
• UiDocumentVixen.Ui
• VxmlGeneratorTestsVixen.Ui.Markup.Generators.Tests
• EditorShellVixen.Editor.Ui
• TaskCenterTestsVixen.Editor.Ui.Tests