β² 1067 βΌ Command line tip of the day (lemmy.world) submitted 8 months ago by yesman@lemmy.world to c/linuxmemes@lemmy.world 160 comments fedilink hide all child comments
[β] shalafi@lemmy.world 6 points 8 months ago (1 child) I'm a sysadmin and I'm weeping, gnashing my teeth and rending my garments. π And I've never done anything janky like that. Ever. permalink fedilink source parent hideshow 2 child comments replies: [β] partial_accumen@lemmy.world 2 points 8 months ago Oh, there's even more jank in this thing than the reboot workaround described above! I have 3 windows displaying different metrics on this display powered by the RPi. Because of the animation of each metric rendered on the display, higher value metrics will consume more CPU. Since each is a separate process, the animation in the displays would be different for each window by without any modifications. So to make each of the 3 display's animations operate at the same relative speed, I do a calculation of how the number of objects being displayed for the metric, then add an amount of invisible (well, black on black) objects to each window so to equal a fixed amount of the animation speed I want resulting in each window having the exact same number of objects and the animations move at the same speed. This works surprisingly well. The only time I have to monkey with the fixed value is if I'm using it on faster or slower Raspberry Pis. For example, I'll have a lower number of final fixed objects for an RPi 3 rather than a higher number of fixed final objects for a faster RPi 4. permalink fedilink source parent
[β] partial_accumen@lemmy.world 2 points 8 months ago Oh, there's even more jank in this thing than the reboot workaround described above! I have 3 windows displaying different metrics on this display powered by the RPi. Because of the animation of each metric rendered on the display, higher value metrics will consume more CPU. Since each is a separate process, the animation in the displays would be different for each window by without any modifications. So to make each of the 3 display's animations operate at the same relative speed, I do a calculation of how the number of objects being displayed for the metric, then add an amount of invisible (well, black on black) objects to each window so to equal a fixed amount of the animation speed I want resulting in each window having the exact same number of objects and the animations move at the same speed. This works surprisingly well. The only time I have to monkey with the fixed value is if I'm using it on faster or slower Raspberry Pis. For example, I'll have a lower number of final fixed objects for an RPi 3 rather than a higher number of fixed final objects for a faster RPi 4. permalink fedilink source parent