Drafts for polyline requestRender handling #12841
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The Request Render Mode is "spotty" with Entities. This is a bit vague, and there are many different flavors of "spotty". As shown in an example of a recent comment there, the meaning of that can be very specific (and unspecific at the same time), as in "It does not work".
The reason for this specific case is, very roughly: Under the hood, the entity causes the creation of several things, collections, batches, geometries, updaters, and a
Primitive
. This primitive is created with the default ofasynchronous=true
. This essentially means that the firstrequestRender
call from the sandcastle is issued before the geometry is actually created. (The creation happens with a worker, namely thecreateGroundPolylineGeometry
worker in this case). The primitive then goes through the ""well-known""PrimitiveState
state machine, and eventually, theGroundPolylinePrimitive
becomesready=true
.This is where the "fix" is hooking in: Setting the
ready
flag is done in aframeState.afterRender
function. And when such anafterRender
function returnstrue
, it will trigger a re-rendering in 'request render mode'.Of course, this fix is likely "too narrow", and only a "patch" for this particular case. There are other types of geometry and primitives, and whenever something is created with a web worker, this "thing" may suffer from the same issue: A client-side
requestRender
call may be issued before the worker is done, and the desired re-rendering of the (thenready
) object does not happen. It may be necessary to more thoroughly review the places where geometry/primitives are created asynchronously, and where someafterRender.push(... return true; )
may have to be inserted.Issue number and link
Related to #12543 , but certainly no holistic "fix" for that.
Testing plan
Run the sandcastle from this comment in the issue
Author checklist
CONTRIBUTORS.md
CHANGES.md
with a short summary of my change