[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile

#8007: [app_server] fully unresponsive when resizing window of big textfile
-----------------------------+----------------------------
   Reporter:  ttcoder        |      Owner:  axeld
       Type:  bug            |     Status:  new
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:
 Blocked By:                 |   Blocking:  7882, 8136
Has a Patch:  1              |   Platform:  All
-----------------------------+----------------------------

Comment (by Pete):

 Replying to [comment:54 Pete]:

 I've done a little more investigation, and I probably shouldn't have been
 quite so pessimistic.  In particular:
 >
 > Finally, I didn't find the hoped-for improvement in audio glitching.
 Moving a window still causes just as many 'crackles' as before, despite
 the supposed higher priority of audio.

 I was using Csound for this, which was not the best choice.  I have to use
 a very small audio buffer (64 bytes) to keep the latency low. (Not the
 audio-chain latency -- this is Csound's fault, in the way it generates the
 audio.)  My MusicWeaver/fluidsynth stuff can use a more sensible buffer
 size (960 bytes), and has much better behaviour.   Most of the time...

 I find that I can fire up a live music configuration, and play fluidsynth
 with *no* audible glitches, even when I move windows around.  This is
 vastly different from my experience without the patch, where window
 movement causes continual crackles.

 In this condition, it's the app_server (I guess) that slows down!  Only
 when the screen contains windows belonging to the audio app, though; other
 workspaces seem normal.  Window movement starts lagging behind the cursor.
 I can understand this if the audio threads are getting preference, except
 that the total load on the CPU (shown by 'top') doesn't seem excessive --
 about 7-10%.  And, as I say, it's only when related windows are visible.
 In any case it's much preferable to ugly audio!

 ''However''... things don't always seem to work this way.  I seem to still
 be able to get into a situation where window movement interferes with
 audio, and it then continues this way, much like without the patch.  I
 haven't been able to determine what causes the switch, but I'm going to
 run the patched system as standard for a while, to see if I can figure out
 what's happening.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:55>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: