View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014564 | MMW 5 | Playback | public | 2017-11-28 17:51 | 2020-03-27 16:42 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0014564: Visualization Performance issues | ||||
| Description | Tested visualization in build 2085 and there are some performance problems: 1) CPU utilization. It looks like the visualization doesn't offload anything to the GPU. MM4 Playback: ~ 6%. With vis: ~ 10% MM5 Playback: ~ 15%. With vis: ~ 40% 2) The visualization isn't synchronized with the music. | ||||
| Additional Information | Note: user at GJG-829-82789 indicated that he might want to help with visualizations in MM5. Perhaps we should try to see if a user would be interested in porting Milkdrop? Note: we may need to use WebGL to reduce CPU utilization. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2094 | ||||
|
|
Fixed in build 2089. Old Milkdrop visualization is replaced by new Milkshake visualization. It implements some of Milkdrop features (not all, some things are missing and some seems to not work ok) and it uses WebGL, so it is less CPU consuming. Please test, if it is better for you. (switch off small player visualization by clicking on it, this does not use WebGL, probably should be implemented in the future too?). |
|
|
Verified 2089 |
|
|
2089 test Pic uploaded |
|
|
Tested build 2093, and the feature is still unusable for performance reasons :-( It is both very slow and out of sync with the music. I've posted a video of this to the ftp site. |
|
|
I retested by first freeing up memory and cpu to ensure that there weren't any external constraints. After doing so, I found that: - in the A&D panel, the visualization performs as expected (i.e. it was very slow in the previous test due due to CPU/Memory constraints). That said, these limitations should not exist--i.e. we should fix this as well even though it's not quite as severe an issue. - the bug occurs with both DSound and Wasapi - in full Window mode, the visualization performs better (i.e. appears more as one would expect it to) the smaller that the window is. - when running the visualization in full Window mode, CPU utilization is inversely correlated to the size of the window! The is completely the reverse of what one would expect. Hopefully this gives a clue as to the problem's source. Note: I'm testing on an ultrawide monitor. |
|
|
For consistency of a test and comparison against test results across different PCs I'm suggesting to create "PresetsTest.js" with one simple Preset (Attached) and either implement F5 (show FPS) or automatically Show FPS in the top Right corner. |
|
|
Not sure how much it is related to Chromium rendering, but I also found Rusty's machine very very slow re graphical performance (even for MM4), e.g. on his machine function GetPixel in GDI32.dll was very very slow, we needed to replace it by ScanLine , details at 0014490:0049064 I am also seeing higher CPU utilization (10% on my i7) when the visualization is in A&D window. Full screen visualization is only at 3% of CPU (same as with visualization disabled). BTW: If milkshake visualization is in A&D window and I close MM5 during the visualization then I am always seeing stack overflow error : https://www.dropbox.com/s/9iw3m3t2hvpj4am/Screenshot%202018-04-03%2013.58.42.png?dl=0 |
|
|
Stack overflow error fixed in build 2094. |
|
|
In build 2094 - implemented support for: F5 - displaying/hiding FPS F10 - toggle automatic preset change. When off, current preset will not be changed. |
|
|
Resolving so you can test it. Other optimizations are problematic, worse performance on some systems could be caused by Chromium and its WebGL implementation, I have no idea how to significantly improve it on our side. And Javascript runs only in one thread, so all GUI actions have impact on visualization FPS too (e.g. scrolling, hovering, even simple mouse movements or progress animations). |
|
|
Verified 2231 When MM is in focus FPS is in VSync to Monitor at 60FPS, but as soon as other app is front or mouse moves outside MM5 Window it drops to 20-30. I gues sthat we can't do much but it is worth to mention. Close if I am right. |
|
|
It is a feature, fps is reduced to 30fps for inactive window (and to 2fps for invisible window), to reduce CPU load in these situations, when another window has focus. |
|
|
Verified 2235. |
