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

Label backgrounds have too much padding on Linux + Firefox #12443

Closed
anne-gropler opened this issue Jan 20, 2025 · 8 comments
Closed

Label backgrounds have too much padding on Linux + Firefox #12443

anne-gropler opened this issue Jan 20, 2025 · 8 comments

Comments

@anne-gropler
Copy link
Contributor

anne-gropler commented Jan 20, 2025

What happened?

When working on a sandcastle for another issue (#12138), I noticed that the labels look odd on a different machine. I was told by a collague that this issue exists for at least a year, that we know of.

The labels have too much padding on Linux and Firefox. Also note the weird scattered single pixels in the background:

Image

They do look fine ( = as expected) on the same Linux but with Chrome. Well fitting padding and clear white-with-alpha background.

Image

Reproduction steps

  1. Select a machine running Linux.
  2. Open Cesium Viewer in Firefox
  3. add Labels (as entities or as label primitives) that use a background

Sandcastle example

https://sandcastle.cesium.com/#c=zVVbT9swFP4rXrSHZCtuC7RAb9oo3ZiEtmmg7SUPuMlJa+HYke20MOh/n507pWhs0qRVahKf71y/c3ISCK40WlFYg0RjxGGNpqBoGuPvmcz1nSA7TwXXhHKQvuMNfc5AI0bmwC6o0mDEU8LYnAQ3BsvRyBicAdPEuO12cGdYiy/pTzDS/VwaZCnElH+ooW4TIbcN5PA4g0owEIxBoKngj7O/sLlNK9C1OedVYhWYfHEiaUw1XYHCJAzd2o/X8A5cU31nPBem2ZkWJvc+RygRilqrQRl4SqQ2T4Qf4EiK+AwWEkC5e0c93O0fdvv9oxY6OMEnvX3781rWSUbkAGUOEdJwqwfId/LgvtPKxWop1qeG4IUUKQ8HSMsUCiiizNYqZJ2FPeGP32azz4XOvDLdpfnj/NPVDK+pXr5nyZK4HXzc8xqBH4cz3Rig69f3ZS83yS0y/adzSa8znY25bppEVmwbLmuq/4bGTgsdFrSVRNXO0yQkGsKCs2cZ+5d8bbH1O64KluybIWGeUqa/ltUYIEp5Pts5FlZYNt6ujeXlY7Nt/AzPf8B0r2+YPimH4CnXRcT/ZT7t9eXzaVnf+Hw3rTbzvC0+vyQ8DIjSDCyJV2KxYHCaam1Wiu+c0xBQZqMMDSgiTIG5lU1zgyUENxAWLcrfZ2wTNd15VYDDbPzLBHai9t9opoRYrMDd7rhX6dJoOzSq1+7bcb2Zhzlm9St8Mn60cB8eatPRuLmlK9eoserfjNFevrutfJPfisKzLYetrinwme4UhjUfL1DflHXv7mZJZdZyb+i0nJHSdwwmZfbvaJwIqVEqmYtxW0OcMLNFVHueGjuNA6W8Iq9Ru2k6CukK0XC84xOJAkaUMkiUMmaz9p3JqG30n5gyQULKF19WIBm5s2rL7uQiF2KMR21z3G2phTBfXLnl+Rc

Environment

Browser: Firefox 134.0.1
CesiumJS Version: 1.125, but issue seems to be waaay older.
Operating System: Arch Linux with Kernel 6.12.10; Nvidia GeForce GTX 1660 Ti with Nvidia driver Version 565.77

@ggetz
Copy link
Contributor

ggetz commented Feb 6, 2025

Thanks @anne-gropler! I wonder if this is a manifestation of our implementation of measureText#9767.

In noticed the font used is "Calabri" which is not installed by default on all machines and browsers. If it appears to be specific to the Calabri font, my other guess would be #378 is coming into play. Would you be able to confirm if this behavior also manifests for default fonts like sans?

@ggetz ggetz added needs feedback On hold until additional info is supplied theme - label/billboard quality labels Feb 6, 2025
@adi64
Copy link

adi64 commented Feb 7, 2025

Thanks for the reply @ggetz!
The affected machine in question is mine, so I thought I'd reply directly.
I tried out your suggestion and updated the above Sandcastle to use sans for every font, but the problem persists:

Image

I just tried it on a different machine - also Linux, also Firefox, but this time using the on-chip Intel UHD Graphics 630. Same problem. So this seems to be not a font-specific problem, but a "Firefox on Linux" problem. But I'm not sure if this is a Firefox bug or a Cesium bug which just happens to work fine on Chrome.

@jjspace
Copy link
Contributor

jjspace commented Feb 7, 2025

I think this may be a Firefox problem not a Cesium problem. Maybe there's a way to mitigate it on our side but someone would have to look into that more. Throw the following into the dev console on some browsers to see what it says

ctx = document.createElement('canvas').getContext('2d')
console.log(ctx.measureText('test'))
console.log(ctx.font)
console.log(ctx.measureText('test').width)

On Chrome on Linux I get a width of ~16.1181 always across 2 machines
On Firefox on Linux on one machine I see ~19.2 on one machine and ~17.75 on another machine. The second has a HighDPI screen which may affect it but I don't know.
All show the "same" font being used by default of "10px sans-serif"

Interestingly the interop project does have tests for measure text that show Firefox should be passing for both the canvas element and offscreen canvas. Looking at the tests themselves they use a special font so maybe it's a matter of the way Firefox treats the default fonts?

Not gonna keep digging but maybe that helps get someone else started

@ggetz ggetz removed needs feedback On hold until additional info is supplied needs triage labels Feb 17, 2025
@ggetz
Copy link
Contributor

ggetz commented Feb 17, 2025

Thanks for the info @adi64, and thanks for the insight @jjspace!

I think we can safely eliminate #378.

It sounds like firefox on linux is at minimum a contributing factor. We'd be open to including a workaround if this is known issue affecting multiple users.

@jjspace
Copy link
Contributor

jjspace commented Feb 17, 2025

Checking this notification made me remember a comment on the forums I saw last week regarding the scattered pixels. I've opened #12480 to track that separately as it seems unrelated to the label sizing/padding

@anne-gropler
Copy link
Contributor Author

I've opened #12480 to track that separately as it seems unrelated to the label sizing/padding

It seems related! On my Windows, Firefox I activated the "suspected fingerprinters" option, and it creates those scattered pixels AND the extra padding!

Suspected fingerprinters on:
Image

Suspected fingerprinters off:
Image

@adi64
Copy link

adi64 commented Feb 18, 2025

I can confirm that it is fixed by disabling "Enhanced Tracking Protection" also on Linux :)

Image

@ggetz
Copy link
Contributor

ggetz commented Feb 18, 2025

Thanks all!

So all in all, I think #12480 is interacting with #9767 to produce this issue. I'm going to close this one to keep the relevant discussion in those two threads.

@ggetz ggetz closed this as completed Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants