Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox - Most gauges layout breaking after a few seconds #251

Open
rouggio opened this issue Dec 23, 2021 · 16 comments
Open

Firefox - Most gauges layout breaking after a few seconds #251

rouggio opened this issue Dec 23, 2021 · 16 comments

Comments

@rouggio
Copy link

rouggio commented Dec 23, 2021

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

@OneOfTheInfiniteMonkeys
Copy link

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.

@W0lpertinger
Copy link

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

@panuworld
Copy link

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).

@Tirguy
Copy link

Tirguy commented Feb 18, 2022

Same problem here....

@JohnLinford
Copy link

JohnLinford commented Mar 5, 2022

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!

@panuworld
Copy link

panuworld commented Mar 6, 2022

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.

@OneOfTheInfiniteMonkeys
Copy link

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.

@JohnLinford
Copy link

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!

@fencer
Copy link

fencer commented Apr 3, 2022

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

@JohnLinford
Copy link

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?

@TuShen121
Copy link

TuShen121 commented Apr 4, 2022 via email

@fencer
Copy link

fencer commented Apr 4, 2022

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.

@JohnLinford
Copy link

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.

@fencer
Copy link

fencer commented Apr 4, 2022

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.

@rob040
Copy link

rob040 commented Jul 7, 2022

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.

@TuShen121
Copy link

TuShen121 commented Jul 7, 2022 via email

oweitman added a commit to oweitman/ioBroker.vis-canvas-gauges that referenced this issue Aug 28, 2022
as described here
Mikhus/canvas-gauges#251
the proposed change should woraround the problem with firefox.
it dosent seems that the autor of the lib would fix this.
additional description and test of the workaround here
https://forum.iobroker.net/topic/57487/vis-anzeige-gevierteilt/29?_=1661722561928
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants