<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Actually, punting to another thread or process is still going to slow
<br>down your rendering, but in a much less deterministic way. The OS<br>scheduler is going to be interrupting the rendering rather than the<br>long-running serialization function. Breaking down the serialization<br>work into smaller chunks will allow you to better control what's going
<br>on.<br></blockquote><div><br>Holy crap! I just grew an extra brain cell! It has tingly sensation like selson blue.<br><br>So let me offer some empirical evidence of this phenomenon which I was not quite understanding until reading your comment - of course, it makes complete sense now. I've been working on a cheesey game in my spare time called Twisted Wars (yes, the Twisted), and just to amuse myself I decided to run the reactor normally rather than threaded select and model the runtime loop as a cooperative iterator - the idea being that eventually the runtime loop could be many cooiterators, to allow for an actor-based system.
<br><br>To my surprise, after changing the core runtime to a cooiterator, my frame rate improved (albeit only about +5 - but this might be more noticeable if I had a decent frame rate to start with). I explained to a friend who's also working on the game and they refused to believe me! Ha!
<br><br>-Drew<br></div></div>-- <br>\\\\\/\"/\\\\\\\\\\\<br>\\\\/ // //\/\\\\\\\<br>\\\/ \\// /\ \/\\\\<br>\\/ /\/ / /\/ /\ \\\<br>\/ / /\/ /\ /\\\ \\<br>/ /\\\ /\\\ \\\\\/\<br>\/\\\\\/\\\\\/\\\\\\<br>
d.p.s