I love coding, but to the same extent I hate project maintenance. This is a problem I share with most other coders, I guess – but well, sometimes it just has to be done. And today it was MPUI‘s turn to get some fixes.

I mainly wanted to implement two things: First off, there was a request to run MPlayer with a higher priority than Win32’s »normal« priority class. This is usually a good idea, considering the ugly mess that is Windows’ scheduler. But on the other hand, I got a bug report that MPlayer hogs CPU when started from withing MPUI (and does not if run standalone). This really got my attention, mainly because it is essentially mutually exclusive with the higher priority setting. (You don’t want to have a high-priority process occupy the CPU in Windows. Believe me.)

I found out that the problem was caused by MPlayer’s –wid switch. This is the option that causes MPlayer not to create its own window, but embed into another one instead. Basically, this switch is the very heart of MPUI, so it’s not possible to live without it. My first assumption was that MPlayer does some sort of polling when used in embed mode. A quick look intro vo_directx.c somewhat confirmed this: In put_image, the function that essentially displays each image (and is therefore called quite frequently!), Directx_ManageDisplay is called. This function, in turn, checks if the window size and position is OK, checks DirectX caps, sets up the DirectX clipper, updates the overlay and some other fun stuff. Normally (without –wid) this function is only called if the window size or position changes, which is totally sufficient. But in embed mode, MPlayer doesn’t receive the size/move events from the window manager and thus has to poll.

To fix this problem, I may have to set up a MinGW development environment here to fiddle around with MPlayer’s code – in my opinion, a window size/position cache would reduce the per-frame overhead to a mere GetClientRect(), which should yield acceptable performance.

But this a project for the future – today, I settled for two of the minor improvements on MPUI’s ToDo list: native .m3u playlist support and (preliminary and not very thoroughly tested) volume control.

And right now, I’m asking myself why I write all this. Oh well, I guess that this is what blogging is all about … telling the world boring and uninteresting things :)