X forwarding lags terribly in Windows ME but not Windows 98 due to behavioral differences in Message Queue processing

[Kahenraz]

This is kind of an obscure bug that I found today while looking to compare X server performance differences between Windows 98 and Windows ME. What I found was that windows forwarded to my local X server on Windows ME lagged horribly and were unusable. I finally found the problem to be related to the Message Queue processing when I noticed that the progress animation for page loading in a web browser would stop when mouse input was idle. If I moved the mouse randomly around on top of the X window, I could force the queue to process and the loading animation would continue-- until I stopped moving the mouse.

I can reproduce this issue most obviously by forwarding glxgears, which periodically reports how many FPS is rendered to the frame buffer. On Windows 98, it would average about 50 FPS, with no change if I were to move my mouse around on the window. But in Windows ME, it would only update at 5 FPS when idle, and upwards of 200 FPS when directly manipulated with the mouse. I don't know if this 200 FPS is correct or some kind of anomaly, as the display output was choppy and inconsistent, with no way to verify this performance metric.

I tried installing the Windows ME Service Pack 1.05 to see if it contained a fix, but there was no change in behavior. I don't know what is causing this issue, so I'm having trouble pursuing any meaningful workaround.

Is anyone familiar with this issue with message processing in Windows ME or know of a possible workaround?

 

 

 

Edited July 23, 2022 by Kahenraz

[jumper]

Throttle the window update rate to prevent queue saturation.

 

[Kahenraz]

What makes you think that it's saturated? If this were the case, I would think that the window would become unresponsive. The issue seems to be that the queue isn't being pumped, or is being left idle for some reason due to an overly aggressive optimization gone wrong.

I don't know why this is an issue specifically with Windows ME and not Windows 98.

Edited July 23, 2022 by Kahenraz

[Goodmaneuver]

10 hours ago, Kahenraz said:

I could force the queue to process and the loading animation would continue-- until I stopped moving the mouse.

Look at your 16 bit CPU usage https://msfn.org/board/topic/183777-how-to-debug-out-of-memory-issues-in-windows-9xme/?do=findComment&comment=1222522 it is 100%. Mine does not do it and that could be a clue as if you move your mouse the 100% will drop.

Edited July 24, 2022 by Goodmaneuver

[Kahenraz]

There is no issue with this on Windows 98 when processor usage is at 100%. CPU usage actually increases when the mouse is moved, since it has to send and process WM_MOUSEMOVE messages and possibly others. When the mouse is idle, less CPU activity is present.

Edited July 24, 2022 by Kahenraz

[jumper]

Posted messages have different priorities. Draw messages are higher than paint messages. Too many draws will block painting, sometimes until another action causes a paint message to be sent.

 

[Goodmaneuver]

6 hours ago, Kahenraz said:

When the mouse is idle, less CPU activity is present.

CPU should be showing zero though when idle.

 

[Kahenraz]

There are other processes running. I used for term idle in this context to illustrate that I wasn't moving the mouse.

Edited July 24, 2022 by Kahenraz