FWIW - our engine measures delta-time (dt) by the difference in timestamps passed to requestAnimationFrame. This report demonstrates that when under GPU load in a worker with OffscreenCanvas, the rAF callbacks incorrectly keep reporting timestamps as if the framerate was still 60 FPS. Instead it should report timestamps reflecting the drop in performance due to the high GPU load.

In which context are you calling requestAnimationFrame -- the main thread or the worker? If the main thread is still running at 60 fps even if the worker is hitting its limit, it makes sense for the former to still give you 60 fps as the result (but the latter should report a lower fps).

(Do you have a smaller reproduction case that doesn't stress the system as much?)

requestAnimationFrame is called in the worker. The stress on the system is required to reproduce the issue so I don't see how it's possible to reproduce the issue without the stress on the system.

Skyos, try this example, maybe it is better.First try it on chrome 68, see how it works without worker, and then go chrome canarly/dev.
(i think i used different fullscreen scale, so it does not work in Chrome beta anymore, as it has that awful bug, when you use worker and screen gets resized worker window freezes)

https://snipg.github.io/GPUWithWorker1/

Tips: You can use my last link to test FPS with GPU and CPU(chrome canarly). For GPU just use max window size or fullscreen, see lag or freeze and FPS shows still 60.
For CPU make window very small and start to spawn alot of sprites, witness constant fps decrease and everything looks much better under cpu load.

Adding new examples for same problem. 
When ball reaches screen edge, text will be displayed with distance between each trail part. 
No Worker example: https://snipg.github.io/CorrectDt/
Worker example: https://snipg.github.io/WrongDt/

Worker example should be the same as without worker.

I'll send this to fserb@, who seems to be the expert for BeginFrames in OffscreenCanvas. AFAICT, offscreen canvas BeginFrames currently go via  WorkerAnimationFrameProvider::BeginFrame() and use a custom timestamp instead of the BeginFrame timestamp [1].

ash@scirra.com: If I understand correctly, in your case the worker isn't overloaded, but the GPU is, and you receive more rAF callbacks in the worker than the GPU can service? Is your computation of "delta-time" really as simple as rafTimestamp - lastRafTimestamp?

fserb: Do we have some sort of backpressure on the rAF callbacks in the workers based on e.g. CompositorFrameAcks for the submitted frames?

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/workers/worker_animation_frame_provider.cc?l=46

Yes, we measure delta-time as simply as rafTimestamp - lastRafTimestamp. Re-reading my last comment (it was a few weeks ago now), I think I meant that if the GPU load causes the framerate to drop to say 30 FPS (33ms delta-times), the timestamps we get to rAF appear to still be 16ms apart.

This seems to be related with DidReceiveCompositorFrameAck and DidPresentCompositorFrame not applying GPU backpressure.

We are exploring https://chromium-review.googlesource.com/c/chromium/src/+/1282219 as the possible solution for this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c2e137dc5294b30492a05a96a33bf0c7ff12908

commit 5c2e137dc5294b30492a05a96a33bf0c7ff12908
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Sat Oct 20 01:34:55 2018

viz: Throttle begin-frames when gpu is busy.

Throttle begin-frames to clients until gpu is done processing the
earlier swaps. This helps with reducing work when the gpu has a high
load, by not sending begin-frames to clients.

The clients always keep receiving the compositor-frame-ack messages
when a surface becomes activated (or replaces an older pending frame),
even if the gpu is busy doing work from earlier frames. So this change
introduces the back pressure by way of withholding begin-frames so
clients have to do less work.

BUG= 877906 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: If34eb5c5af03961e17932c8f57caf352d0362bab
Reviewed-on: https://chromium-review.googlesource.com/c/1282219
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601383}
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/components/viz/common/frame_sinks/begin_frame_source.cc
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/components/viz/common/frame_sinks/begin_frame_source.h
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/components/viz/service/display/display_scheduler.cc
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/components/viz/service/frame_sinks/primary_begin_frame_source.cc
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/components/viz/service/frame_sinks/primary_begin_frame_source.h
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/components/viz/test/fake_external_begin_frame_source.h
[modify] https://crrev.com/5c2e137dc5294b30492a05a96a33bf0c7ff12908/ui/android/window_android.cc

