Here's x's regular hard question of the day... ;) Rev is great for 95 percent of the apps, this works ok though because you can divide information or make it painless in a prepared way or a different gui approach, no problem. But creating gradients, rendering images, treating a million of anything is a severe issue when dealing with rev's processing speed or throughput. I know, rev is not c...
So in graphical applications rev can be a real bottleneck. If you have to treat lots of historical data for a display it's enormous time... Examples abound but im sure drawing fractals, finding simple permutations, or factorials, etc, the task soon becomes hours of wait for a calculation or an image to draw. This has two adverse effects: Rev is unavailable and your CPU spikes to 100% blocking other applications from operating correctly... It's a fact that if we want to use rev in parallel while it processes something, or lower the cpu we could add somekind of wait in the loop... And this is where im asking anyone's opinion on how to implement this... Here's some examples of ideas I'm thinking of... Loop 10^10 times calculate send idle to rev -- rev receives socket messages or user clicks, etc... then continues end loop or loop 10^10 times if the number of lines in the pending messages < PMLimit then send calculate to rev in 12 ms end if end loop Problem with this is that things can get stuck, some waiting to be executed and your loop waiting for the queue to move... or loop 10^10 times calculate wait 50 ms with messages end loop Is this possible? The same situation applies to applications like games, simulations, graphic or "processing-intensive" applications. If this runs, it blocks the rev session, possibly other processes... Wouldn't it be nice to have some kind of "Rev-OS" like runtime breathing bubble for the os or other running stacks? It may be that osx doesn't act this way... It's severly annoying in windows. When I test MoireX application which draws graphical moires and more with 500X500 paint X 4 points X 3 colors (in a special function realm), it blocks everything including videos running in other apps! It breaks the connection to chatrev, rev looks like a frozen-hung application. The wise developper will say compile apps (but then I can't enhance them on the run), run in other rev-session (but it's easy to get confused - risky...). but what if you are developping the application and the testing creates the same blocking process in your workflow? Running 2 sessions of rev is not exactly handy, may require another license, etc... The point is to allow rev to multitask (not thread alas) and do all this in one instance of rev running alone (one 100cpu cycles sucking application at a time is enough ;) - also create parallel tasking things is not the easiest way to get projects done... There's solutions to this, I know... but please dont change the subject of "giving rev some events back between loops or reducing cpu load... The point is go give rev time to breath between loop (or 5 loops) so it can work somewhat regularly (50% of the cpu would be nice)... Breaking down the "loop" into subhandlers doesn't really help (they can't be threaded) and "sendeables" is maybe a problem if we "send" each subhandler into the queue X 1000000. Using another runtime of rev is not the issue - 200% cpu used! overheating! your computer explodes in a new revolutionary way ;) In brief, is there a way to intervene in a task intensive loop, such that it brings down the cpu to 50% use, yet still be 75% effective compared to when we run all the loops uninterupted? I sense that a stack based event list in addition to the existing global eventqueue (pending messages) needs to be implemented for this... Is that a valuable improvement? If you work with databases or graphics, long text (+1MBs) or 10000 of anything you know what I mean... cheers Xavier http://monsieurx.com/rev _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution