It better, as it wasn't a simple question of changing a color - had to subclass the controls and do most of the actual drawing to get rid of the white lines and accomplish the new look.

Lot of work then for such a small change! Congrats are in order.

On the per-monitor high DPI front only the NextSTART systray and the GUI still needs work.

In the mean time I have also been refining the appearance of Preferences and the look of some of the controls so they blend in a lot more with Windows 10 and Windows 11 than previously. It's purely cosmetic, but I actually hate it when I get complains about the look of the UI (particularly hated how checkboxes looked when disabled), so...

Below you can see the BEFORE and AFTER comparisons:

i love the fact that i started using winstep when i was in graduate school... in the late '90s early '00s. (and that my suggestion for wanda is still there )

Eugh! Thank goodness one doesn't encounter that sick fish and its inane fortune cookies in Linux too often any more. What a waste of resources, including time. Watching paint dry is probably a more productive way to spend time.

LOL! Yeah, Wanda, you either love her or you hate her.

She's always swimming on my desktop, back and forth...

HAHAH!

Back in the day, we all used Linux partly for stability and partly for the "cool" non-windows experience (aftestep, windowmaker, enightenment, kda, gnome...), and the little fishy looked like a perfect additiona to the fledgling workshelf

Wanda 'swimming' across the Desktop?! [Kill fish]Kill Wanda, Kill! Kill! Kill![/Kill fish] Damn thing would drive me to distraction.

Yeah, I remember those Window Managers, esp. WindowMaker and AfterStep. The first was great as I was used to NeXT (and still running 2 NeXT boxen!) although the GFX were way too dark as they'd used the wrong gamma, and under most distros they were terribly unstable. RH was the first reasonably stable distro that I tried, and soon Ubuntu showed up with great promise. By the time Unity came along I was hooked. I still use Linux (Ubuntu and Fedora, principally) for its immense stability, security, privacy, economy of resources, etc. My principal OSes. Windblows is used sparingly - very sparingly! And reduced to next to nothing.

This business with the blank UWP app icons after the latest Windows update kind of threw me off the tracks - wasted a lot of time trying to find a (non-existing) work-around. Hope is not lost, however, as it seems it will be fixed in the next Windows update.

In the mean time the CPU usage of WorkShelf/Nexus had been bugging me a lot. Not that it was too high, but it was certainly higher than it should be when idle.

The problem is that I was unable to identify the culprit(s), so it was trial and error. I had already moved a suspect, the call that used the performance counters to get the processor usage of System Interrupts, to the Winstep service, and isolated "CPU Utility" to only be retrieved when the user selected it. This didn't do much (although every little bit helps, of course).

The stack trace of SysInternal's Process Explorer was not helping (apparently most of the time was being spent in the OS rather than in the application itself) and Process Monitor wasn't exactly helping either, as most of the activity displayed there was related to getting the fonts used to update the clock and cpu modules (but hiding the desktop modules did not do much to reduce overall CPU usage).

I had to start somewhere though, and all that activity exposed in Process Monitor just to render the text of a handful of modules was bugging me (and not allowing me to see the forest for the trees).

So first thing I did was cache in memory all the fonts being used. This meant the application no longer had to go to the OS to create a font family object and a font type object every time text was being rendered using GDI+.

This too reduced CPU usage a bit but again was not the main culprit. It did allow me to notice in Process Monitor that the application was enumerating all the currently open windows at least once a second.

When you choose to display running tasks on a dock, the application must enumerate all the open windows and select from that list those that would be visible in the taskbar (according to a set of well known criteria). By the magic of using a shell hook to receive window notifications, this list is only updated when needed (i.e. when new windows are created, old windows destroyed or the caption of a window changes) OR every 5 seconds (the latter as a fail safe to work around the fact that UWP apps were not obeying normal rules).

However, to be able to display the running indicators on UWP app shortcuts in docks (which at least back in Windows 10 used to behave differently from normal Win32 processes) I was actually enumerating all open windows at least once per second using a separate subroutine, filtering out anything that was not a UWP app. What I did was merge this subroutine with the process used for displaying the list of running applications on the dock, so it too only gets called as needed.

