Canvas2D: Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true

Hi Team,
I’m making the cluster of labels like: -

position: Cesium.Cartesian3.fromDegrees(x, y),
label: {
text: lbl,
font: “14px Helvetica”,
fillColor: Cesium.Color.WHITE,
outlineColor: Cesium.Color.CYAN,
outlineWidth: .5,
opacity: 1,
style: Cesium.LabelStyle.FILL_AND_OUTLINE,
heightReference: Cesium.HeightReference.CLAMP_TO_GROUND,
pixelOffset: Cesium.Cartesian2(10, 50),
eyeOffset: Cesium.Cartesian3(0.0, 1500.0, 0.0),
horizontalOrigin: Cesium.HorizontalOrigin.LEFT,
verticalOrigin: Cesium.VerticalOrigin.BASELINE,
disableDepthTestDistance: Number.POSITIVE_INFINITY,
clampToGround: true

and adding the labels on the globe using given code :-


while adding the labels cesium.js throwing a lot of warning messages like:-

Canvas2D: Multiple readback operations using getImageData are faster with the ‘willReadFrequently’ attribute set to true. See: HTML Standard

Coz of these warnings application becomes slower please help me how to remove provided warning messages.
Screen shots of errors are given below:-


Hi Shashi,
Have you resolved the issue? seems i encountered the same,

Thanks & Regards,

Not yet waiting for the Cesium Team response.

On the other sources i’ve found HTML Standard help but it’s need to change into the cesium.js.

see this issue too (spoiler: it may not be a good idea to change it):

1 Like

Hi there,

Looks like willReadFrequently was officially added to the canvas API earlier this year

Based on discussion around this feature, heuristics for when this feature is helpful are imprecise, which is why this is a console warning. I would suggest investigating whether this does provide a performance benefit in CesiumJS by cloning the repo and modifying the code which creates the 2D contexts, such as in labelCollection and writeTextToCanvas. If you can demonstrate that this is a performance improvement with your data, we can certainly take a look at including it.


I saw the other post too, and was wondering what “readback” operations Cesium performs against WebGL. In the example in the first post, I noticed that the entity collection is called “cluster”, and it occurred to me that clustering uses GL-backed collision detection (?) – maybe this issue only occurs when clustering is enabled? I’ve had cases where enabling clustering really tanks performance (see clusterEvent fires continuously · Issue #5096 · CesiumGS/cesium · GitHub) so maybe the warning is actually on to something in that specific case?

Thanks for providing the reference i went through that, but in which version it’s added and how we can implement it, in our code using Cesium.js not mentioned properly, and i’ve not found any reference about it in cesium help section pls do update if u have any.

In our project with Cesium, the console messages start to appear in the initialization phase, before any of our own data is added to the map. So I have to assume that the basic functionality of displaying a map already does a number of Canvas2D reads.
Maybe one of the core developers can shine a light on this?

Do you get the error on every Cesium page? I just opened the default Sandcastle example and I’m not seeing the errors mentioned in the OP. (Chrome 106, Windows)

ETA: I was able to get one of these errors in Edge 106, but it’s definitely spurious – it traces back to a feature detection function (Resource.supportsImageBitmapOptions) which calls getImagePixels twice in a row, against two 1x1 pixel test images. I’m still unable to make it produce a big dump of multiple warnings like the OP shows, though.

If your are using online Cesium.js you can’t.
If you are using locally or you have your own Cesium.js library you need to change given code
.getContext(‘2d’, {willReadFrequently: true}) everywhere in Cesium.js library.

I see two of these warnings on application initialisation. Since this is an Angular app and the cesium viewer is initialised while not visible (covered by another page of the app) it is very hard to determine exactly when the warnings occur. Two more appear about a second after the main Cesium Viewer is stable and visible. This occurs reliably BTW. After that I rarely see these warnings .

update: I do see a lot of these warnings when I zoom in on our data that’s added to the map. I wonder whether these issues might be related to billboards (which we use to display stuff).
As a side note: another common feature between the OP and our app is the use of disableDepthTestDistance: Number.POSITIVE_INFINITY.

As per the MDN docs:
“This will force the use of a software (instead of hardware accelerated) 2D canvas and can save memory when calling getImageData() frequently.”
This doesn’t exactly raise any expectations that cesium is going to be faster with this option enabled. Forking cesium and applying the code change shouldn’t be too hard, but I have no incentive to do so at the moment.
I have applied this option in a color picker component that I made (not related to the cesium usage in my app), where getImageData() is called frequently (on mousemove) but there I didn’t see any difference in performance.

Are you able to reproduce this somewhere public-facing? Stackblitz for Angular, or maybe just a custom Sandcastle? I could help debug, if so. If not, try clicking through to the line in Cesium.js that gets flagged in the console log message, and set a breakpoint, then reload the page. You might get some insight into the call stack at the time – it’s how I found the function I referenced in my previous comment.

I currently find no degraded performance that I can relate to these warnings, so I’m a little unwilling to pour even more time into this. I was initially just responding to the OP with a pointer to the MDN docs.