NEW: speedups, Outline mode
(This and the following messages describe new stuff in CVS and thus in 0.44, not 0.43)
Recently I committed a few rendering speedup patches that I've been testing for a few weeks. It's still far from Xara speed, but the difference is noticeable.
1. As you probably noticed, screen redraw is done in chunks (typically horizontal strips). The maximum size of the chunk was 64K, which is pretty small. (Lauris had a strange idea that Sodipodi must run fine on a system with 32Mb RAM.) On the other hand, rendering each chunk causes a complete stroking and uncrossing of the paths touched by the chunk, which is especially expensive for paths with strokes, and even more so for dash patterns. This means the monstrous livarot functions were called a lot more often than necessary.
I increased the chunk size to 256K, and that helped a lot. In some critical situations (complex stroked/dashed paths at high zooms) it's now up to 3 times faster; typically at least 10% faster. Node editing is also noticeably snappier because it involves a lot of path rendering. I then tried 1M chunks, but even though this made stroke/path rendering still faster, for some reason it slowed down rendering of files with lots of semitransparent gradients. So in the end, I settled on 256K. The gradient slowness with large chunks needs further investigation.
2. When rendering transparent overlays, Inkscape spends a lot of time calculating NR_PREMUL(c,a) defined as (((c) * (a) + 127)/255). I changed the division to
FAST_DIVIDE_BY_255(v) ((((v)<< 8) + (v) + 257) >> 16)
borrowed from Mozilla and got about 10% speedup on complex documents with transparency.
3. An error in sp-canvas.cpp caused a complete extra screen redraw after each zoom operation. That is, after you press "+" in a complex drawing, Inkscape redraws, but for some time after that it remains still unresponsive because it does that second redraw (invisibly for you, i.e. nothing changes on the screen). I fixed that, and now zooming is much more pleasant in complex docs.
4. It turned out pretty easy to code an Outline ("wireframe") display mode. In it:
- all paths and shapes are shown as inverse (black on light background and vice versa) outlines of constant width (i.e. 1 screen pixel regardless of zoom), without fill;
- text is painted by inverse fill color without stroke;
- bitmaps are shown as is;
- any opacity and gradients are ignored.
Since Inkscape's display of path strokes is the slowest part of its renderer, the outline mode is usually not drastically faster than regular mode (usually 10% to 50% faster), and in some cases it may even be slower. However, the value of the outline mode is not only in its speed; it is a good way to get an idea of the structure and objects of your document, and it is convenient for precision node editing and for finding "stray objects". The switch from normal to outline view and back (View > Display mode) works on the fly. (As for a non-AA mode, I have no idea how to do it, and anyway I doubt that it will give a noticeable speedup at all.)
I'm also really looking forward to Xara opening its code. I do plan to attempt to borrow their renderer, or parts thereof, into Inkscape, now that I know that ins and outs (but not the guts) of our own renderer fairly well, but I cannot promise anything - this may turn out prohibitively difficult. We'll see.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Quoting bulia byak <buliabyak@...400...>:
- When rendering transparent overlays, Inkscape spends a lot of
time calculating NR_PREMUL(c,a) defined as (((c) * (a) + 127)/255). I changed the division to
FAST_DIVIDE_BY_255(v) ((((v)<< 8) + (v) + 257) >> 16)
borrowed from Mozilla and got about 10% speedup on complex documents with transparency.
Ah, careful with macros. Because FAST_DIVIDE_BY_255 is a macro, the parameters get evaluated multiple times.
given:
#define NR_PREMUL(c,a) (FAST_DIVIDE_BY_255(((c) * (a) + 127)))
You get expansions like:
NR_PREMUL(exp1, exp2) =>
(FAST_DIVIDE_BY_255 (((exp1) * (exp2) + 127))) =>
(((((((exp1) * (exp2) + 127)))<< 8) + (((exp1) * (exp2) + 127))) + 257) >> 16))
Where exp1 and/or exp2 are complex expressions, this could be much slower than it needs to be, and if they have side-effects, the duplication may also alter the semantics of the code.
I suspect you will be able to get an additional performance benefit if you convert these macros to inline functions, because their parameters would no longer be getting calculated multiple times.
e.g.:
inline int fast_divide_by_255(int v) { return ( ( v << 8 ) + v + 257 ) >> 16; }
inline int nr_premul(int c, int a) { return c * a + 127; }
(I am making their arguments and return values 'int', since that is normally what the compiler promotes char arithmetic to anyway.)
-mental
On 11/11/05, mental@...3... <mental@...3...> wrote:
Ah, careful with macros. Because FAST_DIVIDE_BY_255 is a macro, the parameters get evaluated multiple times.
I know that, and I fixed one such bug already.
Where exp1 and/or exp2 are complex expressions, this could be much slower than it needs to be, and if they have side-effects, the duplication may also alter the semantics of the code.
Mostly the expressions are simple array accesses, e.g. d[3]
I suspect you will be able to get an additional performance benefit if you convert these macros to inline functions, because their parameters would no longer be getting calculated multiple times.
Tried that too, no tangible benefit
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Fri, Nov 11, 2005 at 11:43:59AM -0500, mental@...3... wrote:
Quoting bulia byak <buliabyak@...400...>:
- When rendering transparent overlays, Inkscape spends a lot of
time calculating NR_PREMUL(c,a) defined as (((c) * (a) + 127)/255). I changed the division to
FAST_DIVIDE_BY_255(v) ((((v)<< 8) + (v) + 257) >> 16)
borrowed from Mozilla and got about 10% speedup on complex documents with transparency.
Ah, careful with macros. Because FAST_DIVIDE_BY_255 is a macro, the parameters get evaluated multiple times.
An alternative is to change ((v) << 8) + (v) to 257 * (v): I'm told that gcc has for ages emitted equivalent code for these, and I've just verified that g++-4.0.2 -O2 emits equivalent code on x86 (except swapping the roles of %eax and %edx). I believe it's also more readable. (I'd consider 0x101 instead of 257, though that assumes that v is already unsigned or at least non-negative.)
We could further change (v) * 257 + 257 to ((v) + 1) * 257. Again, this makes no difference to code emitted by g++-4.0.2 -O2 on x86 (not even differing in register assignment this time), so this one's just a readability decision (at least on this platform).
pjrm.
On Fri, 11 Nov 2005, Alexandre Prokoudine wrote:
Date: Fri, 11 Nov 2005 23:54:57 +0300 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: speedups, Outline mode
On 11/11/05, bulia byak wrote:
- It turned out pretty easy to code an Outline ("wireframe")
display mode.
What would be default shortcuts to switch between Normal and Outline display modes (remembering that there might be more modes in future)?
I'm tempted by Alt+1 and Alt+2 etc but having keybindings for everything should not be necessary. In fact Inkscape has become a prime example of why you shouldn't try and have keybindings for everything because it makes it a nightmare to change anything.
When you have something important that really needs a keybinding you have all sorts of problems. Keybindings should really be reserved for things which need to be accessed frequently. Sometimes a keybinding only hides the fact that a more streamlined and automated workflow is needed (like in the case of Bitmap Export where ideally the whole process would be automated instead of micro-optimising the dialog and keybindings).
So is this a feature users are going to want to turn on and off frequently or is it like Rulers or Scrollbars or other features which dont really need to be changed so often they require a keybinding for fast access?
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
It toggles, why would you need 2 keybidings? surely one will do it.
--- Alan Horkan <horkana@...44...> wrote:
On Fri, 11 Nov 2005, Alexandre Prokoudine wrote:
Date: Fri, 11 Nov 2005 23:54:57 +0300 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: speedups, Outline mode
On 11/11/05, bulia byak wrote:
- It turned out pretty easy to code an Outline ("wireframe")
display mode.
What would be default shortcuts to switch between Normal and
Outline
display modes (remembering that there might be more modes in
future)?
I'm tempted by Alt+1 and Alt+2 etc but having keybindings for everything should not be necessary. In fact Inkscape has become a prime example of why you shouldn't try and have keybindings for everything because it makes it a nightmare to change anything.
When you have something important that really needs a keybinding you have all sorts of problems. Keybindings should really be reserved for things which need to be accessed frequently. Sometimes a keybinding only hides the fact that a more streamlined and automated workflow is needed (like in the case of Bitmap Export where ideally the whole process would be automated instead of micro-optimising the dialog and keybindings).
So is this a feature users are going to want to turn on and off frequently or is it like Rulers or Scrollbars or other features which dont really need to be changed so often they require a keybinding for fast access?
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
On 11/12/05, John Cliff <simarilius@...36...> wrote:
It toggles, why would you need 2 keybidings? surely one will do it.
It toggles _now_ :) And there might be more display modes later (Xara Xtreme has 4)
I'm not sure how good it will be to change a keybinding people got used to. For me, Inkscape's invention of "#" and "|" for toggling grid and guides was so useful that I use it in both GIMP and Scribus now, bypassing their defaults, and I don't have any probs. But people are different.
Alexandre
On Sat, 12 Nov 2005, Alexandre Prokoudine wrote:
Date: Sat, 12 Nov 2005 20:17:59 +0300 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: speedups, Outline mode
On 11/12/05, John Cliff <simarilius@...36...> wrote:
It toggles, why would you need 2 keybidings? surely one will do it.
It toggles _now_ :) And there might be more display modes later (Xara Xtreme has 4)
I'm not sure how good it will be to change a keybinding people got used to. For me, Inkscape's invention of "#" and "|" for toggling grid and guides was so useful that I use it in both GIMP and Scribus now,
I know the feeling. (Incidentally I'm surprised you are toggling those items frequently enough to want keybindings for them.) Ask any Vi or Emacs user how attached they are to their keybindings, I think most wouldn't want to have it any other way.
I was heavily using a program which had an unusual keybinding for Close. Since I've reconfigured it to use Ctrl+W as I would normally expect I find even I have gotten used to what I know was a bad keybinding and continue to hit the incorrect keybindings. Bad habits are hard to break and sometimes you end up with a different bad habit instead. Bad habits need to be broken and you just have to do it right and then try to fix the next thing and the next thing even if things get a little worse in the short term.
- Alan
On Sat, 12 Nov 2005, John Cliff wrote:
Date: Sat, 12 Nov 2005 08:33:46 -0800 (PST) From: John Cliff <simarilius@...36...> To: inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: speedups, Outline mode
It toggles, why would you need 2 keybidings? surely one will do it.
As Alexandre clearly explained the assumption is there will be more than just Normal and Outline mode:
What would be default shortcuts to switch between Normal and Outline display modes (remembering that there might be more modes in future)?
It is not unreasonable to plan for that rather than bolting arbitrary (bad) keybindings onto what we have right now and be screwed when things need to be changed later.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Fri, 2005-11-11 at 03:20 -0400, bulia byak wrote:
I then tried 1M chunks, but even though this made stroke/path rendering still faster, for some reason it slowed down rendering of files with lots of semitransparent gradients. So in the end, I settled on 256K. The gradient slowness with large chunks needs further investigation.
It might be due to cache effects.
-mental
participants (7)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
bulia byak -
John Cliff -
MenTaLguY -
Peter Moulder