Canvas vs SVG in 4.10 API

[markpenton1]

Ok,

I have been away for a while (6 or 7 years) but lately have been busy writing JavaScript viewers and much has transpired in those years.  I am migrating a JS viewer from 3.27 to 4.10 and was migrating my custom 3.27 swipe widget to 4.10 and ran into a brick wall with regard to the use of a Canvas in 4.10 in lieu of SVG from the 3.27. Looking at the ESRI swipe widget in 3.27 it made heavy use of a layer's domNode because of the use of SVG. Why canvas? Is it superior to SVG? It just seems like a blob of dumb pixels to me, can't do much with it. Please enlighten me!

[NathanSummers1]

SVG is being replaced by WebGL for performance reasons.  I think it was 4.9 that made WebGL the default - I got this information from the release-notes posts.

[RobertScheitlin__GISP]

To add to what Nathan said. WebGL is now used because SVG was limited in the amount of graphics that could be added to its context. With WebGL you can now have multiple thousands of features (graphics) drawn clientside.

See this Blog post for more info:

Do More with More 

[StevenGreenwaters]

Esri made WebGL the default instead of SVG when the JavaScript API version 4.9 was released in September 2018. The following blog post says, "Starting now, WebGL rendering is out of beta and is the default rendering engine... For now, if you have a requirement to use SVG instead of WebGL for rendering, you will be able to configure your app to use SVG. However, starting with 4.10 (December 2018), WebGL is the only planned rendering mechanism."

https://www.esri.com/arcgis-blog/products/js-api-arcgis/announcements/jsapi-4-9/

Sure enough, when the JavaScript API version 4.10 was released in December 2018, the release notes said, "WebGL is now used for drawing all layers in a MapView."

https://developers.arcgis.com/javascript/latest/guide/release-notes/index.html

That means WebGL support in users' browsers is now mandatory even for 2D maps-- not just 3D maps. I am shocked Esri would go from having SVG be the default rendering mechanism to completely dropping all support for it wholesale in a span of only three months. Support for SVG should have been retained for years after whenever WebGL was no longer the default.

Since there are still tons of brand new computers out there that have limited or no support for WebGL, if you want your web applications to function at all, you are now stuck like a brick wall with the JavaScript API version 4.9. Our federal agency will not be able to benefit from any of the improvements in version 4.10 and above for many years because of this decision. On my maxed out, highest-end Dell Latitude, I now see a blank hole instead of a map for every single one of the sample applications. What on earth?

[markpenton1]

Some follow-up information. I am also doing extensive work with OpenLayers v5.3.0 and quite surprisingly (shockingly!?) I read this, which I highlighted in bold-italic, on there GitHub site for their next version.

SourceURL: https://github.com/openlayers/openlayers/blob/master/changelog/upgrade-notes.md.

"New prerender and postrender layer events replace old precompose, render and postcompose events

If you were previously registering for precompose and postcompose events, you should now register for prerender and postrender events on layers. Instead of the previous render event, you should now listen for postrender. Layers are no longer composed to a single Canvas element. Instead, they are added to the map viewport as individual elements".

Drop of support for the experimental WebGL renderer.

"The WebGL map and layers renderers are gone, replaced by a WebGLHelper function that provides a lightweight, low-level access to the WebGL API."

If OpenLayers and ESRI were on the same highway it appears they are headed in opposite directions.  And lastly, I am so far, quite impressed with OpenLayers v5.3.0, although the jury is still out.