Why only move of window with heavy app, slowdown it?

Just have a usability question: Why on aos4, when you run any heavy programm in window (and, it works fine, without problems, without slowdowns), when you move that window , it looks like you do very heavy job which heavy used CPU and because of it happenes big slowing downing of the app in that window ?

For example in case with Mplayer. You have open in window some moview, then, resize window for a big size. Then, movie that window by top line of window, and, you will heard and see some suttering. Just like when you grab the window, it's start to be much slower.

I trying with composite and without, on 16bit and on32bit. With 16bit its a bit faster, but still, i am curios, why it happenes, and how avoid this ? Or it 's just because of Os4 core itself ?

As for me (as for end user), if you run any app , and any count of apps, it must be slow, yes, but not when you movie window, no ? Its looks like just bad priority or kind, dunno.
It's just feel bad.

@kas1e

While you move the window the application is blocked from updating the window contents. That's why the video stutters. On the other hand, the OS is not allowed to move the window while the application updates it, that's the reason why you cannot move the window smoothly. The app and the OS are fighting for access to the window contents.

@kas1e
...why it happenes, and how avoid this ?... Or it 's just because of Os4 core itself ?
Yes, core. The API was updated, if you didn't know:
Intuition
Improved window support, fading and rendering - including drop shadows.
Reduced video memory consumption due to improved screen handling.
New internal methods for better system "theme" support. (Hyperion)
Why don't you ask the "kernel guy" ?
The window system has slowed down my favorite hangout -- SDLBasic. My poker project graphics slowed down a lot because of it; it's not snappy like it was before Update1, but it's workable.

@Snuffy

ok but why your application instead of running smooth and well now runs slower ?.. un update should give you better performance and not worst .. am i wrong ?

@thomas

Thanks for interesting answer. But that "slowing downs" happens only when CPU loading are heavy. When i have some "easy apps", then there is no problems. All works smooth. So looks like just not enough CPU power, and in end, we see that "fighting" in the real time.

I am just curios, nothing can be done on user level for now ? Maybe setting hi or low priority for that programms, to allow moving of window (os) have high priority, and lower priority of application itself ?

@nubechecorre
As for me, imho, better have smooth moving of window always, let's it be a bit slow down the content inside. But for now it looks like you just tear the screen :)

I am not low-level programmer, and more of it i am not the core/drivers programmer, but, from my point of view it can be solved by 2 ways: priority (on the kernel level) and some kind of message server , which will communicate beetwen those 2 thinks: moving of window and content inside, and works with double-buffering + vsync = will give us smooth effect. Just like any game or demo done.

@kas1e

The problem is not CPU load but gfx update speed. You gave mplayer as an example. Mplayer does not cause CPU load. Its problem is moving gfx data to the window at high speed all the time.

I am sure that a program like this, which causes the highest CPU load possible, will not slow down window movement:



Writing a 24bit RGB buffer into a screen with BGRA pixel format is very slow on my A1. This has nothing to do with heavy CPU load.

Mplayer is trying to play the movie as smooth as possible, i.e. it keeps updating the window all the time. While writing a movie frame to the window, the window is blocked from other updates. This means mplayer keeps the window locked almost continuously. Only every now and then it unlocks it for a few microseconds when it calculates the next frame. And only in these short breaks, the OS can move the window.

That gfx update is slow on the A1 you can also see in PicShow if you enable cross-fading. With a resolution of 800x600 it runs just as fast as realtime. Any higher resolution leads to stuttering.

The same on WinUAE runs completely smoothly even on 1280x1024.

@thomas
So, the only solution more powerfull CPU for now ?

Hi @nubechecorre

...update should give you better performance and not worst .. am i wrong ?
Kind of...
http://www.libsdl.org/
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.

SDLBasic taps this for it's functioning. A native basic program would solve this! But, of course I'm day dreaming about that. Anyway, the update has nothing to with SDL and made the executions list longer. Since this was all at the 32 bit screenmode, I find that switching 16 bit mode a better environment. Gak...
You know you just reminded me of check the 'SObjs' libraries. SDL has library and I bet it's not Peter Gordon's latest update. Off to do that....