Panicz Maciej Godek on Nostr: One thing that I'm relatively happy about is the design of the animation system in ...
One thing that I'm relatively happy about is the design of the animation system in #GRASP
Since GRASP can run in graphical environments as well as in terminal, all the rendering is mediated by the interface called Painter.
Painter is not a clear-cut, elegant abstraction. It has about 100 methods, and I think of it as a whimsical artist.
And among those, there is a method with the following signature:
(play! animation::Animation)::void
where Animation is a very simple interface, defined in the following way:
(define-interface Animation ()
;; if this method returns #f, it means
;; that the animation has ended and can
;; be discarded by the animation system
(advance! timestep/ms::int)::boolean)
Now, the three clients of GRASP provide very different implementations of the play! method (and each of them is fairly complex): the AWT version uses a javax.swing.Timer to advance the animations, the terminal version uses java.util.concurrent.ScheduledThreadPoolExecutor:scheduleAtFixedRate, and the Android version uses android.os.Handler:postDelayed (as if that meant anything to you)
All three clients use a fixed tick period of 40ms, which would ideally amount to 25 frames per second - but this is neither documented nor guaranteed (which is why the advance! method receives the time delta from the previous call that it can rely on)
Currently there are three use cases for the animation system. One is screen repositioning, another is the visual stepper, and the last one is used for panning to the next search result.
Since GRASP can run in graphical environments as well as in terminal, all the rendering is mediated by the interface called Painter.
Painter is not a clear-cut, elegant abstraction. It has about 100 methods, and I think of it as a whimsical artist.
And among those, there is a method with the following signature:
(play! animation::Animation)::void
where Animation is a very simple interface, defined in the following way:
(define-interface Animation ()
;; if this method returns #f, it means
;; that the animation has ended and can
;; be discarded by the animation system
(advance! timestep/ms::int)::boolean)
Now, the three clients of GRASP provide very different implementations of the play! method (and each of them is fairly complex): the AWT version uses a javax.swing.Timer to advance the animations, the terminal version uses java.util.concurrent.ScheduledThreadPoolExecutor:scheduleAtFixedRate, and the Android version uses android.os.Handler:postDelayed (as if that meant anything to you)
All three clients use a fixed tick period of 40ms, which would ideally amount to 25 frames per second - but this is neither documented nor guaranteed (which is why the advance! method receives the time delta from the previous call that it can rely on)
Currently there are three use cases for the animation system. One is screen repositioning, another is the visual stepper, and the last one is used for panning to the next search result.