An update to my previous post, but dropping priority to “Normal” mode.

General system responsiveness is normal. Handbrake’s average frames per second county thingy now goes to ~8.1 on average with extremes being more like 7.7~9.3, but it pretty well hovers at 8.1.

By contrast, applications like writing this post in a browser are now normal performance. It’s even possible to watch previous encode without glitches and artifacts in the decode. But things like writing this post cause more dips in Handbrake’s frame rate.

Overall, it seems fair to say “High” -> “Above Normal” priority loses 5% if you want a nice round number instead of a range for the average. “High” -> “Normal” priority loses 15% by the same method.

Where “High” = cripples the desktop session, “Above Normal” = makes the desktop session feel a few hardware generations behind, and “Normal” = makes it just another process.

I guess that solves that, lol.

A while back, I remember tuning the default priority in HandBrake’s preferences, back when I made the leap over to HEVC. Mainly because the encode times are so long on my old Core i5-3570K, and because I tend to leave such jobs running overnight.

Well, for curiosity sake I’ve decided to see how monkeying with this changes things a bit.

In my experience, nicing processes on my unix systems is rarely worth the bother. That is to say, a nice system like Linux this side of multi-core processors tends to remain pretty responsive, and most people I encounter screwing with niceness tend to be pissing down the wrong problems to start with. But NT is not unix, nor Linux, so who knows.

Looks like the default priority I had configured was “High”. Task Manager also shows a “Real Time” but that isn’t in the GUI.

Net result is Handbrake proceeds at a pace of roughly 8.9 ~ 9.5 frames per second. Which works out to being closer to 9 than 10. Set to high priority also means that while the encode is running my desktop session is virtually useless, as things like updating UI state takes a back seat to next Tuesday.

After the first item in my queue finished, and the next began: I lowered the priority to “Above Normal”. Impact on encode is roughly 8.9 ~ 8.3 frames per second on the average county thingy. So that’s a performance loss of about 3 ~ 6 percent, but my desktop session is actually usable. UI updates like the process table in task manager now update in something closer to real time than melting an Titanic sized iceberg with a zippo lighter, and general productivity is passable. Typing this post is about on par with running a web browser on an older computer. Small price to pay.

That roughly equates to the encode takes less than five minutes less, if I render my desktop useless until the task finishes. Provided current pace keeps. When the entire encode takes a bit more than an hour per episode, it’s kinda a meh perspective. Also a little nicer seeing my processor bouncing between ~70% and 99% in task manager instead of 97 ~ 99 %, lol.

I’m kind of reminded of XP, and my opinion that it could be very stable if you didn’t do nasty things (or need shit drivers) to it, but being user responsive when under heavy loads it was not. As beautifully as the NT desktop has evolved since then, I still don’t think melting a Windows box is as smart an idea as melting a Linux box, if you’ve really got to melt your system’s load.

When the third file starts encoding, I’ll probably try dropping the priority to normal and see what happens.

First impression of Edge 80, based on Chromium:

“Holy fuck that’s fast”
“Is this powered by nitromethane or something?”

The main reason that I had converted my games machine back to Chrome was thanks to Edge being flaky release to release about my tab change / load habits, which could vary from smoother to an effect like watching the GUI thread block for background tab loads or something. Moving it back to Chrome was mostly to get performance that was consistent.

In the time that I used Edge on that machine, I was otherwise very happy with it as a browser. In fact if they had been more consistent, I probably would not have bothered to change things around.

With the move to a Chromium base, I doubt that there’s much reason to care anymore. The only reason that I’m actually left to care about is the bookmark and history syncs with my Debian machine, and I don’t really do that much with bookmarks anymore. Most interesting history bits can probably be solved by Google’s activity page, since doing anything in Chrome’s history usually rolls as “Gah, crap, I’ll just type a search term”, lol.

Halo’s developers explain what can go wrong with unlocked framerates in old game ports

It’s also worth remembering that these kind of weird ass behaviors and bugs can occur on games  natively developed for PCs. Older games often have to cope with hardware that is faster than anyone imagined, and totally different from what the game was developed on.

A prime problem that comes to mind is the flying APC bug in MW3. On my older Pentium D machine, APCs would often fly up into the air and usually come back down. On my Core i5 machine: they never would come back down, or even be within targeting range most of the time. Which makes it hard to complete some of the early missions, lol. Today you require limiting the CPU speed and emulating a graphics card in software just to render it playable on modern hardware.

In fact, the game was old enough that when my eyes lit up at finding a copy of Mech Warrior 3: the next problem to solve was convincing the clerk to sell it to me because there was no returns welcomed, lol. I seem to recall Pentium 3s and Pentium IIs being high end processors around the time the game was released.

Finding myself in need of something to watch, and skimming through unfinished series in my Crunchyroll queue, I find myself returning to Bodacious Space Pirates. I remember enjoying the first parts of the series because of how technology integrates into the scenery, and the premise being amusing.

Actually, come to think of it, I should have finished this years ago. While the notion of Marika finding herself inheriting a pirate captaincy likely guaranteed the show wouldn’t be boring, having worth while characters, and plenty of humorous action certainly makes it entertaining šŸ™‚.

Check out what I’m watching on Crunchyroll! http://www.crunchyroll.com/welcome-to-demon-school-iruma-kun/episode-22-sparkling-shock-792301

After how last week’s episode ended, I rather love the solution that Iruma, and his friends come up with. I may also have busted out giggling by the time Kuromu finds out what the heck is happening on stage.

iPad Pro -> Laptop mode

ProCase iPad Pro 11 Keyboard Case 2018 [Support Apple Pencil Charging], 360 Degree Rotation Swivel Cover Case with Wireless Keyboard for Apple iPad Pro 11 Inch 2018 Release -Black.

I finally broke down, and gave in, and giving this a shot. There’s the reality, that most of the time I find a tablet an ideal form factor. But it is also a reality that I am not always near a desk or table like surface when it would be effective to have an external keyboard.

Thus far this is looking good. Study enough that I’m not worried about tap-tapity-tap-taping it over, or gravity getting the sudden best of me. Big enough that I can get a decent typing experience, and light enough not to have to remove the tablet constantly. Although to be fair, ease of removing the tablet is one of my goals—most of the time I actually want my tablet to be a tablet, and the lighter the better.

Hitting https://10fastfingers.com/typing-test/english I was able to get a decent result after 10~15 minutes of putting around. 85 words per minute with 91.81% accuracy isn’t a bad first attempt. Close enough to my full typing speed, that it’s more a matter of accuracy and getting used to the keyboard, than it is the actual size.

Which is really nice: because that was my primary fear. See, keyboards for smaller devices have generally been a failure for me. A widescreen 10.1ā€ works pretty well, and 11.6ā€ is probably my idea of the perfect sized keyboard in terms of widescreen. For standard laptops of yore, I usually would vote for the ~12ā€ range. A 7ā€ or 8ā€ tablet keyboard is so small that I am better off using two-thumbed touch screen typing, for both accuracy and speed. A 9.7ā€ iPad size keyboard is too small, but at least approaches a size where I don’t feel like snapping the keyboard in half. Given that sordid history, I’m happy to find that the iPad Pro 11ā€ in this dock, is pretty effective; much like how my old 10.1ā€ systems were big enough to use as a full time keyboard but more error prone than a standard PC keyboard.

Yay, it doesn’t suck!