Render filter optimization

MCHPR / MCHPRS

A multithreaded Minecraft server built for redstone.

MIT License

1.55k stars 68 forks source link

Render filter optimization #120

Closed Paul1365972 closed 11 months ago

Paul1365972 commented 11 months ago

Adds a command /togglerenderfilter to toggle the render filter optimization (per plot). This stops the server from sending non-IO redstone component block changes to the client. This commit also adds a few more commands to the auto complete graph.

Considerations:

After deactivating the filter all affected redstone components are still in a desynchronized state. Maybe invert the filter and resend all "missed" changes
Using a build script and perfect hash functions may be a bit overkill and add unnecessary code complexity (Move to different/separate crate?)
This setting could make more sense as an per player option, this could possibly be a bit trickier to implement

StackDoubleFlow commented 11 months ago

Another thing to consider is that the --io-only flag in redpiler does much the same thing. It feels odd having this be a completely separate concept from that. I think it would be easier if we could unify these across the different backends. Maybe we could have it so that if the render filtering is enabled, it automatically sets that flag on redpiler compiles?

Paul1365972 commented 11 months ago

Seems like I missed the --io-only flag. I believe filtering non-IO updates without compiling is nonetheless a useful feature, at least I am currently using it. Considering that the two concepts are so similar I'll rename the command to /toggleioonly and auto activate the --io-only flag when running the /redpiler compile command as you suggested.

Paul1365972 commented 11 months ago

I added another related commit to this PR. It unifies the front- and backends understanding of what a input or output component is. This should help keep the logical inconsistencies at bay and make future optimization passes easier to implement and maintain. This however sadly couples the redpiler's logic to the build script. However I tried to minimize the interaction surface to a minimum, just in case the redpiler should ever be extracted into its own crate.

Since the logic got more complicated, should these generated sets be moved from the plot/mod.rs file into their own? Perhaps a constants.rs file with other constants, that are currently still scattered across the code base, would be useful in the future.

Paul1365972 commented 11 months ago

Closing in favor of #123