by DeathAxe » Mon Nov 16, 2009 2:24 pm
OK, I renamed Registry Key, %Local Appdata%\MediaMonkey and MediaMonkey\scripts to make it clean. MediaMonkey still shows installed extensions, as I did not rename C:\ProgramData\MediaMonkey, but this should not be a problem.
First Situation:
1. I let MM add my Music to the new DB.
2. I press the play-button with an empty playlist.
--> Aeropeek shows waiting cursor!
Second Situation:
1. Select all files in themain listview (about 9000).
2. Start "Get albuminfo from freedb". This takes about 2...3s until the dialog pops up telling me not to have an AudioCD in my drive.
--> During these 2...3s Aeropeek shows waiting curser with and without playback enabled.
I think there I could trigger some more situations like the two above, but I am sure to have an idea what is causing the issue:
A windows application does normally have only one main thread. All messages received by e.g. a click on a menu item or windows itself are handled in this one loop. This means if one message handler needs some time to be ready all other messages are queued but not handled. In fact this means a requested paint cycle (WM_PAINT) is not handled during this time, too. I did not study aeropeek-API, but I think it requests a paint operation from the main window/form, if user hovers the taskbar icon to get the image to show in the preview window. Now that e.g. "Get albuminfo from freedb" has been started a bit earlier and is executed in the main thread by default, the requested paint cycle has to wait. As soon as "Get albuminfo from freedb" is ready, aeropeek is updated correctly.
If I start "Get albuminfo from freedb" I get a waiting curser when pointing to the main form, too and I am unable to move the main window as these requests are not handled, too.
This would mean eighter to move all operations to different worker threads or to "cache" a bitmap of MM's mainform or current album art to be used by Aero Peek. So Aero Peek would always show the last valid image. As soon as a WM_PAINT is triggered, the bitmap is updated by a simple copy operation again.
Summary:
I did not test further scripts for being responsible for this issue, as I think the issue is caused by normal limitations caused by Windows' Message structure. Normally a message handler needs only few milliseconds to finish and therefore a paint request by aeropeek is executed quite soon.
Hope this helps you hunting the bug.
OK, I renamed Registry Key, %Local Appdata%\MediaMonkey and MediaMonkey\scripts to make it clean. MediaMonkey still shows installed extensions, as I did not rename C:\ProgramData\MediaMonkey, but this should not be a problem.
First Situation:
1. I let MM add my Music to the new DB.
2. I press the play-button with an empty playlist.
--> Aeropeek shows waiting cursor!
Second Situation:
1. Select all files in themain listview (about 9000).
2. Start "Get albuminfo from freedb". This takes about 2...3s until the dialog pops up telling me not to have an AudioCD in my drive.
--> During these 2...3s Aeropeek shows waiting curser with and without playback enabled.
I think there I could trigger some more situations like the two above, but I am sure to have an idea what is causing the issue:
A windows application does normally have only one main thread. All messages received by e.g. a click on a menu item or windows itself are handled in this one loop. This means if one message handler needs some time to be ready all other messages are queued but not handled. In fact this means a requested paint cycle (WM_PAINT) is not handled during this time, too. I did not study aeropeek-API, but I think it requests a paint operation from the main window/form, if user hovers the taskbar icon to get the image to show in the preview window. Now that e.g. "Get albuminfo from freedb" has been started a bit earlier and is executed in the main thread by default, the requested paint cycle has to wait. As soon as "Get albuminfo from freedb" is ready, aeropeek is updated correctly.
If I start "Get albuminfo from freedb" I get a waiting curser when pointing to the main form, too and I am unable to move the main window as these requests are not handled, too.
This would mean eighter to move all operations to different worker threads or to "cache" a bitmap of MM's mainform or current album art to be used by Aero Peek. So Aero Peek would always show the last valid image. As soon as a WM_PAINT is triggered, the bitmap is updated by a simple copy operation again.
Summary:
I did not test further scripts for being responsible for this issue, as I think the issue is caused by normal limitations caused by Windows' Message structure. Normally a message handler needs only few milliseconds to finish and therefore a paint request by aeropeek is executed quite soon.
Hope this helps you hunting the bug.