juha_tp wrote:Hmm... IMO, what I suggested should work with any type of multithreading system ... it's the mechanism that matters here.
Without some "gating" system you try to draw all those triggered frames (could be 1000's / second ... depends on implementation ofcourse) which usually leads to visible malfunction because of disturbed drawing process ... with "gating" the drawing process you draw only those frames which are triggered right after drawing of previously allowed frame finished (i.e. you just skip those frames which are triggered while drawing ongoing) and the last triggered frame.
Have you tried already if this method is possible in Ruby?
BTW, this type of method worked well in realtime file write/read process which otherwise had the same type of issue where file was written while read --> file became read before writing process was ended... . Gating the process like described above fixed the issue
From what I understand, the tearing happens on system level, because the system ignores the fact that drawing isn't finished and simply slaps the half-baked frame on the screen. It's not that two drawing routines within flowstone run simultaneously - that is something which would be fixed by the thing you propose.
To fix tearing, we would need to prevent system from sending half-drawed frames to the display (for example by always sending it last fully-drawn frame). I do not think there is a way to do that from flowstone. This would be something that the developers would have to implement in flowstone sourcecode (or even worse, it might be machine specific and had to be fixed by Microsoft in their Windows OS).
Off course I might be wrong...