jonathanhogg / flitter

A functional programming language and declarative system for describing 2D and 3D visuals
https://flitter.readthedocs.io
BSD 2-Clause "Simplified" License
39 stars 1 forks source link

Either fix or pull simplification on state #49

Closed jonathanhogg closed 7 months ago

jonathanhogg commented 7 months ago

Program simplification on state is completely defeated by anything that frequently touches state, which includes physics systems or counters. I should either turn it off and pretend it never happened, or I should think about how to make it work in these cases.

There is an argument for turning it off, as running the simplifier is not zero-cost and can result in irritating frame stutters.

In terms of making it work, the idea that occurs to me would be to bisect the state into static and changing pieces. Simplify on the former and continue to lookup the latter dynamically; dump the simplified program if anything on the static side changes.

Probably the simplest way to achieve this would be to keep a second dictionary mapping state keys to timestamps. One could then walk this every x seconds looking for things that have not changed in the last x seconds and run the simplifier for just those keys. Keep a record of which keys were simplified on. If the set of static keys hasn't changed on the next check, we'd keep the current simplified program. If any of the static keys changes during a frame then dump the simplified program.

jonathanhogg commented 7 months ago

I feel like there's probably an optimisation here based on the idea of generations…

Maybe keep a set of "known static" keys, a set of "potentially static" keys and a set of "known dynamic" keys.

When a key changes:

At the expiry of the x-second check timer:

For rapidly changing keys, we add a set lookup on each state write. At the timer expiry, the minimum we do if nothing has changed is a simple set empty check, a reference swap and an empty set creation.

jonathanhogg commented 7 months ago

Resolved in commit 4f6e9ff