Opened 9 years ago

Closed 8 years ago

#3423 closed defect (fixed)

TA save SVG saves nothing

Reported by: tonyforster Owned by: walter
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Turtleart Version: Unspecified
Severity: Unspecified Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

The save SVG block is giving me nothing in the Journal
There is no error log
Save picture is OK

the turtle is hidden till you click stop

I vaguely recollect something like this before, SVG being procedural rather than the finished image, maybe I am doing something wrong? Adding a Start block didnt help.

Attachments (2)

filled arc 90 svg.svg (727 bytes) - added by tonyforster 9 years ago.
filled arc 360 svg.svg (725 bytes) - added by tonyforster 9 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 9 years ago by walter

I am guessing that you were using fill blocks? There is a bug in the svg code for polygon fill (it wasn't updated to handle a syntax change when I added support for filled arcs). I've got a partial solution in [1]. Still need to add arc support.

[1] http://git.sugarlabs.org/turtleart/mainline/commit/07947d937cc274224618fbd6a94e0e6715f29124

comment:2 Changed 9 years ago by walter

In general, the patch [2] seems to work. Further testing requested.

[2] http://git.sugarlabs.org/turtleart/mainline/commit/ac5389883626ca0b33ed8bb109fa39b588086b38

comment:3 Changed 9 years ago by tonyforster

Applied both patches
able to save filled square OK
save svg only appears to save if it is docked to the blocks that are doing the drawing, if you are single stepping, nothing is saved. This is not easily discoverable.

SVG of filled arc does not work well, drawing is corrupted

Changed 9 years ago by tonyforster

Changed 9 years ago by tonyforster

comment:4 Changed 9 years ago by walter

I did a refactoring... using a cairo surface now. Seems to have solved the SVG problems. Fixed this issue too, by checking to see if an SVG block is in use, even if it is not in the current stack.

http://git.sugarlabs.org/turtleart/mainline/commit/f00e3fe2182c0bab2b802a7a988a3e0a286c8db5

comment:5 Changed 9 years ago by tonyforster

works for me
filled arc 360 ok
filled arc 90 ok
single stepped filled square ok
rotated text ok

does not record in single step if the save svg block is introduced to the canvas after the drawing is done. This is presumably a compromise to save execution time, not keeping an unnecessary record of draw events in svg format?

comment:6 Changed 9 years ago by walter

Thanks for testing.

does not record in single step if the save svg block is introduced to the canvas after the
drawing is done. This is presumably a compromise to save execution time, not keeping an
unnecessary record of draw events in svg format?

Yes. I only keep the SVG surface around if I think the user is intending to save to SVG at some point. I only make that assumption if a save SVG block is on the canvas somewhere. Otherwise, twice as much writing. I could revisit this assumption if you think it is worth the tradeoff (need to run some numbers on an XO 1 to measure the impact).

comment:7 Changed 9 years ago by tonyforster

I agree, its not worth a noticable loss in execution speed.

comment:8 Changed 9 years ago by tonyforster

xo-1.75 no measurable speed difference
blocks hidden (fastest mode)

repeat 2000 fwd100 rt90
print time

takes 9 seconds with or without a save svg on the canvas

comment:9 Changed 9 years ago by walter

Need to do further testing on the impact on memory consumption as well, but in general, I think this would be a good thing to do, since it would also mean we could add a save as svg button to the toolbar.

comment:10 Changed 8 years ago by walter

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.