On 2017-11-09 15:13, hh via use-livecode wrote:
@Mark.
You wrote several times
"... the LCB canvas abilities ..., which are a superset of the HTML5
Canvas abilities"
It is just now more "planned to be a superset"?
The HTML5 canvas has for example the ability to set and get dataURLs.
And LCB doesn't even have a base64 encoder/decoder.
It is already superset in terms of anything the HTML5 canvas can draw,
the LCB canvas can draw.
Specifically, the LCB canvas is a superset because it also supports
transparency layers with local opacity, local blend modes and bitmap
effects.
The way you can get image data in is not quite the same as HTML5,
admittedly: we have from binary data, local files, resource files and
pixel data whereas HTML5 allows referencing image-like elements, remote
URLs and data URLs. (The latter are subsumed by the 'with data'
constructor for LCB images though).
Ignoring images for the moment, the critical API differences are that
the HTML5 canvas allows specifying distinct fill and stroke paints -
which are used for 'fill' and 'stroke' operations.
The latter I've already done a rough patch for here:
https://github.com/livecode/livecode/pull/6099/commits/3c706ad92dff07f6db23fb24e3755e18fe30f011
This adds fillPaint/strokePaint/fillOpacity/strokeOpacity properties; a
'draw' command; the notion of 'no paint' and a transform property. The
fill command uses the fillPaint, the stroke command uses the stroke
paint and the draw command fills (if the fill paint is not 'no paint')
then strokes (if the stroke paint is not 'no paint'). The transform
property allows you to specify the transform to be applied since the
last 'save' - this means you can change the current (local) transform by
setting a property rather than doing a little save/restore dance.
I must confess that I'm less interested in parity with the HTML5 canvas
(which one can always assume will be a subset of SVG capabilities) than
parity with SVG.
It seems a little silly to me that the HTML5 Canvas element has *not*
been 100% based around what operations you need to render a suitably
processed SVG file - particularly as all the major browsers support a
large majority of all the existing SVG specs (and so, by extension all
the major browsers must have 2d graphics support which is 'good enough'
to render SVG). (Although, to be fair here, I didn't see that potential
correspondence when I was designing the LCB Canvas API with Ian - so I
guess I can't cast too many aspersions!)
Critically, you can see the effect of these very small changes to the
LCB Canvas API by looking at the changes it allowed me to make to the
vectoricon implementation (the vectoricon.lcb diffs in the above
commit). With those changes, there is a 1-1 correspondence between
canvas commands and each SVG property and SVG shape element - which
means that any sort of 'metafile' representation of SVG is entirely
natural.
In terms of the image referencing support, then there are perhaps two
missing pieces - the ability to reference an image script object (i.e.
an image object), and the ability to reference a URL. Adding an LCB
Image data URL constructor would be straightforward - remote URLs would
be possible to, but would require a bit more infrastructure (and a
callback to use libUrl).
In terms of where we are at the moment - the above patch needs a little
more thought. Those initial changes give us a 1-1 correspondence between
flattened SVG (i.e. where it has been converted to a sequence of shapes
with fill/stroke attributes) and the LCB Canvas API; but not (strictly
speaking) a 1-1 correspondence for direct execution of an SVG file (my
last comment on the associated PR there explains that).
That patch is backwards-compatible (setting paint sets fill and stroke
paints, getting paint gets the fill paint). However, the further change
I'd like to make is three fold:
- get rid of save/restore, replacing them with begin/end (just without
creating a transparency layer)
- make all inheritable SVG fill/stroke related properties be 'the
value set since the last begin' or nothing if they haven't
- add effective forms of all the fill/stroke related properties which
return the *current* value taking into account inheritence
The above need significantly more thought with regards backwards
compatibility though.
Looking forward, there are features that full SVG needs which the LCB
canvas does not - so it would be good to add them in the same model;
however, that would be watered down somewhat if the fundamentals did not
match - which is one motivation here (another motivation here, I will
admit is an element of 'structural beauty' which is perhaps, slightly
less pragmatic!).
So - yes there are a few differences between HTML5 Canvas and LCB Canvas
currently, but there is a clear path to resolving that inline with the
goal of making the LCB Canvas (essentially) an SVG-capable canvas - i.e.
allowing implementation of rendering SVG to be as clean and as simple as
possible; with no points of friction.
Anyway, in terms of right now, it seems a bit silly to sit here with a
perfectly reasonable SVG implementation which can render all sorts of
SVG files correctly right now whilst we spend time fettling with what
are (in essence) some technical details.
We already have an object which has the right name for display of
something image-like (the image object); that object already hooks into
icons/imagesources - which is the way the majority of SVG files will
likely want to be used; so pragmatism says that the best approach is to
work to integrate what we have now into that object in a display only
way; and then look to the future to expand what we can do with SVG in
LiveCode (e.g. the 'canvas' control or whatever it might be called).
Warmest Regards,
Mark.
P.S. Could you file an enhancemnt request for 'image from url' - in the
first instance we can certainly implement data urls, remote urls will
need a fair bit more thought and time.
--
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
