Well, I should have specified that you should return it as a string, via the html key, but override the content type for SVG.
I changed and returned it as a string via html kep did remove the error, but I was not able to show it with the image component. Can you elaborate a bit on "override the content type for the SVG"?
thank you!
Actually there is still a problem with the Webdev approach.
The left one is generated with the Webdev, and it just displays dark grey color( return {'html': svg_string,'contentType': 'image/svg+xml'}). The Right one is generated with the old approach with script, showing the correct heat map. Is there something else I need to do?
Can you use your browser's dev tools to see if the content type came through correctly?
You may need to encode the string to bytes after all, if the html key won't let you override the content type.
not sure what happened, but it is magically working now. Thanks @pturmel for your time!
2 Likes
I just have a follow-up question regarding the WebDev module. When I am using the Webdev module to query the data and generate the SVG, does that mean I am utilizing the web browser to perform the computing instead of the Ignition Gateway?
No, the WebDev code runs entirely on the gateway.
1 Like
Okay, what I don't understand is what aspect we are improving by using the Webdev module compared to assigning the base64 data URL to the image component?
Also, when using the Webdev module to generate the SVG, I did not see any spike in the Gateway memory, but the web browser did consume a lot of memory on my computer when loading the image in the web browser. Is there an explanation for it?
You are moving a "heavy" display item from being computed inline with the image component to out-of-line as the image component's source. This is particularly important when the image component is nested in a table. You also avoid a slight computational penalty of encoding to base64 on the gateway and decoding the base64 in the browser.
Using separate URLs per image also allows the browser to cache them, and you can have your WebDev code cache the SVGs on that end, too. When inline, no caching is possible.
I have no idea why your browser's memory consumption spikes.
3 Likes
Thank you so much! and that makes sense.
1 Like