Hi Aros, sorry for jumping into your discussion at this point. I just joined the community and am working on something someway related to your goal…
I think that the timer approach is just not the right one. Correct me if I’m wrong: you have a sort of engine which calculates new frames and needs to be called pretty regularly, and then you need to show these frames to the user on the computer display and at same time on a sort of led wall… well, here is what I would do…
Let your “engine” work with its own time base, say 80 frames per second. And each time you get a new frame you mark your on screen component to be refreshed.
This will “disconnect” the engine frame beat from that of the on screen component which will be painted in the traditional way by accumulating refresh requests (well, technically speaking, overlapping requests get aggregated into one single request working on a potentially bigger area).
When the on screen component paint() function will get called, it would just take a snapshot of the current offscreen image (the one managed by the engine at 80 FPS) and copy it over its own Graphics.
This is a simple description, but of course you’d better add double buffering techniques to reduce the time of the copy (when Component::paint() gets called) to a swap of a pair of pointers.
This will give the engine the “illusion” to be called very precisely because you will implement its own offline loop in a separate thread which won’t follow the system message priority rules… and will keep the paint() function from the component side very light. And you won’t take care of the position of your bouncing ball at this “rendering” time, because it already was taken care by the engine in its own thread loop.
Another improvement you could add is not to have a 1:1 correspondence from the offline image and the one of the Graphics object you will copy the image to.
If you manage a 2xWidth by 2xHeight offline image and scale it to the final image when needed, then you’ll have twice the pixels where to draw your bouncing ball (like in a sort of “in house” retina display). Final result is that your intermediate virtual display will support half-pixels and your ball will move way smoother.
And of course you could experiment 4x factors as well. It just will raise the CPU load a bit, but if I’m not wrong, scaling should happen with hardware acceleration (not sure about this on Windows… I’m on a Mac).
Just my contribute…