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

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

FP> Well, it should not allow for 1 pixel mis-behavior, since this
FP> mean there is a 100% error tolerance for every pixel being drawn.

FP> In other words, for every pixel drawn a misbehaving pixel can also
FP> 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> When you draw a circle or polygon in Paint or similar, does it
FP> have a 100% pixel error? No, not at all.  Instead it draw a circle
FP> perfectly as it should.

    If I go to different drawing/painting programs I certainly can get
very different results.  I tend to agree the results you got from
Adobe aren't very good but basically SVG engines are optimized for
anti-aliased graphics.  Also you need to be _very_ careful how you
specify the circle your example:

<circle style="stroke-width:1; stroke:#000000; 
               fill:#FF0000; shape-rendering: optimizeSpeed;" 
        cx="50" cy="50" r="2"/>

    For Adobe this is a circle who's center is at the juncture of four
pixels and who's stroke lies exactly on the boundry between two pixels
(at horizontal and vertial extents).  You have described a circle that
is essentially impossible to render correctly without anti-aliasing.

    However if you shift the center of the circle to lie in the middle
of a device pixel:

<circle style="stroke-width:1; stroke:#000000; 
               fill:#FF0000; shape-rendering: optimizeSpeed;" 
        cx="50.5" cy="50.5" r="2"/>

    You will find you get a much more reasonable rendering.  Adobe
still seems to have a drop out on the top of the circle, but if you
turn off optimizeSpeed this goes away and you get very little
anti-aliasing as most pixels fall nicly on one pixel as opposed to
split across pixels.

FP> My problem is that I need aliased pixel bitmap polygon/circle to
FP> be drawn, in order to render icon without the anti-aliased, so it
FP> doesn't look like crapt. 

    Then you should describe graphics that don't _REQUIRE_
anti-aliasing to make sense (i.e. 1 pixel borders exactly on a pixel
boundry).

FP> Now I'm being forced to draw tons of rectangles instead of proper
FP> polygon/circle, to ensure that the SVG icons doesn't look like
FP> crapt at normal size (100% zoom level); however, this means that
FP> if someone zoom in, lets say at 400% zoom level, that person will
FP> see the pixel sickness effects due to rectangle being drawn,
FP> instead of a nice polygon or circle being zoomed in.

FP> What's the point of having scalable vector graphics, if we cannot
FP> write vector graphics that doesn't look like crapt at normal size
FP> and rely of bitmap faking instead???

    I think you need to learn a bit more about vector graphics before
casting aspertions.  This is not simple stuff even though it often
looks like it is on the surface.  Please have some respect!

Received on Friday, 25 April 2003 08:07:08 UTC