Android: Use Back to open the emulation menu on all devices

[JosJuice]

https://bugs.dolphin-emu.org/issues/12029

We currently have one way of opening the menu on touch screen devices (swiping down from the top of the screen to bring up the action bar and selecting the menu in the action bar), and another way of opening the menu on Android TV (pressing Back). However, some devices that claim to support touch (or don't support leanback? Dolphin currently conflates the two) don't actually let you swipe down from the top of the screen in the way that Dolphin expects, notably Chromebooks. There are also some phones where you can swipe down from the top of the screen but this for some reason doesn't lead to the action bar becoming visible, though we are getting less reports about this nowadays than in the past.

This change makes us use the Back method on all devices, since it should work on all devices with no significant drawbacks.

[Ebola16]

Now I can easily test this menu while emulating! Some of these critiques aren’t directly related to this PR but they should probably be taken care of before merging this:

• Bringing up the menu then immediately pressing a button on the Wii overlay results in a crash:
  2020-08-06 16:05:17.899 1479-1607/? E/WindowManager: RemoteException occurs on reporting focusChanged, w=Window{16a1341 u0 org.dolphinemu.dolphinemu.debug/org.dolphinemu.dolphinemu.activities.EmulationActivity EXITING}
  android.os.DeadObjectException
  at android.os.BinderProxy.transactNative(Native Method)
  at android.os.BinderProxy.transact(Binder.java:1145)
  at android.view.IWindow$Stub$Proxy.windowFocusChanged(IWindow.java:500)
  at com.android.server.wm.WindowState.reportFocusChangedSerialized(WindowState.java:3951)
  at com.android.server.wm.WindowManagerService$H.handleMessage(WindowManagerService.java:5494)
  at android.os.Handler.dispatchMessage(Handler.java:106)
  at android.os.Looper.loop(Looper.java:214)
  at android.os.HandlerThread.run(HandlerThread.java:65)
  at com.android.server.ServiceThread.run(ServiceThread.java:44)
• It would probably be better to keep the ability to exit emulation by pressing back twice. On phones with large screens (like Samsung Note8), pressing back then pressing exit on the opposite side of the screen is cumbersome. Testing mods or Dolphin itself can require many emulation restarts.
• Pressing “back” then swiping up causes the menu to briefly pop-up and disappear from the screen.
• Rename "Exit" to "Exit Emulation", since it is unclear if we're exiting emulation or the menu.
• I think the space between the game title and first menu option is a little large. Since there are now many menu options it would be better to reduce that space if possible.
• Japanese characters stretch onto second line of game title (tested with R4YJ2M):
  

[JosJuice]

Bringing up the menu then immediately pressing a button on the Wii overlay results in a crash:

I can't reproduce this. (I also can't make sense of the stack trace...)

It would probably be better to keep the ability to exit emulation by pressing back twice. On phones with large screens (like Samsung Note8), pressing back then pressing exit on the opposite side of the screen is cumbersome. Testing mods or Dolphin itself can require many emulation restarts.

The problem with this is that pressing Back currently is the only way to close the menu if you don't have a touchscreen. What do you think about letting a long press of the Back button exit emulation instead?

Pressing “back” then swiping up causes the menu to briefly pop-up and disappear from the screen.

I'm not sure if I understand this issue correctly. If I swipe up in an area outside the menu, the menu disappears like it normally does when I touch an area that's outside the menu. If I swipe up in an area inside the menu, I scroll the ScrollView.

Rename "Exit" to "Exit Emulation", since it is unclear if we're exiting emulation or the menu.

Done.

I think the space between the game title and first menu option is a little large. Since there are now many menu options it would be better to reduce that space if possible.

Done.

Japanese characters stretch onto second line of game title (tested with R4YJ2M):

It looks to me like the title in your screenshot is just barely longer than what fits on one line. Isn't it normal to put the last part of the title on a second line in that case?

[Ebola16]

The last two added commits LGTM.

I can't reproduce this. (I also can't make sense of the stack trace...)

Sorry, these are the correct steps to reproduce the crash:

