ZDoom

FRAME #1 Rendered
FRAME #2 Rendered
FRAME #3 Rendered
     Mouse Event #1 Received by ZScript
     Mouse Event #2 Received by ZScript
     Mouse Event #3 Received by ZScript
     Mouse Event #4 Received by ZScript
PLAYSIM TICK Handled
FRAME #4 Rendered 

     Mouse Event #1 Received by ZScript
FRAME #1 Rendered
     Mouse Event #2 Received by ZScript
FRAME #2 Rendered
     Mouse Event #3 Received by ZScript
FRAME #3 Rendered
     Mouse Event #4 Received by ZScript
PLAYSIM TICK Handled
FRAME #4 Rendered

--- a/src/d_main.cpp
+++ b/src/d_main.cpp
@@ -1215,6 +1215,7 @@ void D_DoomLoop ()
                        }
                        // Update display, next frame, with current state.
                        I_StartTic ();
+                       D_ProcessEvents();
                        D_Display ();
                        S_UpdateMusic();
                        if (wantToRestart)

My point is that the events aren't being sent with the right timings. If the engine is running at 140 FPS, and the mouse is polling at 140Hz (assumed for simplicity though obviously this is likely to be higher), this is roughly what ZScript will currently see:
[code]
FRAME #1 Rendered
FRAME #2 Rendered
FRAME #3 Rendered
Mouse Event #1 Received by ZScript
Mouse Event #2 Received by ZScript
Mouse Event #3 Received by ZScript
Mouse Event #4 Received by ZScript
PLAYSIM TICK Handled
FRAME #4 Rendered
[/code]
Therefore, even though ZScript sees 4 mouse events, it can't actually handle them in a proper way that leads to 140FPS menu rendering - this is especially noticeably on a 144Hz monitor but it's still a problem on 60Hz - in ZForms it ends up meaning that if the user grabs a scrollbar, it won't update as fast as the mouse is moving.
What I'd expect to see is an event order more like this:
[code]
Mouse Event #1 Received by ZScript
FRAME #1 Rendered
Mouse Event #2 Received by ZScript
FRAME #2 Rendered
Mouse Event #3 Received by ZScript
FRAME #3 Rendered
Mouse Event #4 Received by ZScript
PLAYSIM TICK Handled
FRAME #4 Rendered
[/code]
I think this can just be achieved by adding this to d_main.cpp:
[code]
--- a/src/d_main.cpp
+++ b/src/d_main.cpp
@@ -1215,6 +1215,7 @@ void D_DoomLoop ()
}
// Update display, next frame, with current state.
I_StartTic ();
+ D_ProcessEvents();
D_Display ();
S_UpdateMusic();
if (wantToRestart)
[/code]
I've had this in my own local compiled version of GZDoom for a few months now and I don't think it causes any issues.

The bigger question here is, why do you even need the events? The entire menu is an event driven system where you already receive the input data through the proper functions as they happen.

I don't know exactly where this would be characterised between "bug" and "feature request", but essentially I think it's pretty unexpected behaviour that due to the way [c]D_DoomLoop[/c] is written, menus and event handlers don't actually get events such as mouse movement as they happen, but they instead queue up until the ticker is run. Especially now that menus can be run at uncapped framerates with the game still paused, this creates an essentially arbitrary restriction that means that menus can't run as smoothly as they should be able to - 35 FPS is pretty noticeable jerky in some contexts.

It'd be better if things like menus got UI events instantly, so that they can be made as smooth as wanted.