Comment by IIsi50MHz

"The Microsoft Store" app is such a strong example of what happens when nobody cares about performance. It misses UI events most of the time, regardless of what hardware it's running on. Although, in this case, I don't think a Pentium 166MHz would help. The UI event processing is just fundamentally flawed.

<flame=ON>

Usually, but not always, it ignores scroll events while an animation is playing…and hovering over a tile in the list cause a pointless zoom-in animation (the result of which occludes parts of adjacent tiles). Sometimes, the animation won't start immediately, but will still play. To prevent the cannot-scroll-while-animating problem, the only safe place for the mouse pointer is over the scrollbar.

Clicking the (completely invisible) track of the scrollbar has random multi-second delays.

Most of the search filters are hidden by default…and can't be shown without waiting for a slow animation. You can click the show-filters widget over 30 times if you're in a hurry, and still the animation hasn't even drawn the first frame. That delay before it starts means that even if you try to wait, you might click one extra time, and then see both the show-filters animation and then the hide-filters animation…all while none of the rest of UI responds. …And then you might realise you want to refine your search terms…which will reset all filters and re-hide the filter options.

Once you find a tile you want to click, be prepared for another two animation delay: one, if the tile isn't already zoomed in, and another while the app mysteriously animates a slew of placeholders instead of just dumping the items information directly into view. It's slow like a 33.6 moder on a noisy phoneline, but now you finely have details about the item you clicked on maybe 7 to 40 seconds ago.

Now maybe you click a screenshot to enlarge, and decide it wasn't the app for you. You hit your mouse's 'back' button or click the app's strangely tiny (given how freaking huge most of the UI is) back button. Nothing happens. You try again, potentially numerous times…because the app ignores those inputs while a screenshot is enlarged. The app's so unresponsive, it at first doesn't occur to you that no amount of waiting or retrying will help. No, you have to click the little close widget on the opposite side of the window, or 'back' will never mean 'back' again.

You try to go back to your search results. The app eventually responds, but decided to discard that data for some reason and has to play more placeholder animations while reloading it and rediscovering your scroll position.

Then you go into another search result and decide the sidebar of other apps people viewed has some interesting items. These don't have animations on the tiles or any details, so you have to click each one of interest, waiting for more placeholders while imagining modems noises and being outpaced by a Colorado glacier that's crossing the road. And when you page back, the item you just came from does /more/ animations while reloading everything via IP Over Avian Carrier With Quality Of Service.

But when burrowing through the people-also-viewed sidebars, don't go too many layers deep, or when you return to your search results, it will have forgotten your scroll position and turned of your search filters. Ah, time for more UI-blocking animations.

But that's okay, right? Nobody ever made an app that responds in milliseconds to every user input, right? And we all know that doing long, blocking operations on the UI thread is right and holy, right? Even routines single-threaded apps never need to yield to other code blocks or process interrupts, …right?

<flame=OFF>

<meta-flame>

Yes, I have reported this to MS via Feedback Assistant. A few times. No, I don't know why they haven't appeared to do anything about this unshippable pile random bits that somehow slopped out of the Bit Bucket.

"Rectify?" No, the only answer is “Games."

</>