Re: [Inkscape-devel] [Inkscape-user] Future plans for speeding up Inkscape?
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:
- 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.
- 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.
- 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.
- 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
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.
- 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.
- 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
- 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
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
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
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
participants (4)
-
Alexandre Prokoudine -
Joshua L. Blocher -
Krzysztof Kosiński -
LukasT.dev＠...400...