[squeak-dev] Bezier filled shape rendering artifacts

> On Mon, 24 Mar 2008 11:34:43 +0100, Igor Stasenko wrote:
>
>  > Looks like i found a fix.
>  > Please see description & fix on Mantis:
>  > http://bugs.squeak.org/view.php?id=6991
>
>
> Interesting. I'm trying to visualize SVG+xml's using the fine SVGMorph
>  package from SqMap (loads+works in 3.10). Do you also have a suggestion
>  for the following kind of rendering problem,

>
>  (SVGMorph fromFileStream:
>   'http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg'
>    asUrl retrieveContents contentStream
>   ) openInWorld
>
>  ... any SVG-capable web browser can render it (+Opera can scale it)
>  perfectly.
>
>  TIA.
>
>  >
>  >
>
>
>
>

> On 24/03/2008, Klaus D. Witzel <[hidden email]> wrote:
>> On Mon, 24 Mar 2008 11:34:43 +0100, Igor Stasenko wrote:
>>
>>  > Looks like i found a fix.
>>  > Please see description & fix on Mantis:
>>  > http://bugs.squeak.org/view.php?id=6991
>>
>> Interesting. I'm trying to visualize SVG+xml's using the fine SVGMorph
>>  package from SqMap (loads+works in 3.10). Do you also have a suggestion
>>  for the following kind of rendering problem,
>
> Sorry, can you check package name again? I can't find it at SqMap nor at  
> SqS

>>
>>  (SVGMorph fromFileStream:
>>   'http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg'
>>    asUrl retrieveContents contentStream
>>   ) openInWorld
>>
>>  ... any SVG-capable web browser can render it (+Opera can scale it)
>>  perfectly.
>>
>>  TIA.
>>
>>  >
>>
>

> On Mon, 24 Mar 2008 15:13:57 +0100, Igor Stasenko wrote:
>
>  > I found it, (typed SWG in search :)
>
>  :)
>
>  > Your script not works.
>  > There is no #fromFileStream: at class side.
>
>
> !SVGMorph class methodsFor: 'as yet unclassified' stamp: 'gvc 10/17/2005
>  17:39'!
>  fromFileStream: aStream
>         "Open an SVGMorph from the given stream."
>
>         |sx doc|
>         sx := aStream.
>         (aStream name endsWith: 'svgz')
>                 ifTrue: [aStream binary.
>                                 sx := (GZipReadStream on: aStream contentsOfEntireFile) upToEnd
>  asString readStream].
>         doc :=(XMLDOMParser parseDocumentFrom: sx).
>         ^self new createFromSVGDocument: doc! !
>
>
>
>  > I used following:
>  >
>  > |doc|
>  > doc:= XMLDOMParser parseDocumentFrom:
>  > 'http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg'
>  >   asUrl retrieveContents contentStream.
>  > (SVGMorph new createFromSVGDocument: doc) openInWorld
>
>
> Sure, that does it as well (it's the same).
>

>
>  > in result i got a tiny morph with little image in top-left corner of
>  > screen.
>
>
> Just alt-click it and resize it (the little halo button in the
>  bottom-right ;-)
>
>
>  > Once i trying to move it, image disappears, and if move back -
>  > it appears again. Looks like it's doesn't handle well coordinates.
>
>
> This one seems to be quite a different problem which I have as yet not
>  investigated (but I know it also happens when putting these morphs into a
>  window). The question with this one would be, "if it renders when resized,
>  why doesn't it so when moved".
>
>  But the currently interesting question is, given the example path/bezier
>  segments, is there a bug with the engine or why doesn't it render what the
>  platform browser does render. There are many examples of SVG+xml files for
>  which there isn't this sort of problems; example
>
>  - http://squeak.cobss.ch/seaside/sextant (a living Squeak desktop rendered
>  by a running Seaside server on the fly).
>
>  But I'm currently more interested to get rid of the problems with the
>  path/bezier segments of
>
>  - http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg
>

>>  > I used following:
>>  >
>>  > |doc|
>>  > doc:= XMLDOMParser parseDocumentFrom:
>>  > 'http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg'
>>  >   asUrl retrieveContents contentStream.
>>  > (SVGMorph new createFromSVGDocument: doc) openInWorld
>>
>>
>> Sure, that does it as well (it's the same).
>>
> Strange, i loaded latest version from SqMap, and there was no such  
> method.

>>  > I don't know why this particular glyph not rendered correctly, i can
>>  > only suppose that it
>>  > was defined with sequence of data, which wrongly parsed by SVGMorph.
>>  > Why i think it's not engine? Because engine can't twist point
>>  > coordinates of shape, it can only fail to fill shape correctly. And  
>> in
>>  > this glyph i see twisting coordinates, look like somewhere SVG morph
>>  > starts feeding engine with wrong coordinates.
>>
>>
>> Huh? I've spent hours checking Gary's parsing code (before posting
>>  anything here in squeak-dev) and until now saw [said the possibly blind
>>  man] no wrongdoing (even compared to a Javanese implementation which  
>> has
>>  no rendering bug). Some typos in SVGMorph's parsing method, quadratic*
>>  v.s. qubic*, but these lines wheren't used especially for A1.svg,A4.svg
>>  (which I tested most).
>>
>>  So you found something suspicious; please tell what and where (did you
>>  mean in Y4.svg?). I could use a point where to start debugging from. In
>>  which segment did you see twisted coordinates? TIA.
>>
>
> Yes, if i find something suspicious, i'll let you know.
> In attachment is a comparable rendering results from Opera (gray) and
> SVGMorph (black).

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Klaus
> D. Witzel
> Sent: 25 March 2008 7:28 AM
> To: [hidden email]
> Subject: [squeak-dev] Re: Bezier filled shape rendering artifacts
>
>
> On Tue, 25 Mar 2008 03:48:01 +0100, Igor Stasenko wrote:
>
> > On 25/03/2008, Klaus D. Witzel wrote:
> ...
> >>  > I don't know why this particular glyph not rendered correctly, i can
> >>  > only suppose that it
> >>  > was defined with sequence of data, which wrongly parsed by SVGMorph.
> >>  > Why i think it's not engine? Because engine can't twist point
> >>  > coordinates of shape, it can only fail to fill shape
> correctly. And
> >> in
> >>  > this glyph i see twisting coordinates, look like somewhere SVG morph
> >>  > starts feeding engine with wrong coordinates.
> >>
> >>
> >> Huh? I've spent hours checking Gary's parsing code (before posting
> >>  anything here in squeak-dev) and until now saw [said the
> possibly blind
> >>  man] no wrongdoing (even compared to a Javanese implementation which
> >> has
> >>  no rendering bug). Some typos in SVGMorph's parsing method, quadratic*
> >>  v.s. qubic*, but these lines wheren't used especially for
> A1.svg,A4.svg
> >>  (which I tested most).
> >>
> >>  So you found something suspicious; please tell what and where (did you
> >>  mean in Y4.svg?). I could use a point where to start
> debugging from. In
> >>  which segment did you see twisted coordinates? TIA.
> >>
> >
> > Yes, if i find something suspicious, i'll let you know.
> > In attachment is a comparable rendering results from Opera (gray) and
> > SVGMorph (black).
>
> Great (except that the colors render here as redish and grayish), thanks
> much !
>
> > Looks like i was wrong about twisting - the glyph is so small that its
> > hard to say what is there, unless you zoom it in.
>
> Yeah that's what makes the 'S' in SVG indispensable :)
>
> > I think you can try to remove drawing parts/segments step by step from
> > original svg to see where it breaking. And then you can trace why.
>
> Don't ask me how often I have already done that (in the segment assembly
> method) but, it didn't turn up anything buggy ...
>
> Nevertheless let me thank you for standing by me; often it's just
> the "you
> are not alone" strategy which kills the insect :)
>
> Will now focus on the areas you colored in the .jpg, thanks again.
>
> /Klaus
>
> P.S. the more I think about this problem the more it smells like the
> path/line/beziers do not flush the engine appropriately (similiar
> to what
> you corrected and to what Gary commented last night).
>
>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Klaus
> D. Witzel
> Sent: 25 March 2008 12:31 PM
> To: [hidden email]
> Subject: [squeak-dev] Re: Bezier filled shape rendering artifacts
>
>
> On Tue, 25 Mar 2008 12:45:48 +0100, Gary Chambers wrote:
>
> > I have noticed that the rendering is significantly improved for your
> > example
> > when scaled by a factor of 20, leading me to believe that Balloon has a
> > precision problem with small values and/or the fact that the
> minimum line
> > width is 1, regardless of any transform that may be in effect.
>
> No wonder I was mainly hunting gosts in your fine code, thank you
> Gary :)
> I'll give it a try as soon as I'm back from this afternoon's meetings.
>
>