1. Bring up the menu by pressing back
2. Rapidly tap outside of the menu

The problem with this is that pressing Back currently is the only way to close the menu if you don't have a touchscreen. What do you think about letting a long press of the Back button exit emulation instead?

That's fine and we should probably have a "Long press back to exit" toast appear when initially pressing back so users are aware of this feature.

I'm not sure if I understand this issue correctly. If I swipe up in an area outside the menu, the menu disappears like it normally does when I touch an area that's outside the menu. If I swipe up in an area inside the menu, I scroll the ScrollView.

I should clarify, this all needs to be done in one fluid motion:

1. Press the back button (don't let go)
2. Swipe upwards off the back button
3. Stop pressing.

You'll see the menu very briefly pop-up, which doesn't look great. But now that I think about it I'm not sure if we can reasonably do anything about this...

It looks to me like the title in your screenshot is just barely longer than what fits on one line. Isn't it normal to put the last part of the title on a second line in that case?

Yes but I think there is room to fit that title on one line without changing the size of the menu. Couldn't we extend text_game_title to come closer to the edges of the menu?

[JosJuice]

Sorry, these are the correct steps to reproduce the crash:

1. Bring up the menu by pressing back
2. Rapidly tap outside of the menu

Well, I've reproduced some sort of crash:

java.lang.IllegalStateException: Fragment MenuFragment{6890c56 (0e07e28b-3be0-4b0a-ab94-3e9fdacf2d0b) id=0x7f0a00c8} did not return a View from onCreateView() or this was called before onCreateView().
        at androidx.fragment.app.Fragment.requireView(Fragment.java:1699)
        at org.dolphinemu.dolphinemu.activities.EmulationActivity.pressedOutsideFragment(EmulationActivity.java:1100)
        at org.dolphinemu.dolphinemu.activities.EmulationActivity.dispatchTouchEvent(EmulationActivity.java:1115)
        at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:69)
        at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:434)
        at android.view.View.dispatchPointerEvent(View.java:13708)
        at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:5499)
        at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:5302)
        at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4805)
        at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4858)
        at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4824)
        at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:4964)
        at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4832)
        at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5021)
        at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4805)
        at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4858)
        at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4824)
        at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4832)
        at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4805)
        at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:7528)
        at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:7497)
        at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:7458)
        at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:7653)
        at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:189)
        at android.os.MessageQueue.nativePollOnce(Native Method)
        at android.os.MessageQueue.next(MessageQueue.java:336)
        at android.os.Looper.loop(Looper.java:197)
        at android.app.ActivityThread.main(ActivityThread.java:7441)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:935)

This crash should be fixed with the latest push.

That's fine and we should probably have a "Long press back to exit" toast appear when initially pressing back so users are aware of this feature.

I have added the long press functionality. However, I haven't added the toast, because I'm not yet sure if this is something worth nagging users about every time they use the menu, since this is a feature I believe most users don't need. But you are correct in that this feature will have zero discoverability if we don't point it out somehow...

EDIT: Actually, never mind, the long press detection doesn't work at all. I'll look into this more tomorrow.

I should clarify, this all needs to be done in one fluid motion:

