Some time ago i described a skin's update principle, which avoids general Rainmeter update cycle. Obviously, it's not a America's discover. The meanings is easily to get - we set Update=-1 and do all the things manually through counter, which becomes a looper. It's needed when we want to avoid skin's redrawing on each cycle, and want to put a tasks step by step, not all the things to each update cycle. Just splitting measures/meters in time. It allow us to make skin's affection on a system as minimal as possible.
The main problem in this method it is.. Your measure what does "driver" function have no priority before other stuff even inside the skin, and if you have an animations or other launched skin, it may cause negative things to your "driver" and make delays. Cycles won't be skipped, but skin could be freezed while another action in processing. General RM's update mechanism (as i can see) have priority and even if system on low resources this cycles (update+redraw) executing perfectly.
It would be great to bring a little improvements in this mechanism. For example, to split update and redraw functions. It would save tons of CPU time in case, when you using onChangeAction dependencies, when you have to update and check many things, but skin's redrawing option is need only if some values were changed. Also a personal measures update rate would be a perfectly solution for many things. In this case, it would be possible to have a simple driver inside, which would rule all the things inside, but the driver (handler, controller, no matter how to call that) would have the same priority as main update mechanism. Sure, i understand, possibly i speak about weird things, but sometimes it would be great to have at least a part of options i described above.
Thank you for your attention.
