5:23 a.m.
My conclusion is that 3D hardware can indeed greatly improve 2D
rendering performance. I'd really like to see these great speed
improvements pushed into a project like inkscape someday, but I am
generally not an open source developer (I'm happily stuck in the world
of Delphi programming).
Your more then welcome to become an Inkscape contributor. We have a pretty low
bar for coders two accepted patches get you BZR commit rights. They don't have
to be world changing patches either mine weren't. If that is not what you are
interested in or have the time for that is fine.
My knowledge of this area is limited so any other Developer feel free to speak
up.
My recommendations would be the following:
1. Look into the simple optimization of using shader programs to
generate inkscapes polygon fills, especially when they involve any
kind of gradients. I have written all the cross platform glsl shaders
to handle any conceivable fill type including linear, radial, and cone
with reflect, repeat, and clamp end options. I can donate that code as
a starting point if anyone would like to take a look at it.
Sure that is a good start. Small fits and start is how we finally got a OSX port
and how the OSX Aqua port is currently going. People working out a little bit
at a time until in all worked.
2. Get the cario guys interested in rolling hardware support into the
cairo api. I've talked with them about a hardware openvg backend
before. Maybe someone well respected from the inkscape can motivate
them to get moving in that direction.
We would need to finish the move to Cairo as our render, for this to be
effective. That is planned but no one is active working on the renderer right
now.
3. Take a look into openvg. I believe Trolltech has done some work
on
implementing that api in Qt. I used the Amanith openvg render and it
works okay in opengl mode. That's another thing to look into.
Unlikely that we will start using the QT toolkit, but it is a great toolkit.
4. And finally, someone might want to check out the evil Microsoft
Direct2D api. I know it's locked into Windows, but it sure should take
care of everything you'd ever need, and be blazing fast too boot.
This is even less likely IMO than a move to QT, as it is not cross platform,
currently maintaining the windows port is hard enough as we have only a
handful of active windows developers.
Joshua L. Blocher
verbalshadow
6:44 a.m.
New subject: [Inkscape-user] Future plans for speeding up Inkscape?
On 1/5/10, Joshua L. Blocher wrote:
Joshua, I'm not subscribed to the -user list, so the message there
won't reach sender perhaps.
> 2. Get the cario guys interested in rolling hardware support into
the
> cairo api. I've talked with them about a hardware openvg backend
> before. Maybe someone well respected from the inkscape can motivate
> them to get moving in that direction.
Cairo already has OpenGL and OpenVG back-ends. Experimental they are,
but they do exist. For months.
> 3. Take a look into openvg. I believe Trolltech has done some
work on
> implementing that api in Qt. I used the Amanith openvg render and it
> works okay in opengl mode. That's another thing to look into.
See above
> 4. And finally, someone might want to check out the evil
Microsoft
> Direct2D api. I know it's locked into Windows, but it sure should take
> care of everything you'd ever need, and be blazing fast too boot.
>
This is even less likely IMO than a move to QT, as it is not cross platform,
currently maintaining the windows port is hard enough as we have only a
handful of active windows developers.
+1
Alexandre
8:42 a.m.
New subject: [Inkscape-user] Future plans for speeding up Inkscape?
2010/1/5 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
Cairo already has OpenGL and OpenVG back-ends. Experimental they
are,
but they do exist. For months.
Correct. Cairo and OpenMP is the lowest level we have to go to. Any
additional optimization work should be done in Cairo, where it will
benefit more programs and more people.
The biggest gains in speed and memory consumption can be made by
replacing libnr with Cairo (reportedly, 2x reduction in memory usage
and significant perf boost). Playing with Open*L directly is going to
be a huge white elephant and a waste of time, just like the recently
removed MMX optimizations for blending which turned out to degrade
performance rather than improve it.
Regards, Krzysztof
3:15 a.m.
New subject: [Inkscape-user] Future plans for speeding up Inkscape?
Playing with Open*L directly is going to
be a huge white elephant and a waste of time, just like the recently
removed MMX optimizations for blending which turned out to degrade
performance rather than improve it.
MMX instructions degraded performance? How does that happened?
And would you tell why do you consider OpenGL huge white elephant and waste of
time?
Thanks
-----
Lukáš Tvrdý | http://lukast.mediablog.sk/log
5:30 a.m.
New subject: [Inkscape-user] Future plans for speeding up Inkscape?
2010/1/6 LukasT.dev@...400... <lukast.dev@...400...>:
MMX instructions degraded performance? How does that happened?
There are several possible reasons: new processors have other
instructions that are faster, or the 'vanilla' instructions got better
while MMX didn't, or the MMX-based implementation was substandard. I
think currently MMX is a legacy technology, with priority being given
to SSEx and other more powerful SIMD instruction sets, so their
implementation might not be a priority.
And would you tell why do you consider OpenGL huge white elephant and
waste of
time?
It is a waste of time to use a very low level API that's definitely
not designed for our use case, when we can use a much higher level API
(Cairo) that already has some experimental support for HW
acceleration. Therefore if we want improved HW accel support, we
should put it in Cairo rather than in Inkscape, so it will benefit
more people. OpenGL is definitely not a white elephant in general, but
trying to use it directly in Inkscape is.
Regards, Krzysztof
4830
days inactive
4831
days old
inkscape-devel@lists.inkscape.org
4 comments
4 participants
participants (4)
-
Alexandre Prokoudine -
Joshua L. Blocher -
Krzysztof Kosiński -
LukasT.dev＠...400...