Press the back button (don't let go)
Swipe upwards off the back button
Stop pressing.

You'll see the menu very briefly pop-up, which doesn't look great. But now that I think about it I'm not sure if we can reasonably do anything about this...

Reproduced. I think these steps are "unusual" enough that it isn't really a big deal.

Yes but I think there is room to fit that title on one line without changing the size of the menu. Couldn't we extend text_game_title to come closer to the edges of the menu?

We could decrease the margin on the right, but I think it looks odd to have a smaller margin on the right than on the left. I don't believe it would be a good idea to decrease the margin on the left, because Google suggests horizontal margins of 48dp (5% of the screen) at the left and right edges of the screen on Android TV to compensate for overscan, which is actually more than the current 32dp.

[JosJuice]

Fixed the long press detection issue. dispatchKeyEvent was eating the event.

[Ebola16]

New problem. After long pressing to end emulation, a game cannot be launched afterwards, probably due to the check from #8860. This does not occur with the "Exit Emulation" menu option.

This crash should be fixed with the latest push.

The crash was fixed.

I have added the long press functionality. However, I haven't added the toast, because I'm not yet sure if this is something worth nagging users about every time they use the menu, since this is a feature I believe most users don't need. But you are correct in that this feature will have zero discoverability if we don't point it out somehow...

Could we add "Long press back to exit" to emulation_menu_help instead?

Reproduced. I think these steps are "unusual" enough that it isn't really a big deal.

Agreed, feel free to ignore that point.

We could decrease the margin on the right, but I think it looks odd to have a smaller margin on the right than on the left. I don't believe it would be a good idea to decrease the margin on the left, because Google suggests horizontal margins of 48dp (5% of the screen) at the left and right edges of the screen on Android TV to compensate for overscan, which is actually more than the current 32dp.

I'm fine with not changing the left margins but I still think we should use the space we have for the title to maximize the number of settings on the screen. Could we change text_game_title's android:layout_width="match_parent" to android:layout_width="218dp" or a similar dp value?

[JosJuice]

New problem. After long pressing to end emulation, a game cannot be launched afterwards, probably due to the check from #8860. This does not occur with the "Exit Emulation" menu option.

So guess what? I actually noticed and fixed this yesterday, but forgot to commit it before pushing. I guess that's what happens when you try to code right before going to bed :)

It should work with the latest push.

Could we add "Long press back to exit" to emulation_menu_help instead?

Hmm... I don't know... It's partially that I don't want to make any particular toast too long (you only have a limited number of seconds to read them, and not everyone is fluent in English) and partially that I don't want users to think that that's the only way to exit and that they need to memorize that a long press is how you exit.

I'm fine with not changing the left margins but I still think we should use the space we have for the title to maximize the number of settings on the screen. Could we change text_game_title's android:layout_width="match_parent" to android:layout_width="218dp" or a similar dp value?

218dp is 250dp minus 32dp, so... You're essentially suggesting to make the right margin 0dp? That would look pretty bad.

I tried changing the right margin to 24dp, which I believe would provide just enough room to fit your title on one line and which provides enough room to fit "The Legend of Zelda: The Wind Waker" on two lines, and it didn't look too ugly, but it did still look a little odd.

Keep in mind that no matter where we draw the line for how wide the title should be, there'll always be some title that needs just a tiny bit more space to take up one line less. We have to draw the line somewhere, and I believe the most sensible line to draw is making the right margin equal to the left margin.

[Ebola16]

It should work with the latest push.

It does. You've seen some of my silly sleep-deprived comments firsthand too lol.

Hmm... I don't know... It's partially that I don't want to make any particular toast too long (you only have a limited number of seconds to read them, and not everyone is fluent in English) and partially that I don't want users to think that that's the only way to exit and that they need to memorize that a long press is how you exit.

I still think the worst option is to not mention this at all. The two sentence toast that some people may miss is a good option here. We're changing the way Dolphin responds to back presses so prior users will be confused without the toast. The message also appears at emulation start so people will have multiple chances to see it. Technically this also helps with accessibility as pressing "Exit Emulation" on a large phone can involve tapping opposite edges of the screen, so users should know about it. And we can rephrase the added sentence to "Long pressing back will exit emulation.", making it sound less like the only option. Even if a user misses the message, they'll still see the "Exit Emulation" option when pressing back.

Keep in mind that no matter where we draw the line for how wide the title should be, there'll always be some title that needs just a tiny bit more space to take up one line less. We have to draw the line somewhere, and I believe the most sensible line to draw is making the right margin equal to the left margin.

EDIT: I forgot that margins can be different for left and right. Although it doesn't look as pretty in the Android Studio layout editor, I think this looks better in game than the previous screenshot.

[JosJuice]

I still think the worst option is to not mention this at all. The two sentence toast that some people may miss is a good option here. We're changing the way Dolphin responds to back presses so prior users will be confused without the toast. The message also appears at emulation start so people will have multiple chances to see it. Technically this also helps with accessibility as pressing "Exit Emulation" on a large phone can involve tapping opposite edges of the screen, so users should know about it. And we can rephrase the added sentence to "Long pressing back will exit emulation.", making it sound less like the only option. Even if a user misses the message, they'll still see the "Exit Emulation" option when pressing back.

I'll add it to the toast.

But I'm not talking about changing the margin. I just want to change text_game_title's android:layout_width, which will keep the title left-aligned with the menu options. android:layout_width="202dp" produced the screenshot below. Although it doesn't look as pretty in the Android Studio layout editor, I think this looks better in game than the previous screenshot.

That effectively changes the right margin. The screenshot you just posted has less than 32dp of space between the end of the text and the end of the menu, if you include the empty space of the ｉ. The reason why this looks fine in this specific case is because fullwidth ｉ has a lot of empty space in it, but this reason does not apply to game titles that end in essentially any other character. I don't want to make other titles look worse just to improve the rendering of titles that consist of exactly 9 CJK characters ending in ｉ.

[JosJuice]

I have increased the menu width by 10dp, which should hopefully make it able to fit 9 CJK characters on one line.

[Ebola16]

I like all of the changes now. I need to leave but I'll give this a final pass later today.

[Ebola16]

• Save/Load state slots do nothing when tapped.
• Previously, swiping from the very top or bottom of the screen would display bars hidden by immersive mode in addition to Dolphin's action bar. I'd like the menu from this PR to also display when unhiding the bars, similar to how the action bar was unhidden, which will make the menu easier to access.
• It would probably be better if the menu options closed the menu upon completion. I'm assuming consecutive menu actions aren't common.
• EmulationActivity's MENU_ACTION_PAUSE_EMULATION and MENU_ACTION_UNPAUSE_EMULATION cases are only called by the old menu. These cases are handled in MenuFragment's onClick override now. We don't need the old menu code anymore, including some of the methods called in those cases. It's also annoying that I can't make a review comment far away from code you've edited.

[JosJuice]

Save/Load state slots do nothing when tapped.

Fixed. Because such a tap is outside of the main menu, Dolphin interpreted it as a command to close the main menu, and it seems like that led to the submenu being closed in the process.

Previously, swiping from the very top or bottom of the screen would display bars hidden by immersive mode in addition to Dolphin's action bar. I'd like the menu from this PR to also display when unhiding the bars, similar to how the action bar was unhidden, which will make the menu easier to access.

I believe that bringing up a UI element that blocks such a large portion of the screen is not a good thing to trigger with an action that the user easily can perform by accident, not to mention that I don't think there's any precedent for apps doing something like this, so it wouldn't be consistent with anything the user is used to. There is also the problem of whether the menu should be dismissed automatically after doing this. Dismissing it automatically would probably make it hard to use (because you'll probably want to read the different options there are before pressing anything), but not dismissing it automatically is inconsistent with everything else that appears when performing the same action. I don't think these problems are worth it for getting rid of one extra tap (and only on touchscreen devices which are not using gestural navigation, at that).

