Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_vis_vumeter (Read 79753 times) previous topic - next topic
0 Members and 22 Guests are viewing this topic.

Re: foo_vis_vumeter

Reply #475
Thanks for the update! Right now I'm using 0.9.7 because of the flicking issue with transparencies. Hopefully you can find the source of that issue in the future, although I don't think it's going to be easy.

0.10.0-rc5...
I kind of, sort of, may be seeing the same issue. It is very intermittent and fleeting in my case. Definitely due to GDI since that is the part that flashes. I've used the performance counters on that bit of code and it completes all it needs within hundreds of microseconds consistently. Too fast to see or for the monitor to even display. There are no messages received asking the VU meter to do anything from outside of it. The suspicion right now is the timer is going too fast and likely the parent is being drawn slower due to possibly being in the main thread for the player, but this is a wild guess. Because of your busier UI that is what makes it look really obvious and annoying because I can barely get it to do the flashing more than 3 or 4 times per minute when actively trying.

Nice work, it seems like you're narrowing it down.

Re: foo_vis_vumeter

Reply #476

I hope other people see the potential of transparent VU meters too ;-)

Couple of questions:

The flickering you have seems to be a bit different than mine. It seems as if scrolling through your playlist itself does not trigger the flickering. With me it does. Only when you click a different item in the playlist it is triggered. So when metadb changes. This is a global trigger.

Also your waveseekbar reacts to this change of metadb with a flicker (it shows the Darkone image underneath). In my skin waveseekbars do not flicker.

Also scrolling though artist images in your biography panel cause the flickers in VU but if I'm seeing correctly NOT to waveseekbar. With me that does not cause flickers in both VU and waveseekbars either. What biography script are you using?

Attached video is with 0.10.0-rc5 and waveseekbar 0.3.0 alpha 1.

BTW. Beautiful VU skin. Which one is it?

Yeah, it seems the flicking can manifest itself in different ways, in different themes.

The VU I'm using in the video above is called "Fantasy". You can download the original here...

https://www.aimp.ru/forum/index.php?PHPSESSID=blbv0pcffu7g3skb6ra6s9v38b&topic=52865.msg324215#msg324215
(You can see it in the top row)

Re: foo_vis_vumeter

Reply #477
Definitely due to GDI since that is the part that flashes...Because of your busier UI that is what makes it look really obvious and annoying because I can barely get it to do the flashing more than 3 or 4 times per minute when actively trying.
I've uploaded 0.10.0-rc6.

This is about as good as I can reduce the flickering. In essence the flickering happens in 0.10.x as opposed to 0.9.x because off the move to the thread pool timer which means running rendering outside the main player thread. The default background shows through when the rendering thread requests the background redraw from the host window and that fails (the failure reasons are varied). The other side of the equation is what the host window is doing. Some things they do make the flickering more visible.

When using JSplitter you can help yourself by using asynchronous operations that don't block the main thread. For example, using "complete\album art.js" makes the issue more visible. In contrast, using basic\GetAlbumArtAsyncV2.js makes the flickering disappear.

During the RC (and I hope this is the last one), this scenario will print this message to the console (it happens during resizing as well due to waiting on the SendMessage timeout):
foo_vis_vumeter: paint_background_using_parent failed: <error-code>

On the resizing part, for the time being, turn off transparency in the context menu when doing any resizing of the VU meter for a less frustrating experience.

As always, DUI works perfectly and is unaffected by any of this.

Re: foo_vis_vumeter

Reply #478

I've uploaded 0.10.0-rc6.


I appreciate the work you're doing in this, I'm amazed how much progress you've made in such a short time. The good news is the flickering is gone. The bad news is, a new bug has been introduced.

When the transparency is enabled (and the VU is actually displayed) minimizing and maximizing my fb2k's window is impossible. It hangs for 5 seconds each time i press the title bars min/max button. I have similar issues when hiding panels in my theme, but I won't get into that because most themes don't function like that.

I can provide one of my infamous animated gifs if you want. :)

Re: foo_vis_vumeter

Reply #479
I've uploaded 0.10.0-rc6.
I'm using fooBar 32bit/CUI 3.0.0 alpha 5.

Scrolling flicker is gone, but for the rest I have the same issues as Majestyk.

When a single VU 2024 is displayed any resize of foobar causes a 5 second freeze. Switching displayed panels does have the same freeze when one VU 2024 is open.

