[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "Pete" <trac@xxxxxxxxxxxx>
- Date: Fri, 16 Mar 2012 02:00:15 -0000
#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:
