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

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

[John K. Walton]

On Tue, 26 Aug 2003, 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.)

yes i've mentioned this in the past. holding the middle mouse or right
mouse button _without_doing_anything_ eats up cpu time. it is clearly
a waste of cpu time. nobody responded.

> 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.
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
> 

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

[Kester Maddock]

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.

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