When I don't do any resizing and the playing track goes to next track for a second VU 2024 will show the new track for a second, then freezes for a second of 4 and continues after that.

Re: foo_vis_vumeter

Reply #480
Another thing I have noticed with rc6 is every so often when fb2k is executed, nothing happens. IE: It just doesn't launch. The loading circle will appear for a bit but that's it. This doesn't happen when switching back to rc5.

Re: foo_vis_vumeter

Reply #481
When the transparency is enabled (and the VU is actually displayed) minimizing and maximizing my fb2k's window is impossible. It hangs for 5 seconds each time i press the title bars min/max button. I have similar issues when hiding panels in my theme, but I won't get into that because most themes don't function like that.
When I don't do any resizing and the playing track goes to next track for a second VU 2024 will show the new track for a second, then freezes for a second of 4 and continues after that.
I did many experiments. Most made it all worse in one way or another. I stopped the moment it began affecting DUI negatively. This combination in 0.10.0-rc7 seems to have the least negative effects, especially during resizing; and the flickering is almost (but not fully) eliminated. I also noticed a huge slowdown in the PSS/JSplitter instances when I happened to run these latest versions on a laptop on battery power. None of the fancy stuff is free.

Also, I'm creating a whitelist of the "splitters" that support transparency. As of today only PSS and JSplitter are allowed. Does anyone know if there are any others (that can contain a VU meter instance)? Here is my list so far:
  • foo_uie_panel_splitter: Transparency supported
  • foo_uie_jsplitter: Transparency supported
  • cui_vh_splitter: No support for transparency.
  • cui_playlist_splitter: No support for transparency.
  • cui_tab_splitter: No support for transparency.
  • cui_top: No support for transparency.

Another thing I have noticed with rc6 is every so often when fb2k is executed, nothing happens. IE: It just doesn't launch. The loading circle will appear for a bit but that's it. This doesn't happen when switching back to rc5.
I've only seen this when fb2k is hung on closing everything down. Because it keeps running, launching a second instance of the player is blocked (there might be a setting to disable this). The only times I've seen this happen on my components is when majorly screwing up and deadlocking the component (particularly on exit). In foo_vis_milk2 it happened lots because it relies on Win32 SendMessage() to communicate between the fb2k-stuff and the library. It is generally very obvious and easy to see what's still waiting for a lock to be released when it happens. I have not seen one lately in VU meter. I'll keep an eye out.

Re: foo_vis_vumeter

Reply #482
0.10.0-rc7:
I've noticed that going into and out of full screen mode changes the VU skin, and doing it often causes a crash.

Re: foo_vis_vumeter

Reply #483
0.10.0-rc7:

foo_uie_panel_splitter: Transparency supported
Thx. A lot of progress as the tests below show.


I first tested with two VU 2024 instances packed in a PSS grandparent/ JSplitter. Because that construction was (?) needed to protect fooBar from crashing going fullscreen and back with VU 2024 directly from PSS.

Testing results.
fooBar 2.24.1 32bit, CUI 3.0.0 alpha 5, PSS, JSplitter, VU 2024 0.10.0-rc7
All test done with two VU 2024 instances open. Both always have the same effect at the same time.

Codes OK / SFF Sometimes Single Flicker / ASF Always Single Flicker.

OK   ELP Scrolling
OK   ELP Queueing/Unqueueing/Sorting
OK   ELP Deleting/Adding items
SFF   ELP Selecting other song by mouseclick
SFF   ELP Automatic popup
SFF   ELP Opening other playlist
ASF   ELP Playing (other) song by mouseclick

OK   Seek Ahead
OK   Seek Back
OK   Seek in WaveSeekbar/WaveMINI/WSH Seekbar
OK   Changing PBO
OK   Changing ReplayGain
OK   Changing DSP
OK   Changing OutputDevice
OK   Changing/Muting Volume
OK   Opening General Preferences
OK   VU 2024 going Fullscreen
ASF   VU 2024 coming back from Fullscreen   NOTE: Creation of an single extra fooBar taskbar item per VU 2024 instance that returns from Fullscreen
ASF   Pause
ASF   Play
ASF   Next Track
ASF   Prev Track
ASF   Next Track automatic
OK   Exiting fooBar

During fooBar resize VU 2024 switches to non-transparent and tries to keep up with the resizing. Even if only the location and not the size of VU 2024 is affected. Very ugly and major slowdown.

