[Bf-committers] Re: [RFC] Re: Blender profiling-1 O16.2int

[Con Kolivas]

On Tue, 26 Aug 2003 12:54, Kester Maddock wrote:
> On Sun, Aug 17, 2003 at 11:36:42PM +1000, Con Kolivas wrote:
> > Now normally, blender should just sleep and wait till X comes
> > alive again before it does anything. However here it shows clearly that
> > it is spinning madly looking for something from X, and poor X can't do
> > anything. This is the busy on wait I've described.
> >
> > Second, any applications that exhibit this should be fixed since it is a
> > bug.
>
> Say if blender is polling the mouse in the view rotate loop?  (If so, you
> should be able to just hold down the middle mouse to starve, without moving
> the mouse.)
>
> Is this really a bug in the application?  Blender is interactive while
> rotating the view.  More CPU means more frames per second which gives the
> user a better experience.  The CPU usage will drop down when the user
> releases the middle mouse button.
>
> (OK, in this specific case blender could update the screen on mouse move
> events, but what about the general case eg a 3d game, where the screen
> is updated by eg monster ai?)
>
> And how do you fix it?  Would sleep(0) in these loops do, or do you need to
> select(...) on X?
>
> CC me please on replys.
>
> Thanks,
>
> Kester Maddock.
> ^ sends occaisional patches to blender.

Thanks for you attention. Yes this is a scheduler issue that makes it prone to 
the effect of priority inversion (heck even the mars rover module suffered 
it), brought out by the quirk in the coding. I wouldn't even know where to 
begin looking at the source of blender but the culprits we've tracked down so 
far that cause this use select with a very short timeout (15ms in one case). 
Basically it repeatedly times out, and X never gets adequate scheduling time 
to respond because the applications themselves are the ones preempting X.

Con