Retroarch: User interface > Menu Scroll acceleration is backwards

[klepp0906]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

Menu scroll acceleration set to normal results in hyperfast scrolling. Set to fast results in normal speed scrolling. They're flip flopped :)

Expected behavior

Normal to result in normal speed scrolling and fast to result in... fast scrolling.

Actual behavior

See above, the options are reversed.

Steps to reproduce the bug

1. enter settings > user interface > set menu scroll acceleration to normal
2. return to the the playlists and pan across them, take note of the speed
3. return to step 1 and set the speed to fast. repeat step 2.

Bisect Results

[Try to bisect and tell us when this started happening]

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.85 62c2842c86

Environment information

• OS: Win10
• Compiler: [In case you are running local builds]

[im4potato]

Unable to reproduce, works as intended for me.

[klepp0906]

you on windows? using vulkan?

just to be sure i removed menu_scroll_fast = "false" from the cfg

it displays properly as in Menu Scroll Acceleration "normal" shows as above in the cfg.

it flips as well if toggled to fast/true.

the behavior in RA itself tells a different story.

fast is a normal pace/substantially slower pace than went set to normal/default. At that point its blindlingly fast panning.

[im4potato]

I'm using Linux, and tried it with vulkan, no problems. It seems like the Fast option takes slightly longer to reach the speed of Normal but it quickly outpaces it in a long list.

[klepp0906]

I'm using Linux, and tried it with vulkan, no problems. It seems like the Fast option takes slightly longer to reach the speed of Normal but it quickly outpaces it in a long list.

man, a LOT of linux users in these parts. makes me wonder what im missing out on.

that being said, would be far from the first windows exclusive bug. Id even go so far as to say the majority fall under that banner.

also pretty telling ;p

for me (using xmb since i also didnt mention that) there is no "takes slightly longer to reach the speed" its basically Normal = instant incredibly fast cycling through playlists. FAST = what you would assume normal speed should/would be like.

[klepp0906]

just booted up my backup pc. downloaded a fresh one over there. same behavior. a windows exclusive - heard it here first.

[im4potato]

I just tried it with XMB as well, still no issues here. Like you said, might be exclusive to Windows.

[klepp0906]

I appreciate you being thorough :) Unless the same guys are working on both sides of the fence, that at least saves the linux guys any hassle

[i30817]

Bugs that occur 'only on windows' are still probably major bugs in linux that are the likely result of undefined behavior and probably just waiting for the right stack configuration (it's random nowadays) to smash linux too. And it's not like there are a lack of linux-exclusive bugs either.

The situation would be better if libretro or RA was rust but spilled milk from 10 years ago to run on consoles and windows 98. Lacking that, RA/libretro should run ubsan and a fuzzer regularly on all platforms it builds for but i haven't see a effort done for that either. If you think windows is bad, you probably haven't looked at the bug list for the consoles, for ifdef code that almost never gets executed outside the consoles built of very old and dodgy non-maintained compilers.

[jdgleaver]

The behaviour here is correct and consistent across all platforms.

Normal scrolls rapidly but has essentially a fixed speed, and only increments by one entry at a time.

Fast starts scrolling slowly, then accelerates and accelerates until it is much faster than Normal, jumping many entries at a time.

The original comments about this are here: https://github.com/libretro/RetroArch/pull/10239

[klepp0906]

ha, interesting.

normal results in unabated, faster than you can even see perpetual scrolling. very fast.

fast results in much slower scrolling, and there isnt really much acceleration involved. it never remotely approaches the speed of the "normal" setting.

normal seems to go from 0-100 over the course of .5 seconds.
fast seems to go from 0-50 over about the same.

perhaps its a wording issue but there is no perpetual acceleration etc on fast. or perhaps its a windows only bug and thats where the issue report is meant to point at? I thought maybe it was due to using my keyboard so i just connected my controller, same business.

Tried on another pc with a fresh retroarch install with 0 configured. same business.

I question the naming (influenced by the functionality if it is deemed broken as im experiencing it) and i question normal (hyper fast) being the default (again, in the context in which im experiencing it).

Of course you guys are the captains of this ship and i know you dont make your decisions willy nilly so if you determine theres nothing to be done regarding functionality, naming, or defaults - im more than okay.

Still i held a single direction for over 30 seconds with 40 playlists and it wasnt skipping entries nor going any faster at 30 seconds than it was at 3 (on fast).

i can record some video if you'd like. but the tldr is normal = super fast. fast = slow.

[klepp0906]

ahah!!

discovery.

so the setting. It effects (in xmb) traveling vertically through settings or playlist entries as you've described.

the confusion stems from the way its functioning traveling horizontally where its functioning as I described, and does not jive with the setting and its naming.

so, i'd argue your naming is accurate relative to the setting and its functionality. The problem lay with it not only not functioning in the same way horizontally, but in a matter in which is counter intuitive to the way the setting is named.

behavior should probably be in parity between vertical/horizontal scrolling.

the alternatives are a separate setting for horizontal scrolling, removing its effect on horizontal scrolling entirely (though i presume it was supposed to include that as well), or it works that way on linux and its another glorious windows bug ;p

[jdgleaver]

Ah, now that is a good discovery! I was only ever looking at vertical lists (never use XMB normally), so didn't notice the horizontal scrolling discrepancy. I guess the guy who added this feature didn't notice it either...

Yeah, that's a bug on all platforms, and it needs fixing :)

I'll try to have a poke at it later... (I expect it may be troublesome...)

[klepp0906]

i feel much better. im so darned anal about polish and ocd about things not working as intended that i always get concerned when i open an issue report. I feel like i open so darned many.

i dont want to clutter things up. I dont want to increase workload. I certainly dont want to add an issue that isnt actually an issue.

Vindication! fortunately its not the case this time lol.

[i30817]

Open as many as you want, it's not like you can make the program worse by opening too many, just possibly better. Expect to be a bit disappointed at times though, since 1500 open bugs and multiple ports mean many slip through or can't be reproduced.

[klepp0906]

no i get that. im wholly realistic and objective when it comes to expectations. Im acutely aware of the scope of what you guys do.

all things considered, there are VERY few that id consider approaching major and VERY few that stay perpetually unresolved.

i have a handful im watching longterm but in my experience most things are rectified rather quick. Its impressive.

thanks for the kind words though <3

[jayare5]

Hey, I thought I'd join the comments here since I am actually the one who had opened an issue requesting that this behavior was added to RetroArch. :P

(See here: https://github.com/libretro/RetroArch/issues/9980)

What happened as a result of this is that "Menu scroll acceleration" got added to RetroArch, with Normal being the new behavior I requested, and Fast being the old one for those who would rather stay with that one instead.

That being said, I do not code at all and don't know how RetroArch is made, but I will make some assumptions... it's possible that the horizontal scrolling speed of RetroArch is global, meaning it is the same as changing values, and also the same as the OZONE's left hand menu (even though that's a vertical menu). If you open RetroArch with OZONE menu, you will have 2 sides: On the left, there's Main Menu, Settings, Favorites, etc. while on the right, there's Load Core, Load Content, Load Disc, etc.
These 2 sides need to be consistent in speed. With "Normal" mode, they behave perfectly fine and alike. However, switch to "Fast" mode, and both the left and right will be inconsistent. The left will move how the XMB moves horizontally, and the right will move how the XMB moves vertically. With "Normal" mode, the horizontal XMB speed seems faster than one would think it needs to be (the behavior you actually opened this issue for), but it is actually the same as what OZONE was doing vertically, it just looks faster because you're scrolling through big icons rather than through entries in a list. Interestingly, if you use a PS3 or PSP, it will also look this this fast when you browse horizontally. So this is at least consistent with Sony's XMB menu and it makes every other menu driver have consistent speeds on all menus.

Yeah, it would be ideal if a user could go in the menu and change the horizontal travel speed of the XMB exclusively for the main menu and not the speed of changing values or anything else that requires left/right. Would probably need a changeable value from 1 to 10 or something, with 10 being the current speed, that way it wouldn't interfere with any other menu behavior and you would have your desired XMB horizontal speed, which honestly wouldn't be a bad thing at all! I just dont know if that would be possible.

By the way, I do think that changing values with left/right at this speed is a lot nicer now than it was with the old slower horizontal speed of "Fast" mode. It used to drive me crazy when I wanted to change the video resolutions / viewports. For now, switching to Fast mode is the only way to fix it, just know that this is how RetroArch used to behave for many years!

[jdgleaver]

Okay, I spent some time looking at this, and unfortunately it's not really possible to set the horizontal navigation speed independently from the Menu Scroll Acceleration setting. The best I could do is this: #10628

I hope that at least makes tab navigation in XMB somewhat rational again...

[klepp0906]

thank you for the update :) you can only do what you can do. I certainly trust that if it were possible you would have made it happen. Whatever you could do is good enough for me <3

as always appreciate your time and work on it!

[jayare5]

Hey, I tested the update, and it works!!
The horizontal scrolling in the XMB is now easy to see with the normal Menu scroll acceleration!!
Everything else also works great, like when you change values with left/right, I feared it would now be slow because of this, but it is unaffected :D