backlog of "updates" is displayed in "fast forward" mode after getting back. about octoprint HOT 5 OPEN

This sounds like the updates from the backend sent via the websocket getting throttled into oblivion by the browser on backgrounding (that's something that browsers do these days, see also here), and then when you refocus the tab the UI gets all updates at once and has to apply them all. Which is a tad weird, I would expect the browser to still keep the websocket connection alive (as also written at the above link), so updates should still happen, but maybe after a certain point they aren't...

I have actually seen this once or twice myself, but always chalked it up to my system having been suspended in the meantime (which obviously would sever the connection), and it never did block the whole browser. It will take some time to find a way to reliably reproduce this in a timely manner (I cannot really go into debugging this when I have to first have to background a tab for hours on end), but I'll see what I can do in figuring out what even can be done on OctoPrint's side here.

from octoprint.

I have wanted to implement the "Page Lifecycle" API handling within OctoPrint for a while now. I suspect the process here is very similar to how 'sleeping tabs' features work, that the browser decides to freezes JavaScript (there's more to it, described on the link below), but doesn't disconnect the websocket. Reloading the page might be waiting for the existing JS callbacks to be processed before the page is removed & reloaded - closing the tab and then reopening it should be fine still.

I opened #4698 but never managed to dig in to it enough to start solving the issue. If my theory that the handling here is the same is correct, then I guess this is kind of a duplicate of that issue. I don't have time to dig into it, even though I'd love to... I can imagine a simple "test" plugin would be able to tell us if the API below is triggered in this case.

https://developer.chrome.com/docs/web-platform/page-lifecycle-api#state-frozen

https://wicg.github.io/page-lifecycle/spec.html

from octoprint.

One of the ways to solve it is that instead of handling: "Oh, time printed has updated to 1:22:33" and then repainting the screen, you just internally set the time-printed to that number, and tag "time printed" as "needs screen refresh. And only when there haven't been any updates for say 100ms do you start putting things on the screen. This on the assumption that you cannot "look ahead" to see if there are more updates pending. (no more queued data on the websocket.

The issue is that the repaint the screen takes say about 70ms, and the N updates at 70ms a piece takes a LONG time. If you can process the update in say 1ms then the "catch up with a day worth of updates" takes way less time so it becomes unnoticeable.

from octoprint.

That does start getting complex with the volumes of data that come through the OctoPrint websocket. There's a lot more than just a couple of fields that "need screen refresh", it's almost all of them - otherwise they would not be read. What you have described is essentially the principle behind UI libraries such as React, which hold a "virtual" model of the page and batch updates to render the page so that it is not constantly repainting.

I think, to handle this correctly the socket should be disconnected, so that the updates do not build up in a queue, and then when the page is unfrozen we reconnect and only have to process one websocket update.

Would have to work out a solution for the "assumption" that the UI will receive events to update it's state, which would be skipped. A prompt to reload would solve this, but it would of course be better to seamlessly update the UI if possible.

from octoprint.

Just noticed a way that might be easier to reproduce.... I just submitted a 29h job and after the slicer said "upload succeeded" I switched to my octoprint temperature view in my browser. Still operational.... and then afterwards... suddenly the temperature display started doing MANY more updates per second than what is normal. So even in that case, a buildup of update happens. In my case... It happened twice, as if took long while there were still updates queued.

from octoprint.