Fixed by our lovely friends in Waterloo.

Thanks, looks like it's working OK in Canary now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3629d825012de4e1ce8cad1a2be9b654c7b01b6a

commit 3629d825012de4e1ce8cad1a2be9b654c7b01b6a
Author: Sadrul Chowdhury <sadrul@chromium.org>
Date: Wed Oct 24 22:35:43 2018

Revert "viz: Throttle begin-frames when gpu is busy."

This reverts commit 5c2e137dc5294b30492a05a96a33bf0c7ff12908.

Reason for revert: crbug.com/898127

Original change's description:
> viz: Throttle begin-frames when gpu is busy.
> 
> Throttle begin-frames to clients until gpu is done processing the
> earlier swaps. This helps with reducing work when the gpu has a high
> load, by not sending begin-frames to clients.
> 
> The clients always keep receiving the compositor-frame-ack messages
> when a surface becomes activated (or replaces an older pending frame),
> even if the gpu is busy doing work from earlier frames. So this change
> introduces the back pressure by way of withholding begin-frames so
> clients have to do less work.
> 
> BUG= 877906 
> 
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
> Change-Id: If34eb5c5af03961e17932c8f57caf352d0362bab
> Reviewed-on: https://chromium-review.googlesource.com/c/1282219
> Reviewed-by: Antoine Labour <piman@chromium.org>
> Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#601383}

TBR=sadrul@chromium.org,fsamuel@chromium.org,sunnyps@chromium.org,piman@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  877906 , 898127
Change-Id: I3a21b59feacaa5152e187bc4483336abd5254b5e
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1298333
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602497}
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/components/viz/common/frame_sinks/begin_frame_source.cc
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/components/viz/common/frame_sinks/begin_frame_source.h
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/components/viz/service/display/display_scheduler.cc
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/components/viz/service/frame_sinks/primary_begin_frame_source.cc
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/components/viz/service/frame_sinks/primary_begin_frame_source.h
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/components/viz/test/fake_external_begin_frame_source.h
[modify] https://crrev.com/3629d825012de4e1ce8cad1a2be9b654c7b01b6a/ui/android/window_android.cc

Reopening. :/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/88023ceeb64cea0946fdcc3018ea28d9330a9976

commit 88023ceeb64cea0946fdcc3018ea28d9330a9976
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Thu Oct 25 18:00:15 2018

Reland "viz: Throttle begin-frames when gpu is busy."

This reverts commit 3629d825012de4e1ce8cad1a2be9b654c7b01b6a.

The fix for the revert was to mark the gpu as not-busy during the
destruction of DisplayScheduler.

Original change's description
=============================
Throttle begin-frames to clients until gpu is done processing the
earlier swaps. This helps with reducing work when the gpu has a high
load, by not sending begin-frames to clients.

The clients always keep receiving the compositor-frame-ack messages
when a surface becomes activated (or replaces an older pending frame),
even if the gpu is busy doing work from earlier frames. So this change
introduces the back pressure by way of withholding begin-frames so
clients have to do less work.

BUG= 877906 , 898127

Change-Id: I3a25cc96ac3f037fc275b12bc956c9875e6fe58e
Reviewed-on: https://chromium-review.googlesource.com/c/1299206
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602788}
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/components/viz/common/frame_sinks/begin_frame_source.cc
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/components/viz/common/frame_sinks/begin_frame_source.h
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/components/viz/service/display/display_scheduler.cc
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/components/viz/service/frame_sinks/primary_begin_frame_source.cc
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/components/viz/service/frame_sinks/primary_begin_frame_source.h
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/components/viz/test/fake_external_begin_frame_source.h
[modify] https://crrev.com/88023ceeb64cea0946fdcc3018ea28d9330a9976/ui/android/window_android.cc

Closing until reopened.