HTML Element has a camera-speed-dependent position delay

Hello,

I am experiencing a synchronization issue between the official HTML Element object and the Construct canvas when the camera moves.

The HTML element appears to lag behind its expected position. The faster the camera moves, the larger the visible offset becomes. When the camera stops, the HTML element returns to the correct position.

This looks like a temporal synchronization issue rather than an incorrect coordinate calculation:

visible offset ≈ camera speed × update delay

Minimal reproduction setup:

A Sprite and an HTML Element at exactly the same position and size

Both objects are on the same layer

Layer parallax: 100, 100

Layer scale rate: 100

Layer angle: 0

Z elevation: 0

Simple HTML content:<div style="width:100%;height:100%;background:red"></div>

No additional CSS classes or effects

V-synced framerate

Camera moved continuously across the layout

I also tested the project with Use worker enabled and disabled, but it did not change the result.

The Sprite remains correctly synchronized with the camera, while the HTML Element visibly trails behind it. The problem becomes much easier to see at higher camera speeds.

It seems that the WebGL canvas and DOM overlay may be updated or composed at slightly different times.

Is this a known limitation of the HTML Element plugin or the browser composition pipeline? Could Construct compensate for this internally, or update the DOM container at the same stage as the canvas camera transform?

A speed-based prediction could reduce the issue, but an engine-level solution would probably be more reliable because Construct knows the exact camera position and rendering timing.

Thank you.

So testing with the button object...

With workers on setting the position every tick will be 2 frames behind.

Turning workers off improves it to be only 1 frame behind.

So if you can predict where an object will be a frame in advance then you can compensate.

For example

every tick:
-- sprite: set x to 320+200*sin(200*time)
-- button: set x to 320+200*sin(200*(time+dt))

I'm not sure it's possible to resolve this with current browser technology. The browser appears to present the canvas and rest of the HTML page at different times, and there doesn't seem to be a good way to guarantee that they line up. So that means there will always be a frame or two delay between them. The HTML-in-canvas proposal may allow this to be resolved, but that appears some way off broad browser support, and would probably require a significant rework of HTML support in Construct anyway.

Out of curiosity, what are you using this for? I had imagined that HTML content would be used mostly for UI and HUD style uses where the scrolling issue isn't important, rather than gameplay content where HTML content tracks scrolling.