It would probably be better if the menu options closed the menu upon completion. I'm assuming consecutive menu actions aren't common.

Actually, the menu closing after selecting something was one of my biggest annoyance points with the old menu. I think the menu is quick and easy enough to close that this isn't a big problem.

EmulationActivity's MENU_ACTION_PAUSE_EMULATION and MENU_ACTION_UNPAUSE_EMULATION cases are only called by the old menu. These cases are handled in MenuFragment's onClick override now. We don't need the old menu code anymore, including some of the methods called in those cases. It's also annoying that I can't make a review comment far away from code you've edited.

I have removed the redundant code, but in a slightly different way that let me remove the setHasUserPausedEmulation method.

[Ebola16]

• New issue. Selecting "Screen Orientation" and then doing anything that doesn't result in an orientation change causes us to lose sticky immersive mode.
• New Issue. When saving a state, a blank OSD message box usually appears and disappears before showing the successful save OSD message. It appears when the "Saving State..." OSD message is expected but the message box is much larger than that. Easier to reproduce by saving the state multiple times.
• New Issue. A "State not found" OSD message should be shown when attempting to load from an empty slot.

Fixed. Because such a tap is outside of the main menu, Dolphin interpreted it as a command to close the main menu, and it seems like that led to the submenu being closed in the process.

