Pesquisar no site de suporte

Evite golpes de suporte. Nunca pedimos que você ligue ou envie uma mensagem de texto para um número de telefone, ou compartilhe informações pessoais. Denuncie atividades suspeitas usando a opção “Denunciar abuso”.

Saiba mais

Esta discussão foi arquivada. Faça uma nova pergunta se precisa de ajuda.

SVG lines disappear when scaling downwards

  • 15 respostas
  • 1 tem este problema
  • 8 visualizações
  • Última resposta de ACProctor

more options

I am using <line> elements of width 1.5 to connect <rect> elements. This all looks fine but if the image is dynamically scaled down to show more of the diagram then some of the lines eventually disappear. I tried this in Chrome and it appears to work fine.

Rather than present any code, I can point to an example in a blog-post at: https://parallax-viewpoint.blogspot.com/2018/12/further-travels-of-walking-boots.html. Scroll to the bottom of the post and there's an embedded SVG "family tree" image that uses the JavaScript pan-zoom library to dynamically scale the diagram.

On the default setting, not all lines will show -- probably dependent upon whether they fall on a pixel boundary or not. As the image is gradually scaled up, you will notice that the lines will eventually all show. Contrast this with Chrome where the lines always appear to show.

I am using <line> elements of width 1.5 to connect <rect> elements. This all looks fine but if the image is dynamically scaled down to show more of the diagram then some of the lines eventually disappear. I tried this in Chrome and it appears to work fine. Rather than present any code, I can point to an example in a blog-post at: https://parallax-viewpoint.blogspot.com/2018/12/further-travels-of-walking-boots.html. Scroll to the bottom of the post and there's an embedded SVG "family tree" image that uses the JavaScript pan-zoom library to dynamically scale the diagram. On the default setting, not all lines will show -- probably dependent upon whether they fall on a pixel boundary or not. As the image is gradually scaled up, you will notice that the lines will eventually all show. Contrast this with Chrome where the lines always appear to show.

Todas as respostas (15)

more options

It's probably simpler to view it stand-alone and use the + and - buttons in the lower right corner to see the changes.

https://parallaxview.neocities.org/Blogger/TreeHammond3.html

This seems to work by changing the transform parameters. For example:

As loaded:

<g id="viewport-20181228205828281" class="svg-pan-zoom_viewport" transform="matrix(0.9656317830085754,0,0,0.9656317830085754,-88.4996566772461,-22.304458618164062)" style="transform: matrix(0.965632, 0, 0, 0.965632, -88.4997, -22.3045);">

After clicking the - button once:

<g id="viewport-20181228205828281" class="svg-pan-zoom_viewport" transform="matrix(0.8778470754623413,0,0,0.8778470754623413,-12.126983642578125,8.420180320739746)" style="transform: matrix(0.877847, 0, 0, 0.877847, -12.127, 8.42018);">

I don't know anything about this kind of transform.

However, the fact that lines appear to fluctuate between single width and double width reminds me of "rounding" issues I've seen with different viewport widths and certain CSS properties (disturbing fluctuations when slowing resizing the window a pixel at a time).

more options

Thanks, I had noticed those "fluctuations". Since Chrome seems to scale with no problem, would this be considered a problem in the Firefox SVG implementation?

more options

It's definitely a problem somewhere in Firefox. But whether it is related to transforms, or SVG specifically, I don't know. Do you want to file a new bug, or search for an existing one?

https://bugzilla.mozilla.org/

more options

I think logging a new bug would be quickest as I don't expect many people to have fallen foul of this

more options

jscher2000 said

https://parallaxview.neocities.org/Blogger/TreeHammond3.html

However, the fact that lines appear to fluctuate between single width and double width reminds me of "rounding" issues I've seen with different viewport widths and certain CSS properties (disturbing fluctuations when slowing resizing the window a pixel at a time).

I don't see 'double' lines when I zoom in and out (using mouse wheel or clicking + and -).



~Pj

more options

Now that it's been pointed out to me, I can see that it's there all the time, and is quite bad. I'm using a 1600x900 display on my laptop, and all transformations (+ or -) from the initial configuration show a pronounced "redraw" fluctuation. If you look carefully then you can see that the lines are thinner after the redraw, and at small scales this causes some to disappear. Are you using the diagram in the blog-post, or the standalone version (https://parallaxview.neocities.org/Blogger/TreeHammond3.html) as suggested above?

more options

ACProctor said

Are you using the diagram in the blog-post, or the standalone version (https://parallaxview.neocities.org/Blogger/TreeHammond3.html) as suggested above?

I was viewing it from:

https://parallaxview.neocities.org/Blogger/TreeHammond3.html

Within the Webpage, yes... missing or distorting lines, but it should be a static chart there anyway, since it's so small.


~Pj

more options

You should see the problem in both modes. In particular, that flicker, or fluctuation, when undergoing the matrix() transformation is very pronounced and must be indicative of a deeper problem than just my lines disappearing.

My laptop is running 64-bit Windows 7 on a 1.87GHz Dell Inspiron having a 1600x900 display. On using the +/- buttons, the new configuration appears to be drawn OK, but then a split-second later all the lines change slightly -- becoming thinner -- and some of the objects may even move by a pixel (it's hard to be sure exactly what's happening).

more options

ACProctor said

You should see the problem in both modes...

Correction. I see 'missing' lines in both modes.

Using:

https://parallaxview.neocities.org/Blogger/TreeHammond3.html

...With Zoom Minus 6 and 8, there are missing lines.


~Pj

more options

More Information: I have recently modified this SVG code (both in the blog-post and the standalone version) to join the lines more accurately when under high magnification. Part of the changed involved setting the stroke-opacity to 1.0, and this has had a knock-on effect for this problem.

The lines now appear to show much better at the small scales, suggesting that the reported problem was connected with opacity of the line elements. There is still a small "fluctuation" when using the +/- transformations, but it is now (to me) mostly visible in the text within the boxes, which becomes more bold a fraction of a second after that completed redraw.

Do let me know if I can provide any more information that might help.

more options

Hi ACProctor, you might want to add that to your bug filing as well as this thread.

more options

I haven't filed a bug myself, and I haven't seen a reference for one filed on my behalf -- otherwise I would be happy to do so.

more options

Oh, sorry, yes, I suggest you file a bug. It's possible this is already on file -- the submission system will show you similar reports -- but it might be new.

more options

ACProctor said

More Information: I have recently modified this SVG code (both in the blog-post and the standalone version) to join the lines more accurately when under high magnification...

https://parallaxview.neocities.org/Blogger/TreeHammond3.html


Ok, the lines hold-up this time. However, when I first Minus Zoom to the last step from -7 to -8, it's a smaller step-down. If I go back up and down before resetting, it steps-down the same as the other steps.

~Pj

more options

I was trying to understand your point Pj. I am aware that there's a slight difference between the initial size of the SVG diagram and the size after a reset -- the latter of which brings the sides out to the bounding frame. If this what you're referring to then it's not a Firefox problem; it's a problem with the pan-zoom JavaScript that I use, and I have seen it in other browsers.

The original problem (lines disappearing) does seem to be related to their opacity.

The remaining observation of the "fluctuation" when performing a +/- matrix() transformation might have been related to opacity. It's still there but much reduced, and seems to be that 'bold' is applied to the text AFTER the resized diagram has been redrawn, thus giving the appearance of two separate changes (i.e. a "fluctuation").