Vector images?

[Scott Rossi]

Mark, what you describe sounds great.  Even a subset of SVG capabilities
is very welcome.

But I have to ask, partly because I'm clueless when it comes to low level
programming, but also because I'm curious: does it make sense to have two
"realms" of graphics?  There are card based (native) graphics, and then
there are the graphics inside widgets.  I recall reading that all of the
graphics rendering in LC was going to be moved over to the skia graphics
library.  Is this what enables the display of SVG in widgets or is
graphics rendering in widgets based on something else?  What prevents the
display of SVG graphics outside of a widget?  As it stands, there are
graphics capabilities within widgets that don't apply to native graphics.
Would it not make more sense to have a single universal approach to all
graphics in LC?

And to confirm your comment, yes, some of us people are definitely
interested in your (little) development.

Best Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/20/15, 9:04 AM, "use-livecode on behalf of Mark Waddingham"
<use-livecode-bounces at lists.runrev.com on behalf of mark at livecode.com>
wrote:

>On 2015-10-09 18:57, Richmond wrote:
>> Why do I have a feeling that the ability to import vector images as
>> vector graphics
>> was meant to be one of the goals of the kickstarter?
>
>Well that very much depends on what you mean by 'vector images' ;)
>
>The exact Kickstarter stretch goal was this:
>
>   Vector Shape Object
>
>   Like the graphic object on steroids. Sub-pixel positioning,
>   shape determined by intrinsic properties (i.e. width of rectangle,
>   radius of circle etc.). 'Group' type, containing a collection of
>   shapes to be nested - and imported/exported in a (subset of) SVG.
>
>There is still some more work needed on the widget's architecture to
>make this a reality (mainly related to ensuring that the rect of the
>widget is determined by its internal geometry, rather than the other way
>round which makes BIG difference if you want to do effective and
>tile-able affine transformations and avoid animation 'jitter' from
>issues surrounding aligning to an integer grid).
>
>However, after spending some time at a weekend recently playing with a
>small subset-SVG-parsing library I found, I've come up with this:
>https://github.com/livecode/livecode/pull/3089.
>
>This widget enables rendering of simple SVG files consisting of shapes,
>paths, transforms, stroke properties, color fills, linear and radial
>gradients. This is nowhere near the whole of SVG, certainly, but is a
>useful enough subset for icons and such I'd have thought.
>
>I'm currently working out how we can hook such widgets into the 'icon'
>mechanism in the engine - meaning that such a widget could be used as
>the source of icons in buttons and imgSrcs in fields. Also, it would be
>good if there could be some sharing of the parsed SVG data structures if
>multiple SVG widgets reference the same file (a bit like referenced
>image objects share in-memory representations to minimize memory cost).
>
>It isn't quite ready for inclusion in a build so it will unlikely be in
>DP8 (due this week), I'm hoping it will be ready shortly after that
>though.
>
>Just thought people might be interested in this (little) development :)
>
>Warmest Regards,
>
>Mark.
>
>-- 
>Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
>LiveCode: Everyone can create apps
>
>_______________________________________________
>use-livecode mailing list
>use-livecode at lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode