On 20/10/15 22:35, Scott Rossi wrote:
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?
This is a very important question to which the answer really does need
to be "Yes".
Now, I am a person who works at the "kiddy" end of LiveCode who makes no
pretensions to understand
the inner workings of an SVG file as opposed to that of a PNG file.
What I do know is that as there is a menu item to either import or
reference images that would seem
the logical place for SVG images to be handled.
A longish time ago LiveCode (then called Revolution) allowed one to
import EPS vector images
via the menu system: why SVG images need to be handled in a completely
different way vis-a-vis
the GUI entirely escapes me.
And to confirm your comment, yes, some of us people are definitely
interested in your (little) development.
The ability to import, export, manipulate and, possibly, manufacture SVG
images in LiveCode is not
a "little" development, it is very important.
Vector graphics are part of what we could call "the standard set", and
indeed have been for rather
longer than perhaps most people are aware, and RunRev's decision to drop
EPS image import
seemed odd and wrong at the time it happened: importing SVG images would
serve to rectify
what I, for one, feel was a backward move.
Best Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
More strength to your SVG elbow!
Richmond.
On 10/20/15, 9:04 AM, "use-livecode on behalf of Mark Waddingham"
<use-livecode-boun...@lists.runrev.com on behalf of m...@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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