Nothing happens when save slots are tapped in portrait mode still. Landscape mode appears to work now.

I believe that bringing up a UI element that blocks such a large portion of the screen is not a good thing to trigger with an action that the user easily can perform by accident, not to mention that I don't think there's any precedent for apps doing something like this, so it wouldn't be consistent with anything the user is used to. There is also the problem of whether the menu should be dismissed automatically after doing this. Dismissing it automatically would probably make it hard to use (because you'll probably want to read the different options there are before pressing anything), but not dismissing it automatically is inconsistent with everything else that appears when performing the same action. I don't think these problems are worth it for getting rid of one extra tap (and only on touchscreen devices which are not using gestural navigation, at that).

Fair points, drop this suggestion.

Actually, the menu closing after selecting something was one of my biggest annoyance points with the old menu. I think the menu is quick and easy enough to close that this isn't a big problem.

I think we'd only want to keep the menu open if a user is likely to select multiple menu options. Are there common reasons to do this? If not I don't see a reason to keep the menu open.

I have removed the redundant code, but in a slightly different way that let me remove the setHasUserPausedEmulation method.

That part LGTM.

[JosJuice]

New issue. Selecting "Screen Orientation" and then doing anything that doesn't result in an orientation change causes us to lose sticky immersive mode.

Fixed.

New Issue. When saving a state, a blank OSD message box usually appears and disappears before showing the successful save OSD message. It appears when the "Saving State..." OSD message is expected but the message box is much larger than that. Easier to reproduce by saving the state multiple times.

Reproduced, but I have no idea why this PR would cause it to happen or what to do about it. It also seems like it happens for just one frame.

New Issue. A "State not found" OSD message should be shown when attempting to load from an empty slot.

There is such an OSD message, but it ends up being entirely obscured by the menu. Not sure what the best solution is here...

Nothing happens when save slots are tapped in portrait mode still. Landscape mode appears to work now.

Fixed. I was trying to compare coordinates that were relative to frame_submenu to screen coordinates (or to coordinates relative to the activity's root view? They're the same in practice). This actually also led to problems in landscape mode, but not with the leftmost savestate slots.

I think we'd only want to keep the menu open if a user is likely to select multiple menu options. Are there common reasons to do this? If not I don't see a reason to keep the menu open.

I can't think of a specific scenario where it would be common to want to change two settings in a row. But sometimes I need to look around in the menus (well, only really the overlay controls menu...) to remember what options are available, and I believe it's useful for that. And every user has to go through the options at least once if they want to know what options there are.

[Ebola16]

Reproduced, but I have no idea why this PR would cause it to happen or what to do about it. It also seems like it happens for just one frame.

Ok since it's a minor graphical bug that doesn't need to block this PR.

There is such an OSD message, but it ends up being entirely obscured by the menu. Not sure what the best solution is here...

Oh, that problem was actually the save slot not responding to taps, which has been fixed.

I can't think of a specific scenario where it would be common to want to change two settings in a row. But sometimes I need to look around in the menus (well, only really the overlay controls menu...) to remember what options are available, and I believe it's useful for that. And every user has to go through the options at least once if they want to know what options there are.

If there isn't a common scenario for changing multiple menu settings I still think we should close the menu upon making a selection. This would greatly improve the problem of the menu covering OSD messages. Even though not closing the menu may be slightly more convenient for users to learn what our settings do, I don't think that justifies the additional taps that will always be required to close the menu.
Edit: Pause/Unpause should probably be an exception.

[JosJuice]

If there isn't a common scenario for changing multiple menu settings I still think we should close the menu upon making a selection. This would greatly improve the problem of the menu covering OSD messages. Even though not closing the menu may be slightly more convenient for users to learn what our settings do, I don't think that justifies the additional taps that will always be required to close the menu.