All in all pretty good result with a couple of things that I would like a little better if possible.
First of all the refreshes on clicking Play/Pause while playing. I'm not switching tracks so no refresh is needed (like all seek forward/back which do work fine).
Second is the creation of a ghost taskbar item coming back from fullscreen per instance of VU 2024.
And third ... Can you disable drawing of VU 2024 altogether while fooBar is being resized? And only redraw VU 2024 after resizing stopped.


Now of course I noticed your remark about PSS being supported for transparency without caveats which made me curious since you blocked PSS fullscreen somewhere during versions because of PSS fullscreen crashes. To my astonishment in this version PSS is not blocked for fullscreen anymore and does not crash fooBar during/returning from fullscreen!

I created the same situation PSS grandparent (locked coordinates) / PSS parent (unlocked coordinates no margins) with VU 2024 child as the above situation with PSS (locked coordinates) grandparent / JSplitter parent (unlocked coordinates no margins) with VU 2024 child. All test results are exactly the same.
Conclusion: There is no reason to pack VU 2024 in a JSplitter to protect fooBar from crashing anymore, you can also use a PSS to pack VU 2024 in.

Next thing I tested was getting rid of the PSS parent with unlocked coordinates no margins and putting VU 2024 directly under the PSS grandparent with locked coordinates (the latter PSS thus becoming the parent).

Going fullscreen and back. Position after coming back from fullscreen is not centered anymore, but shifts to the left (off center). Apparently on return VU 2024 has lost its original centered alignment within the window/panel I allot to it. When a refresh is triggered (next track or resize) this is corrected, but I cannot force this by code since I have no way of detecting that a plugin has been fullscreened. Please fix.

During a resize of fooBar window like the other two constructions VU 2024 loses transparency and tries to keep up which is enormously slow and extremely ugly. On top of that it also overrides the coordinates it has been alotted and displays a very small non-transparent instance of itself in parent PSS from 0,0 coordinates (different from the allotted coordinates) during the resize. After resizing it restores itself to the correct size/position. Would all be fixed by my third request earlier (disable display of VU 2024 during resize).

Generally speaking all refreshes from the earlier tests above have the same undesirable effect. All refreshes lead to a very brief display of a small version of VU 2024 starting from parent PSS 0,0. It would be great if you were able to hide this initial refresh without transparency at the wrong coordinates. Since they are all triggered from outside so I cannot create code to force/hide this.

I would not mind if the new issues with a locked parent cannot be solved. Easy enough to pack a VU 2024 instance in an unlocked PSS (or JSplitter) parent, which leaves the three issues mentioned earlier:

1) Refreshes on clicking Play/Pause while playing.
2) Creation of ghost taskbar items.
3) Stop redrawing on resize.

 

Re: foo_vis_vumeter

Reply #484
Thanks again for the update. Although improved, 0.10.0-rc7 is still too slow on resizing. It would have to be like 0.9.7 for me to use it...and might I add I am perfectly happy running 0.9.7.

Re: foo_vis_vumeter

Reply #485
After many experiments, I have sadly concluded that foobar2000 does not provide sufficient information to serially sequence grabbing the GDI background device context during size/move/sys events. It appears to assume all of these operations occur in the "main thread". Without source code for foobar2000 or any of the transparency splitters, I'm not going to continue trying to make this work beyond its current state.

Now of course I noticed your remark about PSS being supported for transparency without caveats which made me curious since you blocked PSS fullscreen somewhere during versions because of PSS fullscreen crashes. To my astonishment in this version PSS is not blocked for fullscreen anymore and does not crash fooBar during/returning from fullscreen!
That I fixed already with @musicmusic's guidance.

Second is the creation of a ghost taskbar item coming back from fullscreen per instance of VU 2024.
Will not change this. This is the same as the Default UI behavior and it is technically incorrect to mark the VU meter window as a tool window. I made sure the window gets a nicer icon than the Windows default one for fancy Alt+Tab look.

Going fullscreen and back. Position after coming back from fullscreen is not centered anymore, but shifts to the left (off center). Apparently on return VU 2024 has lost its original centered alignment within the window/panel I allot to it. When a refresh is triggered (next track or resize) this is corrected, but I cannot force this by code since I have no way of detecting that a plugin has been fullscreened. Please fix.
That is the window caption. I can only place the window back where I'm told. I grab the position before going fullscreen and restore it coming back exactly the same. Check your splitter configuration. I don't know that I can do much either to detect this behavior either. In JSplitter, you need to enable pseudotransparency and then remove its caption.

