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: Foobar2000 v2.0 x86 Seekbar rendering issue (Read 2042 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Foobar2000 v2.0 x86 Seekbar rendering issue

Windows 10. It will happen randomly after I launched a fullscreen application. This one was particularly bad, after playing Elite Dangerous. Happened ever since 2.0 AKAIK. Appears to be a leak where the draggable thumb in the seekbar was not erased.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #1 –
What's with the partially orange and blue titlebar? Is that also a rendering bug? Or are you running some custom OS themes?
Anyway, potential bugs in foobar2000 v2.0 are most likely quite uninteresting as 2.1 has had plenty of fixes. Update to the latest preview build and report back if there is misbehavior with it.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #2 –
I don't do preview builds because there is no seamless way to stay with a version (Just keep updating - no). But thanks for the hope. This is a trivial thing (orange is just anonymization of a large title, didn't want to touch anything to get rid of the glitch) and I see light at the end of the tunnel. Once 2.1 comes out I'll report back.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #3 –
That's a negative Ghost Rider. :(

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #4 –
Your screenshot seems to be showing Columns UI. If that's the case this is not related to foobar2000 v2.x in any way. User interfaces handle all UI related rendering on their own.

Also you didn't comment if you are using custom themes. Your seekbar doesn't look the way it does natively on Windows 10. If a uxtheme hack or custom third party skinning program causes rendering issues, it's not Columns UI's problem.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #5 –
Was using Columns UI 2.1.0-beta.3. Even delving further into the game and switching tabs and seeking tried with vanilla fb2k first then updating Columns UI to 2.1 and couldn't reproduce the result in both. My OS is using Classic Shell. https://www.filehorse.com/download-classic-shell/#screenshots

Funny that, 2.1.0 current version, released on: 2023-09-30
2.1.0-beta.3 released on: 2023-07-24
Only now that I switch I see the seekbar looks noticeably different, definitely had me looking more so at the columns for Columns UI. Malfeasance averted. The components don't nag so I stick with the betas, but then it is further upon me to know where the problem originates.

Judging from the update log, I am not too confident it's fixed. https://github.com/reupen/columns_ui/blob/main/CHANGELOG.md

So now this thread is about Columns UI.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #6 –
I'm not sure those drop-down toolbars look like normal Windows 10 appearance either. If you have something installed that is interfering with the Windows theming APIs, then it could be causing the problem. (Also, Classic Shell hasn't been updated since 2017. Evidently, Open Shell is the successor. Did you mean Classic Theme perhaps?)

If you seek using the commands under Shift+File/Playback/Seek (in the main menu), does the problem occur?

What is the scaling percentage set in Windows display settings?

Are these full-screen games triggering a resolution change?

Also, post a list of third-party components installed from Preferences/Components/Copy report.

Otherwise, disable whatever is altering the Windows theme and see if it still happens.
.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #7 –
Classic Shell impacts basically everything after all Aero was standing on par with the classic theme. I have some custom colors set from Windows's Settings\Theme. This linked webp should be proof enough. With the Columns UI 2.1, I was seeking with the game window active using global keyboard shortcuts to seek 5 seconds while in-game, on the same file, as well as tabbing the rest of the time. But Columns UI 2.1.0-beta.3 all I did was open the game while the file was playing and tabbed a handful of times. 100% scaling, did not bother with other games. But this game I always run lower resolution consistently so unless I went out of my way, I would test other games.

They changed the UX and stuff with tabbing, however "Tabbing" caught my eye, so maybe it's this.

