[Interface / Gameplay] - Text, Chat and Game related requests

[Formula350]

Things that I feel might be "Quality of Life" improvements:

TEXT
▶ The ability to Select/Copy/Cut/Find text in all text fields (Chat, Recipe editing, Saves/Tracks, etc). Often times I find myself in need of that simple feature we've all come to expect a piece of software to support. This would be quite beneficial for the chat as well, being allowed to select chat with the mouse, and copy it (ie: to retain a long bit of chat where you've been supplied helpful information that you'd like to save for later). It could also be beneficial when using the recipe editor if you don't want to export it.
[Which wouldn't be needed if the all.macro contained them in a formatted way. Having been a player of Minecraft, I've come to take the YAML format that the server plugins use for granted]

CHAT
▶ Timestamps for the chat, accessible by hovering the mouse over the person's name, as to not clutter up the limited-sized chatbox. It would make referencing things much easier, and wouldn't need to use vague descriptors like "at one point" or "awhile ago". ;)

GAME
▶ The ability to retain more than 100 things in the History. I'm not sure the reason for only permitting such a low number, but if it has something to do with client stability, then I'd say the best solution for that would be to simply make it an option that doesn't show up unless the "Advanced UI" option is enabled as well.
▶ History is not lost when creating a Track.
▶ Radio Box to include the History when creating a Save (which is kept at the end of the save, so that it can be easily cut off when Shared or Uploaded for Scientists)

INTERFACE
▶ Ability to make Selections in the Original interface (native support, not requiring a recipe)
-> If the above is not possible, at least the ability to somehow click on a segment while Rama Map is open so it is made visible. Perhaps making it so what you've Frozen shows up in Rama Map as an easy way to find what you're wanting.
▶ At the end of the day, if nothing else, then something simple like hotkeys toggles. F1 for Original and F2 for Selection (If there are already hotkeys that I've missed, I apologize!)

▶ OpenCL/DirectCompute support? lol But seriously, I have indeed read a number of the threads, dev chats, feedback posts already made on this subject. However, something tells me that accelerating the ED clouds and perhaps the filters would be decently suited for the GPU.
[I had opened up an ED on #1300, set it to max density, no transparency, and it was choppy to rotate (not a slideshow, but still… shouldn't have been like that). My CPU is not a brute my any means, an old A8-3850, but it's decently overclocked and is a true quad-core. Memory performance is twice that of any of the Bulldozer and newer AMD APUs, and I have an R9 390 8GB graphics. Realistically, IMO, it shouldn't have been choppy like that.]
▶ Better (or actual?) Multithreading? Though, I know most dedicated users run multiple instances of the client, I'd much rather take advantage of it all in one instance. By default I'd be fine with it being left as is, to make it easier for those running multi-instance setups, so for those who don't want to I'd just ask for either a Flag to add in for the Shortcut, an in-game Advanced UI triggered option, or just one that's provided in the options file like the "desired_fps".

Thanks for reading! And hopefully I can edit this, as I know I've left out some things.
-Form

(I had half a dozen helpful links, but they kept getting the post flagged as 'spam', and unfortunately I lost them when I had cut them and accidentally put something else in my clipboard… Doh.)

[Formula350]

Something that just came to me, since I know incorporating OpenCL is a far bigger task compared to making code more multi-threaded…

I generally sit with my Task Manager open in the background due simply to my internet connection being so horrible that I need to monitor whether or not there is any traffic, so I know whether or not a page isn't showing due to slow speeds or a stalled connection. Nevertheless, it affords me the ability to also see memory usage and CPU usage. I noticed the latest update to Main did seem to kick up the CPU usage as high as 58% (+3-8%) when using Wiggle –which whether or not that's code better utilizing, or being un-optimized and wasting cycles, I can't say–, that seems to only be the case on puzzles w/o a Filter, where those (like #1302) still fail to break that 50% usage barrier on my computer [Laptop w/ AMD FX-9800p 2.7GHz (up to 3.8GHz Boost), which while running FoldIt it usually operates around 3.0-3.5GHz; affinity set to all 4 cores].

So I was curious why the Filters aren't placed on one or multiple other threads in these cases?

Reasons I think this is a benefit to everyone:
#1 I don't think you can purchase any computer these days off the shelf, assembled or their parts, which have a processor that only has a single thread. Even the $35 knockoff tablets on eBay come with at least dual-core ARM chips, which says a lot IMO.
#2 Puzzles are generally on a short timer to work on them. Most people do not have as much to dedicate in that (what seems to be a) 7-day window of time that they'd need in order to do as good of work on a puzzle as they may like, especially when you consider that there usually are at least 1 other puzzle to work on. With that in mind, when a puzzle has a Filter it means Tools get slowed down, or (as I've noticed in my limited experience thus far) recipes will either A) do their world slower if filters are left on B) are not able to do as accurate of work or still as quickly, when filters are turned off (always having to run them periodically to check).
#3 Tools sometimes won't behave like normal, stalling out suddenly instead of slowing down in point increments as it nears stability. As an example, a Wiggle will often for me cease to progress and elude to having stabilized; however, if I turn it off and then back on, it'll jump up a number of points, doing so every toggle. It's a further detriment to trying to solve puzzles due to the fact you are being given a "false positive" on stability. That means people might progress onward despite it not being the optimal time to do so (unknowingly jumping the gun, if you will).

Counter-arguments to possible reasons not to:
"It's not fair to those with heavily threaded processors" (I read this on an old Dev Chat log, in response to adding OpenCL [except they said "powerful GPUs], but it applies here as well)

• Unless I'm unaware, we're all here for fun, and to help out at the end of the day, not because we're getting monetary compensation. The end-goal is to be able to complete something as quickly and accurately as possible, and so that would only seem to better everyone' ability to do that. Fairness shouldn't really come into the equation at all given it's for science. I would never feel cheated that I wasn't able to produce as high of a score as someone else with a more powerful computer, but I WOULD feel that way if I felt I wasn't able to finish my work due to inefficiencies in the application that leaves the bulk of my system underutilized. HOWEVER, just as well, by leaving thing as it is, one could argue it is currently unfair to those who can't shell out for higher performance hardware even more than it would be if there was better threading, because slower processors aren't able to perform comparatively to other chips on a single-threaded level. For those who will dedicate a Client per Core in order to work on multiple Tracks will then sacrifice some performance, and those who will work with a single Client will be able to utilize their 1-3 (or more in other cases) extra processor cores.

"Rosetta isn't able to utilize [X-number of threads/OpenCL]"

• I do believe OpenCL was added to Rosetta since those threads I read were made debating OpenCL usage (2012-2014), which the reason was that Rosetta didn't posses that ability. Which, fair enough. If it, similarly, does not have good multithreading support as well, then that's definitely something that needs to be done, because with AMD's "Zen" architecture set to debut at the turn of the year, and their server chips available middle of next year, there will be the availability of 64-threaded (32 core) processors and so a dual processor machine would be capable of 128 threads. That's a lot of potential workload. To further up the ante, those same chips will be outfitted with high end GPU on the same CPU package (as in what the top model desktop version have). That will then put high performance OpenCL power within even easier reach for the Rosetta team, as dedicated power-hungry, space-hogging GPUs won't be required.

[Artoria2e5]

Regarding multithreading, I am thinking that local changes like shakes and mutates are probably easier to parallelize than "global" changes like wiggle. And shake and mutate iterations do usually run quite a bit slower than wiggle, so there is a lot to gain.