Rather large difference in position between Mouse Pointer and mouse.x mouse.y

Been messing around with RTS stuff, and I realized there is a massive gap between where the windows pointer is, and where mouse.x / mouse.y suggest that it is.

I understood there to be usually only a few frames lag, but it seems to be the same gap, regardless of fps (vsync on or off).

As it stands, it is basically intolerable from the stand point of RTS games (like starcraft). Can anyone tell me the variables the input lag depends on? Is it just the mouse, or does the keyboard have an equal delay? Is it possible to hack around this or does it reside in ther black box of either the construct engine or the web browser?

In the RTS I was developing I can barely notice any mouse lag at all.

I am not sure what you mean. I just tested (sprite set position to mouse.x/y) and the lag is barely noticeable at 60 fps. At higher fps there is practically no lag at all.

In any case the lag can't be more than the duration of one frame, 0.016s at 60 fps.

Does it happen in a blank project?

Yes, it happens in a blank as well. I create a box and then set the box position to the mouse.x/y position.

You can notice it most profoundly when moving the mouse in steady motions at the right speed.

You can add several other objects that are daisy chained to the position of the the first, but set in reverse order so they each lag behind one frame. I use this to get an idea what several frames of lag should look like, but the mouse much further ahead.

Ashley Iʻm curious if there is a particular hardware/software issue then. I donʻt think I would have noticed it if I hadnʻt been playing a lot of sc2 lately. Hopping from sc to construct and it was very noticeable .At some point in history, I knew firefox had less latency than chrome, and Iʻm not sure if that is still true, but I wondered how many layers input has to travel in a construct project being tied to the browser. Constructs input lag on my test, had to be perhaps 1/6 of a second or more, regardless of the FPS being vsynced or not. Whether the project was at 60fps or 22000fps. I wondered if constructs double buffer was daisy chained inevitably to several other double buffers? Iʻll try to get a screen capture when I am next at home.

Further exploration leads me to believe (on the current computer at work) that:

A) Input lag is 2 frames at 60hz. I conclude this by storing the previous mouse coordinates one frame back and extrapolating forward 2x that distance. That position is typically spot on the hardware cursor

b) Changing to unlimited fps, either ticks only or full frames, still results in a 60hz 2 frame lag. So either input is still being polled at 60hz regardless of frame rate, all my mice and track pads only operate at 60hz, or something else is causing this?

ASHLEY. 2 frame lag isnʻt unreasonable, Iʻve got some 40hz and 144hz screens I can test on too and see if that changes things, but so far I am assuming there is a 60hz input buffer? Does construct do its own thing or does it build its buffer on another system?

A) Input lag is 2 frames at 60hz. I conclude this by storing the previous mouse coordinates one frame back and extrapolating forward 2x that distance.

Can you share this test project?

Hey, here is the file: https://drive.google.com/file/d/1yQ01n8EX2RFXmgUoQSiuPWFGU4UcmxMZ/view?usp=drive_link

I misspoke earlier, frame lag is 4, not 2. 2 is reasonable, 4 is a much harder pill to swallow, especially when it is always 4/60ths of a second regardless of actual frame rate.

For me exFrames=2 clearly shows the future sprite ahead of the mouse and exFrames=1 is behind. It only seems approximately aligned with exFrames=1.25, which is weird, as it's not even a whole number.

I'd guess there's both mouse smoothing and different system-specific latencies on both hardware mouse input, system cursor rendering, and presenting frames from apps.

One frame behind would be from double buffering. 2 frames from triple buffering. Guess it’s mostly dependent oh what the browser does, or maybe graphics card settings. No idea if construct does its own buffering on top of that.

Typically games hide the windows cursor and just position the mouse to hide that.

Chrome does have a feature when creating a canvas context to be desyncronized, which lets it bypass a lot of the browser’s renderer to be single buffered, but there seem to be drawbacks such as tearing and I’m not sure if other browsers support it.

No idea if construct does its own buffering on top of that.

Construct does not do any buffering (and so should not add any latency) itself. Any delay comes from the browser or the rest of the system.

I've got 3 macbook airs, and one macbookpro, all at 60hz. I have an asusfx504 at 60hz, an Asusg15 at 144hz, an hp revolve at 40hz, and an assortment of all in one desktops to try some tests on (along with like 100 other computers)

I am not getting the same answers, depending on the device used and browser. Assuming one wants to export the game as a standalone app for windows, I should test using Edge right?

Eitherway, I know chrome has some built in latency but didn't have a clue about the others. What is weird to me though, is how much the future prediction jitters in some cases. I thought it could be related to dt fluctiaitons, but that doesn't seem to fully account for it.

I am going to try to create a setup with a qmk keyboard controlling the mouse so I can get absolutely precise mouse input - though I'll have to account for the lag introduced by the board if that is relevant.

On my fx504 with a 60hz screen:

Firefox definitely does something that bumps the lag up to 4 frames.

On chrome and Edge, I only see 2.

Further update:

This website shows input lag. If you run it on an old browser, you can actually get the lag of your device/setup. As it stands, it confirms that basically all browsers are coalescing input into less frequent events to coincide with framerate.

Incendentaly, I get exactly the same input lag on both chrome and firefox, but while running a construct game on firefox I get 2x the lag. Possibly something wonky going on here.

https://www.vsynctester.com/testing/mouse.html