Mikhus / canvas-gauges

HTML5 Canvas Gauge. Tiny implementation of highly configurable gauge using pure JavaScript and HTML5 canvas. No dependencies. Suitable for IoT devices because of minimum code base.

Home Page:http://canvas-gauges.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Firefox - Most gauges layout breaking after a few seconds

rouggio opened this issue · comments

hi Mikhus, even on the live demo page, I can get broken gauges after a few seconds:
https://canvas-gauges.com/documentation/examples/

just hover with the mouse on any gauges in the "Zero Configuration Gauges" or "Other Custom Radial Gauges" or "Other Custom Linear Gauges" sections, stay there for about 10 - 20 seconds and after a while the layout will get corrupted

canvas-gauges version: 2.1.7
Tested on Firefox 95.0.1 (64 bit) on Ubuntu 20.04.3 LTS

bug

cannot reproduce on google chrome, no other browser available here for me

Hi, I have has a similar issue for more than a year with Firefox and this gauge type.
I have always assumed it was the way I was using the gauge.
Windows 10, Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz, NVIDIA 1060, Firefox 95.0.2 (64-bit)
Similar experience with Chrome, no issue visible.

Issue takes 50 updates to display the missalignment, i.e. >100 seconds with the test code below:
image

image

Test code html, perhaps someone has a tip on what's causing the issue?
test.txt

P.S. Thanks to the author, great gauges and to you for taking time to read and perhaps assist.

Same here on Raspberry PI4 4GB and Win11 both running Firefox.

Confirming the problem with Firefox 96.0.3 (64-bit) on Windows 10. Animations (as they usually are because they are one of the coolest thing in these) must be on for this problem to occur. As said above, most of the animated demo gauges on the official example pages fail in a few seconds.

My workaround is to use the update method to set valueText everytime after updating the value [to a string containing the numeric value just set; so visually value box will look the same]. It looks like this workaround works for some reason, no problems so far. However, with that approach animatedValue will not be available (valueText will override it).

Same problem here....

My workaround is to use the update method to set valueText everytime after updating the value

Hi panuworld,

I'm having the same problem with Firefox but I can't seem to get your workaround to work. I'm just doing this each time I have a new value:

        gaugeSpeed.value = parameter[1];   //parameter[1] contains the new value as a number string
        gaugeSpeed.valueText = parameter[1];

I guess I am missing something in your workaround description! Can you see what I am doing wrong? It would be nice to get this fixed if possible!

I'm having the same problem with Firefox but I can't seem to get your workaround to work. I'm just doing this each time I have a new value:

        gaugeSpeed.value = parameter[1];   //parameter[1] contains the new value as a number string
        gaugeSpeed.valueText = parameter[1];

My code uses the update method to update the valueText and it (looks like it) helps with this problem. Wondering if the valueText can be set directly as a property at all... My code:

	gauge.value = speed
	speed = speed.toFixed()
	gauge.update({ valueText: speed, animationDuration: intv })

My PWA using this workaround is here: https://panuworld.net/liikenne/nopeus/speedo.htm (however, it is not really useful on desktop Firefox without GPS)
Another page where I use the same workaround is here (its is in Finnish only but it should show something also on desktop Firefox): https://panuworld.net/liikenne/junat/

Edit: Disclaimer: this seems to work around the acute problem for now. However, I have no idea what is the root cause. So the reliability of this workaround cannot be guaranteed.

Hi,
tried the proposed fix against the example I posted previously.
It seems to work a treat!!! :-)

I have commented in the differences as this file works standalone as an example.
test-1.txt

Thanks for the hint.

Many thanks panuworld and OneOfTheInfiniteMonkeys. I didn't know about the gauge.update facility but now I've implemented it in my code it works perfectly. I don't do much of this sort of coding, being more of an application programmer, so your examples were really helpful!

be very careful with using this workaround as updating too often with this approach will kill the browser.

That's an interesting comment, fencer. I've not "killed" any of my browsers with updates every second or so but perhaps you're thinking about much higher update rates? What resource is the browser running out of to cause it to crash?

That's an interesting comment, fencer. I've not "killed" any of my browsers with updates every second or so but perhaps you're thinking about much higher update rates? What resource is the browser running out of to cause it to crash?

I have about 4 gauges 2 of which update 2-4 times a second. One of them was using the update method, Firefox would eat up 3GB+ RAM in very few seconds till eventually get unresponsive.

I have about 4 gauges 2 of which update 2-4 times a second. One of them was using the update method, Firefox would eat up 3GB+ RAM in very few seconds till eventually get unresponsive.

Interesting, thank you. I found that my Firefox which had been running for 8 hours or so was using 1.7GB with 15+ open tabs, two of which are displaying gauges that use the update function. I closed Firefox, reopened it and refreshed the tabs one-by-one. That got me to about 1.2GB but there was no big uptick in memory use when I refreshed my gauge pages. I've watched for 30 minutes or so with very little change in memory use. Of course, if I start refreshing tabs displaying dynamic pages then memory use goes up as more stuff gets cached but I can't see that the gauges are gobbling up RAM, nor am I experiencing any unresponsiveness.

I have tried to make an example to reproduce the issue but I had no success, so I went ahead and restored the guage.update in my code and still did not happen. I suspect it could be a combination of other things. Will post an update in case I figure it out.

Same here, when viewed by Firefox on Win10. On Firefox v101.0, using gauge.min.js served from cdn.rawgit.com, I did see a deprecated warning message on FF debug console from on some gauge draw method. After updating to FF the current latest version (v102.0.1), no warning messages occurred but stated problem persists.
To me, this looks like a problem with the coordinate system, where the top-left origin changes to the center of the drawing. The .js code is too obfuscated to be readable, unfortunately.