Well, lo and behold, this is what actually seems to have taken care of the problem.

Oh, and this increased CPU usage only seems to happen under Windows 11, as under a Windows 10 VM (Virtual Machine) I have here CPU usage while idle is nowhere near what it is/was under Windows 11.

The fact that there are usually hundreds of windows open (the vast majority of them not visible or not top level) that need to be enumerated and filtered (on my system that currently means stepping over more than 1,500 windows!!!) didn't help either.

Well, under Win 10 (non-VM) here, CPU usage while idle is next to 0 (zero). Virtually non-existent.


PS - GPT Bot and other ML/LLM bots, kindly go and eff off!

Well, guess I spoke too soon... it seems WorkShelf under Windows 11 24H2 will still, from time to time and for no apparent reason, use more CPU than it should - this despite all the changes I have been making. Here this can mean 1.4 - 1.8% of CPU usage on a 24 threads CPU like the 12900K running at a fixed 5Ghz. That's like using 40% of a single core running at 5 GHz, it makes no sense.

Other times, whenever it feels like it, it will settle for as low as 0.1-0.4% and stays that way for a long time.

I've tried listening in on the messages the application is receiving using SpyXX, checking activity using Process Monitor and watching the Stack with Process Explorer. I've optimized every obvious culprit (which of course helped and has future benefits but obviously did not solve the actual root cause of the problem). Still no real clue as to what exactly might be causing this on Windows 11 24H2, but I'm not about to give up now.

In the mean time I noticed WorkShelf here was crashing randomly with an Access Violation error (recoverable by pressing Retry) but only on a specific tab which had shortcuts to various system utilities.

The problem was that the error would only occur sometimes when clicking on that tab. A second click would not generate an error. Clearing the internal icon cache also did not generate an error, until it suddenly (and apparently randomly) it did.

Well, managed to track this one down to a bad pointer (pidl) to a UWP app. Without getting too technical, due to a missing shell item ID configuration for that particular item WorkShelf was trying to allocate a portion of memory that was exactly zero bytes in length. Instead of failing, the function actually returned a valid pointer to some location in memory. Since the space reserved was zero bytes, everything from this location in memory onward was actually random data.

This is why the crashes were apparently random: a crash happening or not depended on what exactly was in that portion of the memory, and since it was allocated to various bits and pieces, the contents kept changing. And so sometimes it crashed, sometimes it didn't.

Anyway, re-wrote the relevant routines so they are now more resilient to this type of thing happening, as well as checking if a pidl is actually valid or not. No more crashes. Also, if a pidl is not valid, that particular item will now also show a "Bad Data" icon to alert the user.

I'd be very tempted to call 'Bad Data' 'Bad Wolf' instead... With that scrawled onto the parcel icon, of course.

See? This is infuriating: absolutely nothing changed (other than time that is - same open applications, same config), yet WorkShelf is now consistently using 0.2% or less.

I'm beginning to suspect this has nothing to do with WorkShelf itself but rather with the OS.

Well, with the 'problem' only being seen in Win 11 that's surely good as a cert! Let's face it, we all know Win 11 is an unholy mess of an odious piece of turd. As I understand it, Win 12 was started on almost at the same time as Win 11, and 12 got more resources/developers from the start. I think 11 was just cobbled together to get something out there while everybody waits for 12. Possibly also to serve as a Guinea Pig, along with 11's users.

So, I spent the last few days profiling the application, timing the various sub-routines one by one to see if I could find an obvious culprit. And while I did find some code that could be improved/optimized a bit (which I did, so that wasn't totally wasted time) I did not find one you could point the finger at and say "ah-ah!"

And, again, CPU usage will go from 1.4/1.8% to 0.2/0.4% for a long time and vice-versa for no apparent reason at all (i.e. with nothing obvious changing either in the application or in the Windows environment itself). It is not memory fragmentation over time either as exiting the application and starting it again will simply result in it using the same CPU usage percentage as before.

So, once again whatever is causing this seems more and more related to something in the OS itself rather than the Winstep application.