This will be the final release candidate before a general release: 0.10.0-rc8


Re: foo_vis_vumeter

Reply #487
Second is the creation of a ghost taskbar item coming back from fullscreen per instance of VU 2024.
Will not change this. This is the same as the Default UI behavior and it is technically incorrect to mark the VU meter window as a tool window. I made sure the window gets a nicer icon than the Windows default one for fancy Alt+Tab look.
Not sure we are talking about the same thing. During fullscreen it is understandable there must be an ALT-TAB handle. But when fullscreen is closed there is not handle needed anymore,
Look at the screenshot. I have 5 leftover handles which clutter my taskbar massively, none of them have any function attached to them.
Trying to close any of them does not work and only minimizes fooBar itself (undesired as well).

0.10.0-rc8
It's great!

Resizing fooBar is handled fine.  And the transparent background with transparent BIN looks awesome.

The only redraw I'd like to see removed is the Pause/Play one.

Hopefuly you are willing to share the techniques you developed to other developers of current plugins.

Thx.

Re: foo_vis_vumeter

Reply #488
Going fullscreen and back. Position after coming back from fullscreen is not centered anymore, but shifts to the left (off center). Apparently on return VU 2024 has lost its original centered alignment within the window/panel I allot to it. When a refresh is triggered (next track or resize) this is corrected, but I cannot force this by code since I have no way of detecting that a plugin has been fullscreened. Please fix.
That is the window caption. I can only place the window back where I'm told. I grab the position before going fullscreen and restore it coming back exactly the same. Check your splitter configuration. I don't know that I can do much either to detect this behavior either. In JSplitter, you need to enable pseudotransparency and then remove its caption.
Nope. It's not the window caption. It is PSS without caption.

There is no issue with parent JSplitter at all.

There is a problem with parent PSS. VU 2024 does not remember it's coordinates coming back from fullscreen. And subsequently uses the parent's PSS 0,0 position to paint itself although it has been told by PSS to live on other coordinates.
Only when PSS issues a refresh (trackchange or window resize) it kicks VU 2024 in the back which restores the correct situation.
PSS does not know a fullscreen has been done, so I cannot correct it from code.

I tried two different constructions:
1) VU 2024 as a panel under main PSS with a whole lot of other visualisations under the same PSS.
2) VU 2024 as a panel under a child PSS as a single panel (same construction as I use currently with JSplitter which works fine).

Both have the same issue. Both forget the original coordinates and only restore correct upon a redraw (trackchange or fooBar resize).

The only thing you need to do solve the issue is do a redraw of VU 2024 after coming back from fullscreen (funny, since until now you had to reduce redraws).

PS. I do prefer to use VU 2024 directly under the main PSS, because that saves panels and makes construction more straightforward.

Re: foo_vis_vumeter

Reply #489
The only redraw I'd like to see removed is the Pause/Play one.
I checked. I'm forcing this update myself.
I have to because VU 2024 does not refresh itself upon trackchange and trackchange changes my background in case of different album.

Re: foo_vis_vumeter

Reply #490
This one hits a home run for me. Everything is working perfectly. Thanks, oops!
It's great!

Resizing fooBar is handled fine.  And the transparent background with transparent BIN looks awesome.

The only redraw I'd like to see removed is the Pause/Play one.
Happy to hear.

Look at the screenshot. I have 5 leftover handles which clutter my taskbar massively, none of them have any function attached to them.
Trying to close any of them does not work and only minimizes fooBar itself (undesired as well).
Whoah, never seen them stick around! I've had to pause the fullscreen exit to even see the taskbar entries for the VU meter on a single monitor since it gets removed really quick on my machine. I'll see if I can fix it later.

The only redraw I'd like to see removed is the Pause/Play one.
The only thing in the component that is affected by the player's play state is the calculation for the audio levels. There is no drawing difference based on those changes. The component will attempt to rerender and present a new frame at the rate of your Vsync (unless the max FPS option is set lower). I'll leave the "paint_background_using_parent failed" console message in the general release. Set the "Debug output" advanced option (and restart) to see it. If you see it when you get the play state change it is likely that the background is redrawing/not ready when the VU meter tries to get it. If that's the case, it might be simpler to fix in whatever is repainting the background. When I tested with the album art scripts the background gets grabbed correctly on window.Repaint().

