On 6 January 2014 19:31, J.F. Rick <self@je77.com> wrote:
This message is mainly for Igor, who probably already curses every time he sees my name on the development list. But, perhaps others have had some experience with this as well.

Quite opposite. You using Athens abd helping to polish it. What could be better?
��
I'm still working on moving my touch applications to Athens. I am running into a major problem with icons. My applications tend to have quite a few icons in them. In the old BitBlt versions, I just used forms for the icons. That same approach fails with Athens as form rendering is time consuming. With just ten medium-sized forms open in my AthensWrapMorph, the system starts to crawl. My guess is that form rendering needs to be sped up before Athens can be widely adopted. Using the form as a paint, while flexible, seems pretty intense.

Right. Converting Form(s) to paint(s) is memory intensive operation. Basically, it copies contents of the form to newly created surface.
To avoid this, use caching. Here is an example from ImageMorph:

��drawOnAthensCanvas: aCanvas
���� ��
���� ��| cached |
���� ��
���� ��cached := aCanvas cacheAt: image ifAbsentPut: [
���� ������ ��image asAthensPaintOn: aCanvas.
���� ������ ��].
���� ��
���� ��aCanvas setPaint: cached.
���� ������ ��
���� ������ ��aCanvas paintTransform restoreAfter: [
���� ������ ������ ��aCanvas paintTransform translateBy: self innerBounds origin "negated".
���� ������ ��
���� ������ ������ ��aCanvas drawShape: self innerBounds.
���� ������ ��].
���� ��
without caching, rendering morphic desktop was very slow, since all icons is forms.

Anyway, for most of my applications, switching over to vector-based graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there.

First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented.

Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence.

Can you submit the fix, please? Let me know if you need commit rights .
��
Third, while ASPathConverter supports vLineTo: and hLineTo:, AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should.

should be straightforward:

vLineTo: number
������ ^ self lineTo: (absolute ifTrue: [ endPoint x@number ] ifFalse: [ 0@number ])

hLineTo: number
������ ^ self lineTo: (absolute ifTrue: [ number@endPoint y ] ifFalse: [ number@0 ])

��

Here are two examples of the kind of SVG files I would like to read:
button-swapShapes.svg��- This one fails because of vLineTo: and hLineTo:
button-erase.svg��- This one fails because of reflectedCubicBezier curves.

You mean this one?:

S/s
(shorthand/smooth CurveTo)

x2,y2
x, y

Draw a cubic Beizer curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point (x2, y2) on the previous command relative to the current point.


Yes. Not supported. Yet :)
But it should be quite easy to implement.
Jochen, i need help with completing SVG importer. So, if you can help, please do.

Can you tell me what is your login name on smalltalkhub, so i will add you to
http://smalltalkhub.com/#!/~Pharo/Athens
committers?