Quote
Internal changes
The component is now compiled using foobar2000 SDK 2023-05-10. [#799]

The component is now compiled with Visual Studio 2022 17.7.

Now I am 99% sure it is fixed

I'm messaging a mod to recategorize it as 3rd Party Plugins - (fb2k)

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #8 –
Why are you using Classic Shell? It's too old. Currently, Open Shell is common.
http://www.classicshell.net/

This is not the solution to your problem.
SHURE SRH1840, SENNHEISER HD660S2, SENNHEISER HD620S, SENNHEISER HD 490 Pro Plus, beyerdynamic DT 1990 PRO, HiFiMAN Edition XS, Bowers & Wilkins P7, FiiO FT5, 水月雨 (MOONDROP) 空鳴 - VOID, Nakamichi Elite FIVE ANC, SONY WH-ULT900N (ULT WEAR) (made a Upgrade/Balanced Cable by myself)

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #9 –
1% probability triggered, forcing a contingency plan. Found a way to replicate the glitch with Columns UI 2.1 and before.

  • Prepare 2 displays with Columns UI 2.1 window maximized in the 2nd display and the game, running a lower resolution than the display, opening in the 1st display in fullscreen mode.
  • Launch the Columns UI 2.1 window and start the file playing at near the end if the draggable thumb will be pushed to the right offscreen, or vice versa, and launch the game in fullscreen mode.
  • Just let the file play or seek using global keyboard shortcuts for a more expeditious desired effect.
  • Tab out/close the game and look at the Columns UI 2.1 window when it comes back onscreen.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #10 –
Reproduced on Windows 11. It can surely only be a Windows bug. However, I have an idea about what might be happening. There may be an easy fix.
.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #11 –
When the game is running, foobar2000 is pushed (at least partially) off screen. Windows does not bother rendering the part of the window that is not visible.

When Alt-Tabbing out of the game, foobar2000 is moved back on screen. However, Windows doesn't bother re-rendering the parts of the window that were previously off screen. Instead, they display as they were when they were last rendered (e.g. before the game was started).

This isn't limited to the seekbar. Even the playlist view will show old state if e.g. the playing track has changed. I've also seen other programs glitch in various ways.

This problem doesn't happen in more common scenarios, like using Win+P to change the monitor configuration.

I can seemingly work around it by making Columns UI redraw the main window when the display resolution changes. However, I'm not sure the resolution change is actually relevant.
.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #12 –
Just from the standpoint of an easy apples to apples comparison Fb2k does not do this when trying to reproduce and changing the user interface module to Default User Interface, and thus the cost benefit analysis of fixing it on this forum is warranted. Also, I happen to know Microsoft wants devs to work in a specific way without spaghetti code. GDI (emphasized software rendering) has been largely replaced with hardware acceleration using DirectX.
https://learn.microsoft.com/en-us/windows/win32/learnwin32/overview-of-the-windows-graphics-architecture

"[GDI] is considered obsolete"
https://www.reddit.com/r/GraphicsProgramming/comments/geq24j/how_windows_handles_basic_gui_rendering_of_its/

This means that basically there is just an accessible backend and once the logic goes out, the render goes in, no miscommunication. Thus, the render may lag, but it always looks right.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #13 –
While the seekbar is not affected in DUI, I can reproduce the same glitching in DUI in other parts of the UI by e.g. using a global shortcut to change the active playlist while the game is running.

CUI only redraws the area of the seekbar where the old thumb was and new thumb will be as playback advances. I can't say how the DUI seekbar is implemented, but if it's redrawing the entire seekbar every time, the problem wouldn't happen.

I can't reproduce the problem without a resolution change, simply because Windows doesn't move windows around if the resolution doesn't change.

I'll probably add the workaround I described. It's a few lines of code, and I'm not seeing much downside (other than masking the original problem).
.

Re: Foobar2000 v2.0 x86 Seekbar rendering issue

Reply #14 –
I don't think it was redrawing the seekbar. Here is the simplex munditis perspective of just an accessible backend. In DirectX when the commands are received, it automatically deletes that particular object (a draggable thumb) with no erase coordinates needed. The object is likely not a raster image but a vector image that the GPU is optimized for. Because there is no tracking of the coordinates, there is no possibility for failure when the graphics happened to be rendered by software at an inopportune time i.e. when it's trying to do the whole job of the GPU, but the GPU is recalculating the display resolution. Some of my screenshots have "vertical sticks" of the draggable thumb for this reason. An attempt was made to delete the old coordinates but the draggable thumb had already moved a pixel. However, if one waited until the GPU was ready it would've deleted all the pixels that belong to the object rather than the dot matrix structure of the object on the display. However, in this case we can see the software still has a bit of of an advantage, though it's misused. Much like a Minecraft chunk rendering offscreen in a stratified way where visual fidelity is less important, that's the software advantage, not the amount of space being rendered. For a slider that is displaying the latest dropdown menu item, it is a bit more software-oriented, as I said it only emphasized software rendering.