W3C home > Mailing lists > Public > www-svg@w3.org > April 2003

Re: [SVG] optimizeSpeed misbehavior pixel rendering at 100% zoom level in Adobe

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Tue, 29 Apr 2003 08:43:52 -0400
Message-ID: <16046.29576.589665.539533@frog.rl.kodak.com>
To: "Fred P." <fprog26@hotmail.com>
Cc: thomas.deweese@kodak.com, www-svg@w3.org

>>>>> "FP" == Fred P <fprog26@hotmail.com> writes:

FP> Hi M. I know everything, Well, it should not allow for 1 pixel
FP> mis-behavior, since this mean there is a 100% error tolerance for
FP> every pixel being drawn.  In other words, for every pixel drawn a
FP> misbehaving pixel can also be drawn.
>> >> In cases where a line falls exactly between two pixles which
>> pixel >> do you render (see below)?  Implementations are allowed to
>> choose.

FP> Okay, implementation may chose but a circle is a circle not a
FP> coleco E.T. monster.

FP> I always drawn and specified a 4 pixels diameter circle with r='2'
FP> or 2*r = diameter = 4 pixels, since the beginning:
FP> http://lists.w3.org/Archives/Public/www-svg/2003Apr/0041.html

FP> YOU specified a modified version with 5 pixels, but that doesn't
FP> matter.

    Wrong again, please read the SVG specification of stroke-width.
The width of your circle is 'r*2+stroke-width'. This is fundamental to
understanding why your content is wrong, why you need end points in
the middle of pixels not on the edges if you want the level of control
you want over line drawing.  There are very important differences
between graphics on discrete coordinate systems (pixels) and floating
point coordinate systems (svg).

    You have to view SVG stroking operation as insetting and
outsetting the given path by 1/2 the stroke-width this region is then
filled based on the underlying pixel grid.

FP> In other words, a circle of 4 pixel diameter will always look the
FP> same, I don't think it is too much to ask to get this in SVG
FP> viewer, is it?

>>  I strongly doubt SVG will ever guarantee pixel and code value
>> precision, if this happens then there will essentially be only one
>> SVG viewer - which would be a pitty.

FP> Yes, it does. You know why? because you draw PERFECT RECTANGLE
FP> covering every pixel PERFECTLY.

    The fact that you get "exact" results in one (very simple) case
does not mean that it is reasonable to get "exact" results in all
cases.

FP><path style='fill:#FFFFFF; stroke:#000000; shape-rendering: optimizeSpeed;'
FP>d='M 5 17 L 2 14 L 2 10 L 3 9 L 5 9 L 5 12 L 5 5 L 6 4 L 8 4 L 8 10 L 8 4 L 
FP>9 3 L 10 3 L 11 4 L 11 10 L 11 4 L 13 4 L 14 5 L 14 10 L 14 6 L 16 6 L 17 7 
FP>L 17 15 L 16 16 L 16 17'
FP>/>

FP>is a perfect line in theory, it covers all pixel precisely to their
FP>middle point BUT because of the triangles for diagonal lines,
FP>the Adobe SVG renderer will make them pixels and corrupt the picture,
FP>there is no reason here to make have a misbehaving pixel,
FP>its a damn diagonal line.

    Still wrong...

    Now let's try making that something that makes some sense (the
transform just shifts the data so all the end points are in the middle
of pixles - as I suggested in my last two posts).

   <path transform="translate(.5,.5)"
         style='fill:#FFFFFF; stroke:#000000; shape-rendering: optimizeSpeed;'
d='M 5 17 L 2 14 L 2 10 L 3 9 L 5 9 L 5 12 L 5 5 L 6 4 L 8 4 L 8 10 L 8 4 L 
9 3 L 10 3 L 11 4 L 11 10 L 11 4 L 13 4 L 14 5 L 14 10 L 14 6 L 16 6 L 17 7 
L 17 15 L 16 16 L 16 17' />

   Amazing! we get the pixel perfect result! I probably should have
let you go ahead with your 'rectification' given you ignored my
suggestions to do the above in my last two responses but perhaps you
will be happy that I actually spelled the solution out for you (which
is a lot more than you deserve based on your insulting tone in this
mail-list).

   You _are_ a beginner here you need to spend a lot more time
thinking about this stuff - the renderers are not perfect they may not
be able to give you what you want in all cases but the issues are
about a 100x deeper than you seem to think they are so listen when
people tell you things you might learn something.

FP> What about this line not being drawn properly!!!
FP> (101,101)-(109,109)

    (101.5,101.5) -> (109.5,109.5) [pixel center->pixel center] is
rendered "correctly".  In your given example the path has a bunch of
stuff hanging off the 'top' of the pixel the Adobe rasterizer probably
moves that to the 'wrong' pixel to ensure when drawn as a whole you
don't get 'drop outs (these are very complex issues and usually fixing
this particular 'broken' output would simply move the problem to other
cases - it is much better to give the rasterizer something that makes
sense to start with).

FP> How can you explain Paintbrush can do it nicely, but that Adobe
FP> can do it at all?

FP> I mean Paintbrush must have a hard time drawing a circle, it
FP> doesn't fit on every pixel, poor Paintbrush; weirdly this simple
FP> drawing tool, can do a perfect job, isn't that weird, isn't it?

    Because Painbrush shifts your circle to lie directly on pixels
'for you' SVG viewers don't move your content on you it renders the
circle where you say it should even if what you are telling it makes
no sense.  In short you can't possible describe in paintbrush (the UI
won't let you) what you are describing SVG.

>> The implementation is not the major problem your content is!  It is
>> true Adobe is clearly not a beginner in this field, but you clearly
>> are.

FP> I think I saw enough flamewar to stop responding to it. =)

    I am just stating the truth, your posts repeatedly show that you
don't know very much about the real details of vector graphics.
Received on Tuesday, 29 April 2003 08:45:03 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:24 GMT