On Sat, May 9, 2015 at 12:05 AM, Igor Stasenko <siguc...@gmail.com> wrote:
> Either you run doits in separate process (as Sven demonstrated), > or you run it in UI process, blocking the rest of UI. > Stef, you complaining about not being able to see output of code that > blocks a process from doing such output. > I wonder how you going to fix that, and how much other complaints you will > face, > once you will fix that. > The solution could be to change the whole UI paradigm and separate > rendering from UI handling, which means that display no longer depends on > what UI process are busy with. > In troubleshooting a few system red-screen-of-deaths over time, it crossed my mind a few times that it might be safer if the #drawOn: methods were written in a functional paradigm, and be passed a kind of "RenderContext" object containing everything they need to render. > That means a lot of work revising the way how morphic delivers content to > the real estate.. > I guess Bloc is doing a lot of this work anyway. Maybe further discussion of a separate rendering loop would be worthwhile? cheers -ben > > Only then Transcript could work as expected, scheduling screen updates > into rendering/screen update schedule, as well as many other applications > that can benefit from separating rendering pipeline from event handling. > But alas, even then, you won't be fully satisfied, since VM is single > threaded and it can be busy only with one thing at a time, either updating > your screen, or advancing in progress of an action you instructed it to > perform. > And i remember many complaints of the past, where people was really > annoyed that 'Transcript is tooooo damn slow' because often for VM it takes > more cycles to update transcript than to do any progress with computation > you run.. > So, the choice is yours: you can run simulation that force updates of its > progress every microsecond on screen (so fast, that human eye cannot > notice) and as result your simulation takes hours rather than seconds, > or you block the updates , or at least do not update that often (for human > eyes updating more than 25 times per second is overkill). > >
