title: GTK3 sometimes ignores gtk_widget_queue_draw when repeated too quickly?
body: <p>I have an application which does some simulation, and renders the result.  Because the render can sometimes be very slow, I separated it into another thread, and the main thread calls <code>gtk_widget_queue_draw</code> once it's ready.  If it's not finished drawing yet, the extra requests get discarded (since <code>queue_draw</code> only invalidates it, and it's impossible to be "more" invalid).</p>
  
  <p>The result is that with large complicated systems, simulation maxes out a thread, and render maxes out another thread, and everything works.</p>
  
  <p>I just ran into a different problem, and I don't see why it's happening:  A sufficiently simple simulation and render (6 5-point lines) causes it to break.</p>
  
  <p>The first few (I've seen everywhere from around 60 to 400) steps render fine (in a fraction of a second), until one step renders twice.  After that, it ignores the <code>queue_draw</code>, until I do something like drag a window over the render window, after which it restarts (until it breaks again).  </p>
  
  <p>If I artificially slow down the requests (<code>usleep(10000)</code> is around enough), this does not happen.  </p>
  
  <p>This is a completely unacceptable solution however, because the process of displaying is not allowed to interfere with the normal simulation thread (No delays, no mutexes, etc. etc.).  I need a solution that makes the render thread do "as well as possible", given that it is working with volatile data.  It does not have to be perfectly accurate--I really don't care if a frame renders a little wrong (half of frame i, half of i+1 is fine), as long as it does render.</p>
  
  <p>Why is this happening, and how do I fix it?</p>