Added Scene.pickAsync for non GPU blocking picking

[alarkbentley]

Description

Scene.pick is internally using gl.readPixels that performs a synchronous GPU readback which is blocking the main render thread and very costly especially on low end GPUs. With WebGL2 a non GPU blocking method is available that uses PBO and Sync operations to asynchronously readback the pixels data without blocking.

Reference: https://registry.khronos.org/webgl/specs/latest/2.0/
Section: 3.7.10 Reading back pixels

This PR implements support for this and exposes it under a new API method Scene.pickAsync -> Promise

Asynchronous picking gives precedence to the rendering over returning the pick information. This introduces a slight delay compared to using the blocking pick method. Depending on what you prefer there might be value in having both options available in API.

Example

import * as Cesium from "cesium";

const widget = new Cesium.CesiumWidget("cesiumContainer", {
  terrain: Cesium.Terrain.fromWorldTerrain(),
});
const scene = widget.scene;

handler.setInputAction(function(movement) {
    scene.pickAsync(movement.position).then((feature) => {
         feature.color = Cesium.Color.YELLOW;
    });
}, Cesium.ScreenSpaceEventType.LEFT_CLICK);

Demo

Browser: Microsoft Edge Version 141.0.3537.71 (Official build) (64-bit)
GPU: ANGLE (Intel, Intel(R) Arc(TM) Pro Graphics (0x00007D55) Direct3D11 vs_5_0 ps_5_0, D3D11)

edge_sync_async.mp4

Profiling results

As seen in the synchronous picking (left), readpixels can stall for longer time than it takes to render the entire frame. In this example 46% of the total execution time is taken by readpixels.

In the asynchronous example (right) the bottleneck is the actual frame rendering which makes more sense.

Issue number and link

#630

Testing plan

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @alarkbentley! Welcome to the Cesium community!

In order for us to review your PR, please complete the following steps:

• Send in a Contributor License Agreement (CLA)
• Add yourself to the contributors file

Review Pull Request Guidelines to make sure your PR gets accepted quickly.

[mzschwartz5]

Hey @alarkbentley,

Thanks for the contribution! Crazy this goes all the way back to issue #630.

I left a number of comments, mostly style related, a few more important, but nothing that should drastically change the overall shape of the PR.

[mzschwartz5]

Style comment - I'm a stickler for simplifying conditional logic when possible.

This function has basically become two different functions depending on whether pbo is passed in. Let's formalize that:

const readPixelsFunc = pbo ? readPixelsAsync() : readPixelsSync();
readPixelsFunc();

Then we have just a single branching point instead of multiple.

[mzschwartz5]

These two funcs can take pixelFormat, pixelDatatype etc. as args

[alarkbentley]

Not sure if I agree that this would be simpler, could you perhaps show in a commit?
If we go this route I would rather create two separate prototype functions. But they have a lot in common.

[mzschwartz5]

Perhaps debouncing is something that should be handled internally by the implementation? (As an option, perhaps?)

Or maybe the internal implementation should use a set of results each frame, rather than an array, so that debouncing isn't even necessary (duplicates across frames will hash to the same entry)

[mzschwartz5]

I don't love the bloat this introduces to the sandcastle. I'm honestly not even sure if such a change is really necessary to show off in a sandcastle. I'm not sure I was even able to tell the difference between (a)sync in the video of this PR's description.

[mzschwartz5]

I haven't reviewed your unit tests yet, but given some of our conversations, I'm guessing we probably need more testing around:

1. TTL on the async pick (some unit test should have picked up on the fact that it was never being decremented)
2. (Maybe) Rejection of the async pick promise