search

timkokes / svgweb

Automatically exported from code.google.com/p/svgweb
0 stars 0 forks source link

Fractional stroke widths are not supported #172

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I'm not sure if this was already present, but I think it was. There are
some subtle display differences between the Tiger image rendered in Flash
and then rendered natively (in eithe FF, Opera, or Safari). Images
attached. Notice that the whiskers are different.

Original issue reported on code.google.com by bradneub...@gmail.com on 21 Jul 2009 at 6:48

Attachments:

GoogleCodeExporter commented 9 years ago 
The problem is that flash does not support fractional stroke widths. 

The whiskers in the test image use a stroke of 0.1. Flash supports a stroke 
value
(which it calls thickness) between 0 and 255. That is not defined to mean 
pixels,
although that appears to be approximately what it draws in practice. However, a 
value
of zero, does not mean a stroke width of zero. It just means the minimum 
thickness.
And the minimum thickness is actually implemented as a stroke width of one 
pixel. So
even if flash was rounding 0.1 down, the actual minimum stroke width it draws in
pixels is one. The only other option is to disable the stroke, but that makes 
the
whiskers totally disappear. 

I am afraid there appears to be no reasonable solution to this problem.

The previous title of this issue was "Tiger SVG displays differently in native 
and
Flash."

Original comment by grick23@gmail.com on 30 Jul 2009 at 2:13

GoogleCodeExporter commented 9 years ago 
Makes sense. Perhaps we should mark this as WONTFIX?

Original comment by bradneub...@gmail.com on 30 Jul 2009 at 6:10

GoogleCodeExporter commented 9 years ago 
From Pedro on SVG Web group:

I've been thinking about fractional strokes issue and I believe that a
good sollution for it is using alpha values variation for every < 0 [1? -rick]
value. Does it make sense?

For example, if stroke width is 0.25, we can use 25% alpha and show it
with 1px width. Everything under zero can be drawn with 1px, and there
would be an exception for value 0 that would really be shown as 1px
width. 

From MichealN on SVG Web group:

Pedro's idea with varying alpha values sounds very reasonable to me.
On the SVG side common wisdom is that stroke-opacity is expensive and
should be avoided but maybe that was true some years ago with slower
machines.

While I am not the one to implement this I would at least like to give
some scenarios from a user perspective why fractional stroke-widths
are more important than how whiskers look on a tiger.

Compare the native SVG versus the Flash rendering of the following map

http://vis.uell.net/gsvg/shape_px.html
http://vis.uell.net/gsvg/shape_px.html?svg.render.forceflash=true

This is just the basic map and on top of it I need to differentiate
between county and district level boundaries so there really is the
need to have subtle differences in stroke-widths in mapping.

Also it may be odd for SVG Web adoption if the flash rendering looks
considerably poorer.

From Rick:
Thanks for the idea. I agree that this is a reasonable solution to try. Under 
normal
circumstances this will probably look more like how the native renderer works.
However, it is worth noting that if the current zoom level of the renderer (the
cumulative transform, which is available in flash) produces a stroke value of 
one or
higher, then changing the opacity is unnecessary since it appears to render 
OK*. 

*Note, however, that as the zoom factor increases another issue arises. Flash 
will
always render lines with a stroke value of less than .5 with a stroke 
equivalent to
one in actual pixels, no matter what the zoom level. When we set the flash 
thickness
value, which is an integer, .49 rounds down to zero and zero does not get 
scaled when
you zoom in. It just remains zero, which means one pixel as explained above. We 
could
round positive values up to one, but the value of one _does_ scale properly, 
and then
our stroke is about twice what it should be. This trade off varies at different
scales. Perhaps when the "round up" stroke produces less error than the "round 
down"
stroke, we should force a round up (or not) ...

In the case of the whisker of .1, consider a zoom factor of 500. The stroke in 
pixels
should be 50. Rounding normally when we set the flash value (which is an 
integer)
rounds down to zero, which produces a stroke of one, which is 50 times wrong. 
Forcing
a round up to 1 produces a stroke of 500, which is ten times wrong. Ten times 
wrong
is less than fifty times wrong. So, you can make an argument for rounding up in 
some
circumstances. However, I think this improvement may only work at high levels 
of zoom
and/or wrongness and just may not be worth it.

Original comment by grick23@gmail.com on 31 Jul 2009 at 7:19

GoogleCodeExporter commented 9 years ago

Original comment by bradneub...@gmail.com on 20 Oct 2009 at 12:27

GoogleCodeExporter commented 9 years ago 
Issue 414 has been merged into this issue.

Original comment by bradneub...@gmail.com on 16 Nov 2009 at 10:38

GoogleCodeExporter commented 9 years ago 
Does Flash 10 open any possibilities for resolving this? I'm changing it to 
medium only because I've 
noticed it seems to be one of the biggest drivers for visual display 
differences between the Flash and 
native renderers. Perhaps there is no solution but it would be nice if there is 
one.

Original comment by bradneub...@gmail.com on 9 Apr 2010 at 2:13