Regarding the serialization of Spiro control points
by Fred Brennan
Greetings,
I write from the FontForge project. Of particular interest to me is the Spiro
spline feature, which was originated around ten years ago by Raph Levien.
One thing I'd like to add, (which would benefit both our projects,) is the
ability of FontForge to understand the Inkscape Spiro serialization format.
However, there are several things about the format which to me as an outsider
appear to be defects serious enough that I have no idea how to even *import*
these splines correctly, much less export our Spiro splines to this format. I
would very much like to support the _de facto_ standard Inkscape has
originated of supporting Spiro in SVG, but I am lost.
George Williams, FontForge's original author, noticed this defect over eleven
years ago.[1] Things are virtually unchanged since then, I checked `git
blame`.
Spiro has five point types, not including beginning and ending points. They
are:
* G4 curve (o)
* G2 curve (c)
* Corner (v)
* Left Constraint ([)
* Right Constraint (])
The ASCII single letters are the normal method of Spiro serialization, as
championed by Raph Levien and by us in FontForge.
Inkscape seems to create what I will call a "pseudo-SVG path". So, it is not
really an SVG path, but rather is an SVG path which undergoes transformation
into the typical Spiro format. Inkscape stores this in the "original-d"
attribute.
So, given a Bezier spline with control points defined as (x, y, c1, c2),
Inkscape interprets a control point with only (x, y) to be a corner, meanwhile
a control point with all four is a G4 curve, and (x, y, c1, NULL) is a left
constraint while (x, y, NULL, c2) is a right constraint.
I can probably overcome this, although George Williams was right to be
skeptical of this format. There is no way I can see to define a G2 curve in
this strange "original-d" format.
Thus, this email. I write to ask a few things. I suppose first of all, what
are the chances that we can convince you guys to store Spiro splines in
plate[2] format, or another widely accepted Spiro serialization format?
Second, if we cannot convince you to do that, how do I export FontForge spiros
which contain G2 control points to Inkscape's original-d format? It's not
possible, yes? So should I just silently fail and save them as G4? The curves
will not be the same if I do that. Should I disallow export to SVG w/Spiro if
glyph contains G2 control point? That seems a steep cost that will just
confuse my users, so perhaps I should abandon the whole thing if it comes to
that.
Cordial regards,
Fredrick Brennan (@ctrlcctrlv)
[1]: https://narkive.com/63FADpG3.4
[2]: https://levien.com/garden/ppedit/README, section "Plate files"
12 months
Help adding support for dxf arc on dxf_outlines.py
by Sandro Duarte
Hi,
I'm trying to add dxf arc to the dxf_outlines extension but I'm having some
problems:
At first I'm using only the arcs that have the same radius, basically the
code goes like this
def dxf_arc(self,arc_info):
"""Draw an arc in the DXF format"""
self.handle += 1
self.dxf_add(" 0\nARC\n 5\n%x\n100\nAcDbEntity\n 8\n%s\n
62\n%d\n100\nAcDbCircle\n" % (self.handle, self.layer, self.color))
self.dxf_add(" 10\n%f\n 20\n%f\n 30\n0.0\n 40\n%f\n100\nAcDbArc\n
50\n%f\n 51\n%f\n" % (arc_info[0],arc_info[1], arc_info[2],
arc_info[3], arc_info[4])
def arc_info(previous_end_point, arc_path):
Ax = previous_end_point[0]
Ay = previous_end_point[1]
radius = arc_path[1]
Bx = arc_path[-2]
By = arc_path[-1]
...
return [center_point_x, centerpoint_y, radius, start_angle, end_angle]
The problem is for this to work it must be before converting the path to
superpath or all the svg arc information will be lost as it will become a
curves but somewhere in the code there's the information that there is some
issues when transforming(matrix) the path before converting it to superpath.
So I'm thinking if it would be possible to use something like simplepath
(but now it's decrepted) and convert the path into segments and then the
segments to curve as they go into the process_shape loop and separating the
arcs that fulfill the conditions(same radius) from the others that should
be converted to curves and then to dxf spline.
It would go like this:
path -> transform matrix -> simplepath -> separate the arcs from the others
(M L C etc) -> arcs goes to arc_info and the others goes to either dxf line
or dxf spline
as opposed to what it is now
path -> superpath -> transform matrix -> separed lines from curves to go to
dxf line and dxf spline respectively
So my questions are :
How to convert the path to some sort of superpath but without converting it
curves?
Does a command to do this exist or should I write a function to do it?
And if I should write one, what's the format of a superpath so it could
match with my function?
What was the issues of having the transform matrix before converting it to
a superpath?
It is possible to do it the way i intend?
Any help would be appreciated
2 years, 6 months
notes on Inkscape's canvas performance and caching, with GPU summary.
by NASA Jeff
There was some discussion on dev-chat about using SVG for rendering
rotation handles and performance and bitmaps came up in discussion.
This should provide a thinking point for talking about canvas performance
at Fridays meeting.
That led me onto some investigation into Inkscapes canvas performance when
rendering bitmaps and vectors and how chrome handles it. This is about the
only benefit of running on an old laptop.
Anyhow, the notes cover the whole file and subfile (z-order sandwich)
caching for all possible dynamic transforms of objects (that is excluding
node, filter, style modification etc...) which should dramatically improve
the performance of inkscape in anything to do with dynamic transformation
where perfect fidelity isn't so critical because it's blurred to the eye.
It's also very practical on the GPU which has enough fast memory and image
filtering technologies to offer good support and high fidelity with no
noticeable artifacts in the rendering.
oliverthered 9:48 PM
I just had a bit of a look at image drawing performance and there is lag
when I'm dragging the image. That means the image position is being updated
with intermediary points when the mouse has long left that point. scrolling
the view point doesn't seem to have these issues, the performance is still
slower than my web browser. That may be because the browser renders to
over-view-size bitmaps, or a composite of bitmaps and caches them, so all
scrolling involves is translating the cached bitmap.
oliverthered 10:00 PM
vector performance doesn't seem too bad, it's still not great though. does
it use intermediary bitmaps with an alpha channel that are cached so that
translating and scaling etc.. operations operate with optimum performance?
in a similar way to how true type font rendering works in most
applications, except with layers.
so say when you select something the objects with z-orders above and below
the selection are cached to bitmaps as layers so they don't have to be
rendered for every update.
obviously you get a sandwich effect if the selected objects aren't in a
z-order group.
oliverthered 11:16 PM
me running out of memory/swapping or whatever causes chrome to show it's
caching system for rendering and it uses square tiles (deciles) when
rendering this svg file. with square tiles it's easy to clip the vectors so
you can minimize redraw because in addition they over size the view.
oliverthered 11:45 PM
looking at inkscape, when the canvas size is larger than the view area
+-42? inkscape resorts to redrawing the portions of the svg file that are
out of view when they come back into view. where as chrome uses deciles so
that at most the content of the squares are redrawn if they move back into
view and are no longer in cache and at least the squares cache the content
once it's been drawn once (in an over sized view that is square by square
proportioned) it's cached and doesn't have to be drawn again for
translation exercises. with decent filtering square caching can also be
used for scale, rotate and skew with the svg file only being needed to be
redrawn when it's enlarged beyond the cache size.
There's a possibility that this may produce some unwelcome artifacts in
studio production though so it may only be workable during dynamic
operations with the svg file having to be redrawn once the dynamic (and so
blurred by the eye) operation is complete to give production quality
fidelity again.
oliverthered 11:50 PM
so all dynamic transforms of svg objects can use bitmap caching deciles as
mentioned about along with the sandwich caching I mentioned earlier when a
fraction of the svg file is modified, nodes, transform, properties, filters
etc... This should work very well on the GPU too as it's ideal for this
kind of compositing.
That should cover animated transforms and path movement (esp in CSS) and
with clipping changes to styles and filters and possibly node movement. It
should be possible to parse this information out of the file so caching can
be optimized with advanced knowledge and not have to be done with "on the
fly" optimization for the various fragments which would get messy.
2 years, 6 months
Discussion for the next developers meeting
by NASA Jeff
I missed the last developers meeting but intend to make the next one. I'm
still in Istanbul and I've had a good chance to think things through more
thoroughly and simplify things, still I'll have to be briefer that I
otherwise would be as I don't have access to all my resources and am
working on a very old laptop.
Points:
-Pitfalls of CSS and Javascript and indeed SIML, which is now deprecated.
*I have some examples of CSS and Javascript I've put together, I'll make
sure all the examples are in both CSS and Javascript so the pitfalls can be
seen.
-Possibility of a dual implementation model, both CSS and Javascript. CSS
being limited to just CSS and fully editable in the GUI, Javascript only
limited by way of features available (re security etc...) but not being
fully editable in the GUI, inkscape isn't an IDE.
-Performance issues with Firefox ECMA scripting engine on older machines.
-Options for implementing security beyond that provided by the ECMA engine
by default.
-Modular design, allowing the ECMA engine and APIs to more easily be
integrated with other open source applications.
*Engine integration,
*API modules providing and API view with module availability restricted
based on use. i.e. Runtime tool extensions need APIs that should not be
available to SVG documents.
-Lightly cover extra tools and GUI changes required for animation and
interactivity etc... This will require some mockups to have a proper
discussion about.
-Possibility of assistance from Universities by way of taking on some of
the work as elements of research projects.
-Potential for revenue generation in a souped up version.
-Discuss a Python2/3 implementation written in Javascript that I've used
via University. This would allow for existing Python plugins that are
apparently quite broken at the moment to be ported to javascript should the
time come
-Potential for macro recording and real-time extensions, e.g. new drawing
tools like the shape recognition extension I've been working on.
Finally,
-Canvas performance, options available and discuss the current
implementation and bottlenecks and how this can be moved forward into the
up and coming OpenGL, Vulkan etc.. implementation.
2 years, 6 months
c++17 usage
by René de Hesselle
Developers,
in our next meeting I'd like to discuss c++17 usage - specifically new
std library features (https://wiki.inkscape.org/wiki/index.php?title=C%2B%2B17).
Allow me to be blunt: so far we've achieved nothing but to increase complexity.
For the introduction of 'filesystem' alone we already had to introduce three different
strategies:
- use std::filesystem as default for up-to-date gcc toolchains
- use boost::filesystem on macOS to not break support for older OS releases
- add -lstdc++fs linker flag for gcc 8.x
I propose to refrain from using std c++17 library features and go for boost
on all platforms where applicable (e.g. boost::filesystem). This way we
avoid introducing new platform/compiler specific code paths that don't bring
any benefit.
René
2 years, 6 months
tuning the canvas
by NASA Jeff
I missed the dev meet up, I'm on holiday in Istanbul at the moment, here's
some additional thoughts i had nodding off last night:
I don't know what the performance bottle necks in the canvas are but i had
a think about vector graphics performance and this is what I identified:
caching of objects and image sections, reducing the fidelity when an
object is being modified dynamically, improved drawing algorithms
(integer) ... that's a no brainier (fits in with fidelity), clipping (which
also fits in with caching), and finally JIT compiling drawing operations
with dynamic elements in their inner loops so that they can be properly
optimized out, vectorized and unrolled etc...
2 years, 6 months
canvas performance
by NASA Jeff
at the very least it should be podssijble to switch over to almost pure
integer rendering with AA disabled to get enough performance to preview
animations in real time.
2 years, 6 months
canvas rasterizing performance
by NASA Jeff
from what's bewen said it seems like the canvas has some performance
issues. I have quite a bit of background in relation to tuning rendering
engines for performance. help i used to do 3d animated graphics on a 386
with a few mewg of ram. even sqeuuzed a simple cad package onto as bbc
computer with 32k of memory.
basically, if i get time i'll take a look at it and tyry to
identify what the performance bottle knecks are and how to improve them.
2 years, 6 months
