Well, using CRuby, this wouldn't make the slightest difference, due to the GIL (global interpreter lock). Multithreaded CRuby applications only gain anything from blocking operations, so it would only make sense to put network operations into another thread. If you just want the control you gain from having co-processes, you'd be better off using Fibers anyway, but obviously they are not multi-threaded.

On other Ruby builds (Rubinius, jRuby, etc), you could do it, since they suppose proper multiithreaded applications, but then you hit other problems (Terrible Windows support being the main one).

If you wanted to run Window#update and Window#draw in parallel, you would have to make sure that update doesn't change the map while draw is trying to render it etc. So that's not generally possible or efficient.

However, Gosu only queues calls to Image#draw, then manually orders them by z, then passes them on to OpenGL, all while applying clipping rectangles and transforms. That part could easily be run on a secondary thread, but that's an optimisation internal to Gosu, and is not likely to happen soon. I don't think it would solve bottlenecks in Ruby games, which are usually limited by loops written in Ruby, not Gosu itself.