In my quest for a more fluid experience with fewer distractions, I've
attempted to multithread the rendering. I see this has been a long
I'm using a Lenovo P40 tablet and the total frame rendering time for a
simple piece is 80 to 100ms (1920x1080, a few hundred vertices on 2
layers with no filter effects - only alpha compositing). This slow
rendering speed makes the touchscreen zooming I recently implemented
So, I tried multithreading SPCanvas::paintRectInternal() with OpenMP
by splitting the rectangle into 2 and rendering them in ||.
I used mutual exclusion for some obviously thread unsafe code like the
call to markRect in SPCanvas::paintSingleBuffer(). The rendering would
work for a few frames before it freezes (waiting threads timeout and
Then, I put other calls that I suspected were thread unsafe in
mutually exclusive blocks until I discovered _root->render() isn't
safe. No point in going further.
Excuse my naive attempt. Can anyone guess how feasible it is to
multithread the rendering? For now, I don't care if it's pixel
perfect. I just need something that's decent and doesn't crash/freeze.
I'm also wondering why the Cairo OpenGL backend isn't being used? GPU
rendering on integrated GPUs should give a nice speedup since there
should be no copying overhead.
The other place to optimize is pixman. I did some profiling (rapidly
zooming in and out with touchscreen) and >= 25% of the time is spent
in pixman rendering. I already went ahead and ported a few to AVX2 and
got ~1.3x speedup (should get more since my laptop is bottlenecked by
memory bandwidth owing to having only 1 memory channel).
Subject: Re: [Inkscape-devel] Inkscape 0.92pre5 released
Date: Sat, 31 Dec 2016 01:35:59 -0500
From: Miguel Lopez <reptillia39@...3425...><mailto:reptillia39@...3425...>
To: Bryce Harrington <bryce@...961...><mailto:bryce@...961...>
Right now, I am testing a bug with the Rotate Copies feature, and I'm
gonna file a report on that soon. So, there is going to be a little
change, but that's not too much. I'm gonna also look at gradient mesh.
Will file a bug report soon.
Well, I checked gradient meshes, and it looks like there's gonna be a
few more work to do. Yep, I will file 2 bug reports as soon as possible.
I wish I can do more, but being fatigued everyday does not help things.
Other than that, the difference between .92 and .91 is huge. I hope to
see more focus on gradient mesh, and experimental forms of gradient
somewhere between .92, and .94. Instead of a gradient mesh, I wish we
can define gradients based on points, and lines. That would also open
avenues to gradient textures/procedural textures, and would hugely
benefit vector-based interior design.
On 12/30/2016 3:37 AM, Bryce Harrington wrote:
> The 0.92pre5 source package and Windows packages are now released and
> can be downloaded from the Inkscape website:
> Thanks to everyone that contributed fixes and translation updates,
> packaging, and work on the marketing/outreach preparations.
> My hope is there will be no further changes between pre5 and the final
> release. Please download and test this release candidate as if it was
> the official 0.92.0 release. What we're looking for are issues that are
> a) so severe that we need to put off the release, or b) issues caused by
> recent changes that can be trivially fixed (e.g. one-liner patches that
> are obviously correct).
> Barring any last minute issues, things look good for finalizing the
> source package this weekend and announcing the 0.92 release early next
> We'll plan on doing a point release in a month or two. This will
> include both translation updates and bugfixes.
> To everyone that has contributed to the changes in 0.92: Great work!
> The release is just days away. :-)
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> Inkscape-devel mailing list
The 0.92pre5 source package and Windows packages are now released and
can be downloaded from the Inkscape website:
Thanks to everyone that contributed fixes and translation updates,
packaging, and work on the marketing/outreach preparations.
My hope is there will be no further changes between pre5 and the final
release. Please download and test this release candidate as if it was
the official 0.92.0 release. What we're looking for are issues that are
a) so severe that we need to put off the release, or b) issues caused by
recent changes that can be trivially fixed (e.g. one-liner patches that
are obviously correct).
Barring any last minute issues, things look good for finalizing the
source package this weekend and announcing the 0.92 release early next
We'll plan on doing a point release in a month or two. This will
include both translation updates and bugfixes.
To everyone that has contributed to the changes in 0.92: Great work!
The release is just days away. :-)
We'll be holding an Inkscape Committee meeting this Friday the 30th of
December, on #inkscape-devel, at Noon Pacific.
All in the Inkscape community are welcome to attend.
Since I suspect many people are on vacation this week, we'll play the
agenda by ear, but give focus to issues relating to the release and
current status of Spreadshirt.
Hope everyone is having a great holiday!
We're nearly done with 0.92.0 - great work everyone and thanks
especially to everyone fixing up bugs and updating translations.
Final RC will be cut Wed the 28th. Translation updates are ok to
continue landing until then. Bug fixes please check with me and expect
some friendly pushback. :-)
I'd like the final RC to be identical to what we release, so we don't
release with anything untested. So ideally there should be NO changes
after the 28th. In practice some minor polish is probably acceptable;
but if there are any significant changes we'll need to do further RC's.
The 0.92.0 release will happen this weekend or very early next week,
assuming we don't need further RC's. We need short turnarounds for
packaging so we can get announcements out swiftly. I think we can do
We can start planning for a 0.92.1 release. There's a healthy amount of
energy going into bug fixing right now, and our users will appreciate if
we continue. Some fixes will need string changes, so I'll propose we
also encourage translation updates. I would like to shoot for early
February with this release.
Additionally, a focus for 0.92.1 could be on bug management tools.
I.e., warning dialogs, workarounds, and bug reporting helper scripts.
Josh mentioned that having a button to reset old prefs could work around
some mesh problems, and I'm betting there's more we could do like that.
I was wondering if it is possible to batch convert pdf to svg with an out
put that renders the text as paths, but contains the text as metadata in
the svg file so you can search on that for words, thus easily finding the
right documents. Or eventually making output of the same file in a path
rendered version and a text containing one(though that is sub optimal). I
remember having read something about adding the text as meta data into the
SVG output, so I was wondering what the status of that is.
If so, is there a way to do this without the gui? Or at least without
starting the whole app for every pdf to be converted? I have several
hundreds to convert, so that would be nice. The tool pdf2svg does a great
job of converting pdf to SVG, but only to path, which sort of defeats the
purpose of conversion in the first place. I have to index the pdf text
into a database and then insert that data into the SVG file as metadata.
Possible, but a bit of a lot of work for a one time event.
Any artists out there using Inkscape on a drawing tablet?
I find the lack of touch and pen support very inconvenient for
serious, free hand drawing. Does anyone else find this wanting or is
working on it? C R, you mentioned it in the discussion of Jabier's
I'm using a Lenovo P40 with the Bamboo Smart AES pen, which has 2
buttons. I'd like to use the buttons to cycle between certain tools.
Preferably, panning, rotation, and scaling should work like Autodesk
Illustrator, using 2 fingers:
scale = Magnitude(p1 - p0) / Magnitude(p1_start - p0_start)
rotation = atan2(p1.y - p0.y, p1.x - p0.x) - atan2(p1_start.y -
p0_start.y, p1_start.x, p0_start.x)
pan = 0.5 * (p0 + p1) - 0.5 * (p0_start + p1_start)
Then single touch should be used to select and move objects.
Currently, single touch is indistinguishable from the mouse - stray
lines are very annoying (Wacom's palm rejection helps reduce this
though). Just like pens, touch should remember the last tool used and
switch to it when using it again.
I started implementing these and found GTK 3 has no multi touch
support on Windows and the pen support is also flaky - the source of
each event is always GDK_SOURCE_MOUSE / "Virtual Core Pointer"
instead of GDK_SOURCE_PEN, GDK_SOURCE_ERASER, or
GDK_SOURCE_TOUCHSCREEN, meaning the pen can't remember its last used
tool separately from the mouse.
For now, I've managed to implement these work arounds:
switch tools: bottom pen button cycles between cursor, pencil, and
tweak. Double clicking top button switches to eraser.
pan: hold down top pen button and drag
fingers to zoom - seems the Wacom driver recognizes zoom gestures and
translates it into mouse wheel zoom events
I am looking for a solution to convert svg files to pdf on AWS lambda.
Since inkscape has a commandline interface, it seems to be a good choice.
But for this to work inkscape would have to run on a headless linux system.
No X11, not gtk etc.
So I am wondering, can inkscape be modified so that it can compile in
I looked at the inkscape code, and at a first glance it does not seemt
to be sooo simple.
Can anyone estimate if this makes sense and how much work this would be?
The 0.92pre4 source package has been released and can be downloaded
I tried to upload it to the inkscape.org website, but kept getting a
server error. Hopefully Martin can investigate and get the source
package properly uploaded there too. :-)
This pre-release incorporates bugfixes for the recently added mesh
gradient feature, tidies up build options, adds the official about
screen, and includes numerous backports and translation updates.
>From what I can see, the reaction to the mesh gradient feature has been
quite positive, and particularly with the serious attention given to
fixing issues that have been raised, there seems to be little reason not
to ship it in our final release. I remain open to feedback to the
contrary, but at this time I suggest we proceed under the assumption
that it will be part of the release. Meanwhile, please do try the
feature out and help us advocate for its adoption by web browsers and
other SVG using applications.
Please try to avoid making any further changes on the 0.92.x tree -
consider it in final freeze before release. The one exception being
translations - the mesh gradient changes were allowed to break string
freeze, so due to that we'll be giving permission to translators for
breaking this final freeze. Ideally, I'd like to see no other changes
to the 0.92.x branch prior to release; so if you have a change you would
like to see included, please run any and all changes by me first (with
justification) before landing them.
Packagers are encouraged to prepare binary packages for the platforms we