mike-jumper commented on code in PR #883:
URL: https://github.com/apache/guacamole-client/pull/883#discussion_r1231198868
##########
guacamole-common-js/src/main/webapp/modules/SessionRecording.js:
##########
@@ -211,6 +219,22 @@ Guacamole.SessionRecording = function
SessionRecording(source) {
*/
var seekCallback = null;
+ /**
+ * Any current timeout associated with scheduling frame replay, or updating
+ * the current position, or null if no frame position increment is
currently
+ * scheduled.
+ *
+ * @private
+ * @type {number}
+ */
+ var updateTimeout = null;
+
+ /**
+ * The browser timestamp of the last time that currentPosition was updated
+ * while playing, or null if the recording is not currently playing.
+ */
+ var lastUpdateTimestamp = null;
Review Comment:
This should be annotated `@private` and with its proper `@type`.
##########
guacamole-common-js/src/main/webapp/modules/SessionRecording.js:
##########
@@ -32,8 +32,18 @@ var Guacamole = Guacamole || {};
* @param {!Blob|Guacamole.Tunnel} source
* The Blob from which the instructions of the recording should
* be read.
+ * @param {number} refreshInterval
+ * The minimum number of milliseconds between updates to the recording
+ * position through the provided onseek() callback. If non-positive, this
+ * parameter will be ignored, and the recording position will only be
+ * updated when seek requests are made, or when new frames are rendered.
+ * If not specified, refreshInterval will default to 1000 milliseconds.
Review Comment:
The notation for an optional parameter with a default value would be:
```
@param {number} [refreshInterval=1000]
```
##########
guacamole-common-js/src/main/webapp/modules/SessionRecording.js:
##########
@@ -678,20 +727,62 @@ Guacamole.SessionRecording = function
SessionRecording(source) {
*/
var continuePlayback = function continuePlayback() {
+ // Do not continue playback if the recording is paused
+ if (!recording.isPlaying())
+ return;
+
// If frames remain after advancing, schedule next frame
if (currentFrame + 1 < frames.length) {
// Pull the upcoming frame
var next = frames[currentFrame + 1];
- // Calculate the real timestamp corresponding to when the next
- // frame begins
- var nextRealTimestamp = next.timestamp - startVideoTimestamp +
startRealTimestamp;
+ // The position at which the next frame should be rendered
+ var nextFramePosition = toRelativeTimestamp(next.timestamp);
Review Comment:
The calculation of the next timestamp based the amount of real time that
passed since playback started was intended to correct for timing error that may
accumulate if frames take longer to render than when the recording was made.
For example, if a series of 100 frames took 10ms each when recorded, but are
taking 20ms in the browser currently playing that recording back, that ~1
second of original time will take ~2 seconds to play back and will offset the
rest of the recording unless steps are taken to correct this on the fly.
There is also occasional scheduling error due purely to inaccuracy in JS
timer events, and corrective steps need to be taken to prevent that error from
accumulating to the point that the recording is significantly delayed.
It looks to me like the new code will schedule frame rendering based purely
on the positions of the frames, without taking delays due to processing into
account. Am I missing something?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
