Gambatte palettes notifications are not synchronised with the currently selected palette (Linux / SDL1.2 / RGUI)

[schmurtzm]

Description

(This is a copy of this issue made on the Gambatte repo, I think that it finally more about the frontend).

Since this pull request : libretro/gambatte-libretro#204 , it is possible to switch between gambatte palettes via RetroPad L/R that's very nice and works well but when using RGUI on Miyoo Mini (a little linux handheld) each notification doesn't not override the previous one.
So if you change quickly 5 palettes you'll see previous palettes names on notifications and you don't know which is the current one. This little problem is very annoying to choose your palette.

One Retroarch for Windows the notifications toasters are not the same and each new palette notification override the previous one in the right way.

A little video to illustrate (I press 3 times R and 2 times L)

2022-10-20.23.23.550874.mp4

As you can see the notifications are late.

(I have hesitated to create this issue in Retroarch repo as the callback to enable cores to notify is in Retroarch I'm not very sure.)

Expected behavior

As on retroarch for Windows the new notifications for gambatte palettes should override the previous one.

Actual behavior

On RGUI, each notification is displayed for a determined time so the current selected palette is not synchronised with the current notification.

Steps to reproduce the bug

1. Use RGUI with old notification style (linux notification style ? Or is it related to SDL 1.2 ?)
2. run gamebatte core
3. press L and R multiple time to observe the lack of synchronisation

Version/Commit

You can find this information under Information/System Information

• RetroArch: [version/commit]
  10.0.0

Environment information

• OS: Linux on Miyoo Mini
• Compiler: GCC, SDL 1.2

[LibretroAdmin]

I asked jdgleaver about this and this is what he said...

Right - so the core is sending a RETRO_ENVIRONMENT_SET_MESSAGE_EXT of type RETRO_MESSAGE_TYPE_NOTIFICATION_ALT, but that platform doesn't have widget support. So it's falling back to sending the message via a regular runloop_core_msg_queue_push():

RetroArch/runloop.c

Lines 1842 to 1875 in 29fd4c1

	#if defined(HAVE_GFX_WIDGETS)
	/* Handle 'alternate' non-queued notifications */
	case RETRO_MESSAGE_TYPE_NOTIFICATION_ALT:
	{
	video_driver_state_t *video_st =
	video_state_get_ptr();
	dispgfx_widget_t *p_dispwidget = dispwidget_get_ptr();
	if (p_dispwidget->active)
	gfx_widget_set_libretro_message(
	msg->msg, msg->duration);
	else
	runloop_core_msg_queue_push(
	&video_st->av_info, msg);
	}
	break;
	/* Handle 'progress' messages */
	case RETRO_MESSAGE_TYPE_PROGRESS:
	{
	video_driver_state_t *video_st =
	video_state_get_ptr();
	dispgfx_widget_t *p_dispwidget = dispwidget_get_ptr();
	if (p_dispwidget->active)
	gfx_widget_set_progress_message(
	msg->msg, msg->duration,
	msg->priority, msg->progress);
	else
	runloop_core_msg_queue_push(
	&video_st->av_info, msg);
	}
	break;
	#endif

So it's just going on the message queue, and each message is just getting rolled out as the list is processed
Since the non-widget implementation only has one line where anything can be displayed, you are incredibly limited there. I guess one (lame) option would be to make RETRO_MESSAGE_TYPE_NOTIFICATION_ALT take the RETRO_MESSAGE_TYPE_STATUS path, which should force the current (most recent) message to be displayed. That might do in the short term.
But for a better experience, you might want to experiment with having multiple text locations for the non-widget builds - i.e. keep the line at the bottom of the screen for the message queue, but have another line at the top for status/alt messages. The main issue there is implementing it for all the platforms....
Hmm... Well, why not try the RETRO_MESSAGE_TYPE_STATUS path option first, and see what it looks like?

[schmurtzm]

Thanks for the feedback !
Does it means that I can modify it here : https://github.com/libretro/gambatte-libretro/blob/master/libgambatte/libretro/libretro.cpp#L607
by replacing RETRO_MESSAGE_TYPE_NOTIFICATION_ALT by RETRO_MESSAGE_TYPE_STATUS and make a try ?

[LibretroAdmin]

you can try yes.

[schmurtzm]

For the platforms which doesn't have widget support replacing RETRO_MESSAGE_TYPE_NOTIFICATION_ALT by RETRO_MESSAGE_TYPE_STATUS is perfect. The result is the one expected : each new palette notification override the previous one 👍🏻 . The notification stays at the same position (bottom left) as in my initial video. So the short term solution is OK for platforms without widget support. Thanks for the advice.

On Windows (with widget support) it's not bad but it change the place where the palette notification is displayed :