Hopefully you are willing to share the techniques you developed to other developers of current plugins.
All of the changes will be published with the foo_vis_milk2. I've been synchronizing the Columns UI implementation between the two and use the same DirectX infrastructure organization. I have a long overdue rebase on this component before I publish the code, which might take a while longer.

Re: foo_vis_vumeter

Reply #491
Uploaded 0.10.0. Special thanks goes out to @Defender and @Majestyk for their detailed testing and continuous feedback.

Almost the entire component got some update. Enjoy!

The full and detailed changelog under the spoiler tag.
Spoiler (click to show/hide)

Re: foo_vis_vumeter

Reply #492
Uploaded 0.10.0.
Almost the entire component got some update. Enjoy!
Thanks for this. And happy to assist in testing.

In this build the ghost taskbar entries after fullscreen per instance of VU are gone.


I also did some comparisons between a JSplitter wrapped VU and a PSS wrapped VU:

1) JSplitter definitively needs a kick every track change to update it's background. This results in a flicker.
2) JSplitter. Upon resizing it's dark theme background is shown before restoring transparency. This repeats itself several times during a resize. Also resize is slow.

1) PSS does not need the kick every track change to show the correct background. Therefore no flicker. And also no flicker on Pause/Play.
2) PSS does not have issues showing transparency during resize. Also resize is a lot faster.

All other behavior is the same.

Therefore in my skin I changed all 5x VU 2024 to be wrapped in PSS instead of JSplitter. I also dropped 3x VU 2013 wrapped in JSplitter (leaving only 1x VU 2013 in PSS for test purposes somewhere).
BTW. I had to drop milkdrop first. CUI in layout mode crashes on applying changes when milkdrop 0.3 is present. I guess that will be sorted when you apply the same changes you made in VU also in milkdrop. After finishing the layout changes I reinstalled milkdrop 0.3.


Which leaves only 1 final issue:

I want to get rid of the wrapping of VU 2024 in a (PSS) wrapper altogether, which would reduce the numbers of PSS panels with 5 more.
I tested this construction. It works fine except when resizing and coming back from fullscreen, when VU 2024 seems to forget where it should display itself and displays itself from parent 0,0 coordinates. Which is only corrected after a trackchange or after resize.
The PSS wrapped version probably has similar behavior, but here it does not matter since VU is supposed to use the whole of the PSS parent area and has to display itself from 0,0 anyway. Still wonder why here during resize here a small intermediate version of VU is not displayed, which I accept gratefully.

I attached a video to show the issue, maybe it gives you an idea what and why it happens.
The upper VU (unwrapped) has a fixed set of coordinates and is the non-wrapped version and has a thin blue line that displays the coordinates VU has been given.
The lower VU (wrapped) has no coordinates set and is supposed to use the full area of it's PSS parent. In this case the blue line depicts the whole area of the PSS parent wrapper.
In text I also display all relevant coordinates.

I also attached a set of transparent BIN's with different L and R (to get rid of too much space in the middle). I also made a full set of opaque and gradient versions.


Anyway, happy camper here.


EDIT: The unwrapped version of VU 2024 even makes a ghost appearance in the parent. I changed the skin for the unwrapped VU and it displays itself as a small version although it should be hidden. And does show itself as a miniature whatever plugin I select. I can even doubleclick it to go fullscreen and back.

Re: foo_vis_vumeter

Reply #493
Running foo_vis_vumeter v10 - no crashes so far - happy camper

Will you be implementing the new Milk drop soon

Re: foo_vis_vumeter

Reply #494
Running foo_vis_vumeter v10 - no crashes so far - happy camper

Will you be implementing the new Milk drop soon
Yep, I got the MilkDrop release almost ready to go. Just got to put in the changes from the last few days such as the "ghost taskbar entries" updates in there and test the focus when docked. ETA: sometime this weekend or Monday.


Re: foo_vis_vumeter

Reply #496
Which leaves only 1 final issue:

I want to get rid of the wrapping of VU 2024 in a (PSS) wrapper altogether, which would reduce the numbers of PSS panels with 5 more.
I tested this construction. It works fine except when resizing and coming back from fullscreen, when VU 2024 seems to forget where it should display itself and displays itself from parent 0,0 coordinates.
I think I found the problem and implemented a possible fix. Let me test some more. But closing in on the ideal Columns UI fullscreen sequence that also accounts for PSS and JSplitter wrapping as well as transparency.