[Kaleidoscope] makes system too slow to react on user's input

[mpanasyuk]

Media threads also don't get enough CPU power.

How to reproduce:

1. Open some video/sound file in MediaPlayer.
2. Hit play and confirm there are no dropped frames or sound glitches.
3. Open Kaleidoscope.

Media playback will be affected. To make impact even bigger open Kaleidoscope fullscreen. Also you can chose more complex media file for playback, one that will load CPU more.

Haiku R1/alpha1 (Revision 32975)

[mpanasyuk]

Forgot to mention - VESA mode. Can't test not in VESA because my graphics card is not supported (nVidia 8600GT)

[axeld]

What is "Kaleidoscope" and where can one get it? It definitely sounds like a bad behaving application, but I'd like to confirm that assumption.

[mpanasyuk]

Sorry for not mentioning that earlier. It's a demo app from BeOS R4.x

[axeld]

Is there any way to get a copy of this demo app?

[mpanasyuk]

Kaleidoscope BeOS R4 demo app

[axeld]

Thanks! It looks like a locking contention problem within the app_server (probably due to the slow anti-aliasing lines drawing).

[axeld]

Should be fixed with hrev35472.

[Garjala]

I do not think it is fixed. Tested with hrev35528 and real hardware (Athlon64 3200, 2 gigs of ram, Radeon X800 Pro, Soundblaster Audigy).

1. Start playing mp3 with mediaplayer
2. Start Kaleidoscope

Now sound almost stops. You can hear few second of sound every 5-10 secs. Mouse cursor also randomly starts updating only every 3-5 secs making Haiku use very hard. Mouse cursor problem comes and goes while Kaleidoscope keeps running, but sound stays like that.

Both problems disappear when Kaleidoscope is closed.

[mmadia]

It seems to be a thread priority issue, Kaleidoscope's app_server thread is of priority 15. On a single core machine that could be preventing MediaPlayer from having enough cpu time. Manually reducing Kaleidoscope's app_server thread priority to 5 helps.

[axeld]

Which makes this a different problem. The interface still feels not perfect when Kaleidoscope is running, but it's definitely usable -- the maximum lock holding time should be shortened a bit more.

[Garjala]

Tested that and it seems that changing Mediaplayer "event queue runner" thread to 20 pretty much fixes the sound. Changing Kaleidoscope to 5 on the other hand only has small effect to sound even if I change all of its threads to priority 5. Neither of the priority changes fix odd mouse behaviour while Kaleidoscope is running.

[axeld]

Indeed, reducing Kaleidoscope to 5 shouldn't help a lot - the app_server thread is the expensive one (running with priority 15 as well).

I've further reduced the lock holding time in hrev35548; there is already a ticket about too low MediaPlayer priorities, so that should be covered.

[diver]

I tried to run Kaleidoscope in hrev35548 (vbox) and found out that if you start clicking on leaf menu in the same time - ~30% of such clicks will be ignored (Deskbar didn't react), is it intended?