Regarding savestate loading specifically, I believe there may be cases where someone has multiple savestates and doesn't remember slot contains the one they want. The only way to find out which one is which is to try loading all the savestates until they find the right one, which can be done a lot faster if the savestate submenu isn't dismissed after loading a savestate.

I do think the additional taps are justified, since it only requires a single tap on a rather large area of the screen. You can move your right thumb into the position of the A/B/X/Y buttons, tap the screen to dismiss the menu, and then continue playing without having to move your finger to another location.

[Ebola16]

Alright that case makes sense to me. I need to leave my computer soon so I'll give this PR another check today or tomorrow. And this doesn't need to be done in this PR but what do you think about aligning OSD messages to the right side of the screen on Android? I don't know how feasible that would be.

[JosJuice]

I'm not sure if that would be easy or not. But I should be able to make a PR that adjusts the x coordinates of OSD messages while the menu is open, which is probably the better solution anyway.

[Ebola16]

LGTM now although issues should probably filed for:

• When saving a state, a blank OSD message box usually appears and disappears before showing the successful save OSD message. It appears when the "Saving State..." OSD message is expected but the message box is much larger than that. Easier to reproduce by saving the state multiple times. Code in OSD::DrawMessages's for loop is initially triggered once as expected, but eventually becomes triggered multiple times per each OSD message.
• Adjust the x coordinates of OSD messages while the menu is open.

[MANGOM1LK]

I would disagree with the long-press-Back thing since on Android 10 this input essentially does not exist in gesture mode - swiping from the side and holding doesn't do anything, it just waits till you take your finger off the screen and activates a normal Back press

[JosJuice]

I don't see any harm in keeping the option of long pressing even if only some users can use it. Though I guess it is somewhat weird for a toast to mention a feature that you might not be able to use...

[JosJuice]

I've added 32dp of extra space when the navigation bar is at the bottom of the screen.

[Ebola16]

I've added 32dp of extra space when the navigation bar is at the bottom of the screen.

I like this change. I also noticed the four save/load menu options went missing. See the last screenshot.

[JosJuice]

They work for me. You most likely just haven't enabled them in the settings.

[Ebola16]

They work for me. You most likely just haven't enabled them in the settings.

Nevermind, that fixed things. I must have deleted my Dolphin.ini for testing at some point and forgotten about it.

[Ebola16]

LGTM now although issues should probably filed for:

• When saving a state, a blank OSD message box usually appears and disappears before showing the successful save OSD message. It appears when the "Saving State..." OSD message is expected but the message box is much larger than that. Easier to reproduce by saving the state multiple times. Code in OSD::DrawMessages's for loop is initially triggered once as expected, but eventually becomes triggered multiple times per each OSD message.
• Adjust the x coordinates of OSD messages while the menu is open.

Now emulation is easy to exit both with and without gesture navigation thanks to the lower position of "Exit Emulation", which hopefully will be useful for @MANGOM1LK.

With a navigation bar or physical buttons, emulation can be ended by long pressing back or the "Exit Emulation" menu button. Without a navigation bar, a back gesture can be performed and then "Exit Emulation" can be tapped, which is comparable to the old double tap back method.

[Ebola16]

@JosJuice I think I figured out how to make OSD messages adapt to emulation menu visibility and survive orientation changes. Let me know if I should make this a separate PR: Ebola16@c9dd638

Also, I updated the other non-blocking issue. I may get around to testing this further but feel free to solve it before me:

• When saving a state, a blank OSD message box usually appears and disappears before showing the successful save OSD message. It appears when the "Saving State..." OSD message is expected but the message box is much larger than that. Easier to reproduce by saving the state multiple times. Code in OSD::DrawMessages's for loop is initially triggered once as expected, but eventually becomes triggered multiple times per each OSD message.

[JosJuice]

I have a different solution in mind that I believe will work better. I'll create a PR for it once this PR is merged (due to merge conflicts).

[Ebola16]

Can't argue with something that works better, that's fine.

[JMC47]

What's the status of this pull request?

[JosJuice]

I believe both I and @Ebola16 consider this ready to merge.

[JMC47]

After messing around for a bit, I'm very happy with how it performs and I like it a lot more than the old behavior.