> Though I did find a bug (rarely encountered) in
>  SVGPathMorph>>createSegmentsFromSVG.
>
>  Replace
>
>         data do: [:cmd |
>                 ((cmd = $S or: [cmd = $s]) and: ['CcSs' includes: c not])
>                         ifTrue: [lastCubicControl := position].
>                 ((cmd = $T or: [cmd = $t]) and: ['QqTt' includes: c not])
>                         ifTrue: [lastQuadraticControl := position].
>
>  with
>
>         data do: [:cmd |
>                 ((cmd key = $S or: [cmd key = $s]) and: ['CcSs' includes: c not])
>                         ifTrue: [lastCubicControl := position].
>                 ((cmd key = $T or: [cmd key = $t]) and: ['QqTt' includes: c not])
>                         ifTrue: [lastQuadraticControl := position].
>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Igor
> Stasenko
> Sent: 25 March 2008 2:30 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] Re: Bezier filled shape rendering artifacts
>
>
> On 25/03/2008, Gary Chambers <[hidden email]> wrote:
> > Though I did find a bug (rarely encountered) in
> >  SVGPathMorph>>createSegmentsFromSVG.
> >
> >  Replace
> >
> >         data do: [:cmd |
> >                 ((cmd = $S or: [cmd = $s]) and: ['CcSs'
> includes: c not])
> >                         ifTrue: [lastCubicControl := position].
> >                 ((cmd = $T or: [cmd = $t]) and: ['QqTt'
> includes: c not])
> >                         ifTrue: [lastQuadraticControl := position].
> >
> >  with
> >
> >         data do: [:cmd |
> >                 ((cmd key = $S or: [cmd key = $s]) and: ['CcSs'
> includes: c not])
> >                         ifTrue: [lastCubicControl := position].
> >                 ((cmd key = $T or: [cmd key = $t]) and: ['QqTt'
> includes: c not])
> >                         ifTrue: [lastQuadraticControl := position].
> >
> Hmm..
> is this correct notation: " 'CcSs' includes: c not "
> maybe more correct should be  ('CcSs' includes: c) not ?
> and same for ('QqTt' includes: c) not
>
> >
> >  Also, never did get to the bottom of why the page bounds
> sometimes come out
> >  wrong... (perhaps because taken from the SVG rather than computed
> >  "after-the-fact").
> >
> >  Glad someone is still using the old SVGMorph "experiment"!
>
> Okay, one more test.
> open given morph
>
> (SVGMorph fromFileStream:
>  'http://squeak.cobss.ch/JSesh/resources/glyphs/varia/Y4.svg'
>   asUrl retrieveContents contentStream
>  ) openInWorld
>
> then inspect SVGPathMorph submorph and evaluate following:
>
> 2 to: segments size do: [:i | self assert:(segments at:i) start =
> (segments at:i-1) end ]
>
> Does endpoints of adjusted segments should be equal?
> Because this test shows that some are not.
>
> | good bad |
> good := bad := 0.
> 2 to: segments size do: [:i |  (segments at:i) start = (segments
> at:i-1) end ifTrue: [ good := good +1] ifFalse: [ bad := bad +1 ] ].
> { good. bad }
>
> prints: #(86 8)
>
>
> >
> >  Regards, Gary.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Though I did find a bug (rarely encountered) in
> SVGPathMorph>>createSegmentsFromSVG.
>
> Replace
>
> data do: [:cmd |
> ((cmd = $S or: [cmd = $s]) and: ['CcSs' includes: c not])
> ifTrue: [lastCubicControl := position].
> ((cmd = $T or: [cmd = $t]) and: ['QqTt' includes: c not])
> ifTrue: [lastQuadraticControl := position].
>
> with
>
> data do: [:cmd |
> ((cmd key = $S or: [cmd key = $s]) and: ['CcSs' includes: c not])
> ifTrue: [lastCubicControl := position].
> ((cmd key = $T or: [cmd key = $t]) and: ['QqTt' includes: c not])
> ifTrue: [lastQuadraticControl := position].

> On Tue, 25 Mar 2008 12:45:48 +0100, Gary Chambers wrote:
>
>> I have noticed that the rendering is significantly improved for your  
>> example
>> when scaled by a factor of 20, leading me to believe that Balloon has a
>> precision problem with small values and/or the fact that the minimum  
>> line
>> width is 1, regardless of any transform that may be in effect.
>
> No wonder I was mainly hunting gosts in your fine code, thank you Gary  
> :) I'll give it a try as soon as I'm back from this afternoon's meetings.
>