Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Regards, Krzysztof
In my limited testing with some of my most node & filter intensive files... It's SO much faster now it's not even funny. We're in the big leagues people! (note: I didn't check memory use or anything yet, not that I'm doubting, just saying that I'm running with scissors and okay with that)
Cheers, Josh
2011/7/9 Krzysztof Kosiński <tweenk.pl@...400...>
Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Regards, Krzysztof
All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2011/7/9 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Cute.
I played with clip-rule awhile back (https://bugs.launchpad.net/inkscape/+bug/171243), but I never finished the rendering part, partly because of the crazy semantics of multiple even-odd paths aren't compatible with Cairo's clipping.
Can you render the test files here correctly?
https://bugzilla.gnome.org/show_bug.cgi?id=650213
--Andy
W dniu 10 lipca 2011 02:39 użytkownik Andrew Lutomirski <luto@...2655.....> napisał:
I played with clip-rule awhile back (https://bugs.launchpad.net/inkscape/+bug/171243), but I never finished the rendering part, partly because of the crazy semantics of multiple even-odd paths aren't compatible with Cairo's clipping.
Can you render the test files here correctly?
In revision 10356 of the branch, the test files attached to the bug render correctly. I used your patch for clip-rule handling in SPStyle. A few extra bits in SPClipPath were needed too.
Regards, Krzysztof
2011/7/9 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 10 lipca 2011 02:39 użytkownik Andrew Lutomirski <luto@...2656....> napisał:
I played with clip-rule awhile back (https://bugs.launchpad.net/inkscape/+bug/171243), but I never finished the rendering part, partly because of the crazy semantics of multiple even-odd paths aren't compatible with Cairo's clipping.
Can you render the test files here correctly?
In revision 10356 of the branch, the test files attached to the bug render correctly. I used your patch for clip-rule handling in SPStyle. A few extra bits in SPClipPath were needed too.
Now some of the diagrams in my thesis will show up right in Inkscape. Thanks!
--Andy
Regards, Krzysztof
When starting a printout from XP with just one object and a filter effect (tried with blur, turbulence and colormatrix) the program crashes with:
Assertion failed: CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface->ref_count), file cairo-surface.c, line 638
When exporting the same as png file, the program performs correctly.
Regards Preben
-----Original Message----- From: Krzysztof Kosiński [mailto:tweenk.pl@...400...] Sent: 10 July, 2011 10:41 To: Andrew Lutomirski Cc: inkscape-devel Subject: Re: [Inkscape-devel] First results
W dniu 10 lipca 2011 02:39 użytkownik Andrew Lutomirski <luto@...2656....> napisał:
I played with clip-rule awhile back (https://bugs.launchpad.net/inkscape/+bug/171243), but I never finished the rendering part, partly because of the crazy semantics of multiple even-odd paths aren't compatible with Cairo's clipping.
Can you render the test files here correctly?
In revision 10356 of the branch, the test files attached to the bug render correctly. I used your patch for clip-rule handling in SPStyle. A few extra bits in SPClipPath were needed too.
Regards, Krzysztof
All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
similar to LP Bug 806105
latest devlibs dont seem to want to build it on win, giving an error due to not finding -lgomp fresh checkout, fresh devlibs and fresh mingw
Any ideas?
Cheers
John
2011/7/10 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Regards, Krzysztof
All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
John,
Are you sure you got installed with openmp support? http://wiki.inkscape.org/wiki/index.php/Win32Port
Instead of mucking digging for checkboxes in the mingw installer I just opt to choose the "option "TDM-GCC recommended, All Packages" in the TDM-GCC 4.5.1 installer".
That should fix it for you.
Cheers, Josh
2011/7/10 John Cliff <john.cliff@...400...>
latest devlibs dont seem to want to build it on win, giving an error due to not finding -lgomp fresh checkout, fresh devlibs and fresh mingw
Any ideas?
Cheers
John
2011/7/10 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Regards, Krzysztof
All of the data generated in your IT infrastructure is seriously
valuable.
Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
thanks that was it.
2011/7/11 Josh Andler <scislac@...400...>:
John,
Are you sure you got installed with openmp support? http://wiki.inkscape.org/wiki/index.php/Win32Port
Instead of mucking digging for checkboxes in the mingw installer I just opt to choose the "option "TDM-GCC recommended, All Packages" in the TDM-GCC 4.5.1 installer".
That should fix it for you.
Cheers, Josh
2011/7/10 John Cliff <john.cliff@...400...>
latest devlibs dont seem to want to build it on win, giving an error due to not finding -lgomp fresh checkout, fresh devlibs and fresh mingw
Any ideas?
Cheers
John
2011/7/10 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Regards, Krzysztof
All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2011-07-10 at 01:20 +0200, Krzysztof Kosiński wrote:
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Nice work. Well done!
Martin,
2011/7/10 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello all
The branch at lp:~tweenk/inkscape/gsoc-caching contains the first testable features of my performance improvement project. The SVG drawing is rendered to a separate surface, so it doesn't need to be redrawn every time there is an editing control drawn over it. The responsiveness of path highlighting in complex documents is improved dramatically. If you turn off real-time updates of paths and leave only real-time updates of outlines on in node editor preferences, there is also a significant improvement in responsiveness when editing complex filtered paths.
To fix some breakage with clipped groups (appears to be a Cairo problem, but I couldn't isolate it) I have substantially changed the rendering pipeline. Clipping paths are now rasterized and the drawing is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Current revision segfaults for me on startup
Alexandre Prokoudine http://libregraphicsworld.org
W dniu 12 lipca 2011 23:15 użytkownik Alexandre Prokoudine <alexandre.prokoudine@...400...> napisał:
Current revision segfaults for me on startup
I can't reproduce this. It looks like your segfault is caused by the "draw-cuboid" icon (the 3D box tool icon). I changed the icon theme and deleted the icon cache but it doesn't produce a segfault for me.
Does it also mean that LPE can be applied to text objects directly? I had to write a tutorial a while ago explaining the horrible hack to allow editable text with LPE applied to it. This could be more straightforward :)
No. This problem is unrelated to my work, because I only changed things in the renderer. The inability to use text objects as LPE input is caused by an problem in the object tree (SPText does not inherit SPLPEItem).
Regards, Krzysztof
2011/7/10 Krzysztof Kosiński <tweenk.pl@...400...>:
is composited with them using the IN operator. This allows us to handle nested clipping paths and clip-rule correctly. As an unrelated improvement, text objects can now be used as clipping paths.
Does it also mean that LPE can be applied to text objects directly? I had to write a tutorial a while ago explaining the horrible hack to allow editable text with LPE applied to it. This could be more straightforward :)
Alexandre Prokoudine http://libregraphicsworld.org
I have merged the first batch of work into trunk.
The changes for this feature are fairly localized and there is a substantial improvement in perceived responsiveness, so it would be a shame to hold it back until I'm finished with other unrelated things. The next batch of changes is likely to be more invasive. (Hint: I want to implement a Google Maps-like effect on zooming.)
Regards, Krzysztof
On 14/7/11 22:23, Krzysztof Kosiński wrote:
I have merged the first batch of work into trunk.
The changes for this feature are fairly localized and there is a substantial improvement in perceived responsiveness, so it would be a shame to hold it back until I'm finished with other unrelated things. The next batch of changes is likely to be more invasive. (Hint: I want to implement a Google Maps-like effect on zooming.)
Are there new requirements (e.g. minimal GCC version) to build trunk after the latest merge?
On Mac OS X 10.5.8 (i386) with Apple's GCC 4.2.1, I get tons of warnings from 'src/2geom/bezier-curve.h' since updating to 10451:
CXX arc-context.o In file included from ./2geom/geom.h:42, from snapped-point.h:17, from snapper.h:20, from line-snapper.h:17, from guide-snapper.h:18, from snap.h:22, from sp-namedview.h:26, from arc-context.cpp:29: ./2geom/bezier-curve.h: In copy constructor ‘Geom::BezierCurve::BezierCurve(const Geom::BezierCurve&)’: ./2geom/bezier-curve.h:50: warning: base class ‘class Geom::Curve’ should be explicitly initialized in the copy constructor
Compiler: g++-4.2 CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O0 -Wall
~suv
On Jul 14, 2011, at 5:13 PM, ~suv wrote:
Are there new requirements (e.g. minimal GCC version) to build trunk after the latest merge?
On Mac OS X 10.5.8 (i386) with Apple's GCC 4.2.1, I get tons of warnings from 'src/2geom/bezier-curve.h' since updating to 10451:
CXX arc-context.o In file included from ./2geom/geom.h:42, from snapped-point.h:17, from snapper.h:20, from line-snapper.h:17, from guide-snapper.h:18, from snap.h:22, from sp-namedview.h:26, from arc-context.cpp:29: ./2geom/bezier-curve.h: In copy constructor ‘Geom::BezierCurve::BezierCurve(const Geom::BezierCurve&)’: ./2geom/bezier-curve.h:50: warning: base class ‘class Geom::Curve’ should be explicitly initialized in the copy constructor
Compiler: g++-4.2 CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O0 -Wall
It definitely looks like actual bugs in 2geom. I can look at those tonight or tomorrow and get a patch together.
W dniu 15 lipca 2011 06:02 użytkownik Jon Cruz <jon@...18...> napisał:
CXX arc-context.o In file included from ./2geom/geom.h:42, from snapped-point.h:17, from snapper.h:20, from line-snapper.h:17, from guide-snapper.h:18, from snap.h:22, from sp-namedview.h:26, from arc-context.cpp:29: ./2geom/bezier-curve.h: In copy constructor ‘Geom::BezierCurve::BezierCurve(const Geom::BezierCurve&)’: ./2geom/bezier-curve.h:50: warning: base class ‘class Geom::Curve’ should be explicitly initialized in the copy constructor
Compiler: g++-4.2 CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O0 -Wall
It definitely looks like actual bugs in 2geom. I can look at those tonight or tomorrow and get a patch together.
I just deleted the copy constructor, it was equivalent to the default one anyway.
By the way, I think this warning is bogus, because Geom::Curve has no member variables and no constructors defined (e.g. it only has the default no-argument constructor which does nothing).
Regards, Krzysztof
On 15/7/11 07:37, Krzysztof Kosiński wrote:
W dniu 15 lipca 2011 06:02 użytkownik Jon Cruz <jon@...18...> napisał:
CXX arc-context.o In file included from ./2geom/geom.h:42, from snapped-point.h:17, from snapper.h:20, from line-snapper.h:17, from guide-snapper.h:18, from snap.h:22, from sp-namedview.h:26, from arc-context.cpp:29: ./2geom/bezier-curve.h: In copy constructor ‘Geom::BezierCurve::BezierCurve(const Geom::BezierCurve&)’: ./2geom/bezier-curve.h:50: warning: base class ‘class Geom::Curve’ should be explicitly initialized in the copy constructor
Compiler: g++-4.2 CXXFLAGS: -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O0 -Wall
It definitely looks like actual bugs in 2geom. I can look at those tonight or tomorrow and get a patch together.
I just deleted the copy constructor, it was equivalent to the default one anyway.
By the way, I think this warning is bogus, because Geom::Curve has no member variables and no constructors defined (e.g. it only has the default no-argument constructor which does nothing).
Moving to a newer GCC version is not an option, and Apple will never upgrade the GCC version they ship with Xcode due to license changes in GCC itself.
The system libs and all dependencies inkscape dynamically links to, are build with GCC 4.0.1 (on Leopard) or GCC 4.2.1 (Snow Leopard). Building just Inkscape itself with a newer version of GCC (e.g. to enable OpenMP) causes various issues (in my tests: memory allocation warnings with GCC 4.4, segfaults with GCC 4.5), which are known (i.e. reported in different places for other software too, according to google) but apparently not solvable/avoidable (?). If someone is interested to further investigate, I'll revisit my bookmarks for related information/links.
BTW - the changes to the icon naming in r10451 broke toggling the status icons in the "Layers" dialog and in the layer indicator on the status line. The icon names changed in 'src/ui/dialog/layers.cpp' ignore the status, but even after correcting those the icons do not change on click. I don't know what fixes/reverts are needed in 'src/ui/widget/imagetoggler.*'.
~suv
On 15/7/11 09:17, ~suv wrote:
BTW - the changes to the icon naming in r10451 broke toggling the status icons in the "Layers" dialog and in the layer indicator on the status line. The icon names changed in 'src/ui/dialog/layers.cpp' ignore the status, but even after correcting those the icons do not change on click. I don't know what fixes/reverts are needed in 'src/ui/widget/imagetoggler.*'.
My mistake - I didn't correct the icon names in both files: - src/ui/dialog/layers.cpp - src/ui/widget/layer-selector.cpp
With attached diff it works ok for me (no changes needed on imagetoggler.cpp).
~suv
=== modified file 'src/ui/dialog/layers.cpp' --- src/ui/dialog/layers.cpp 2011-07-15 00:21:05 +0000 +++ src/ui/dialog/layers.cpp 2011-07-15 06:48:30 +0000 @@ -582,7 +582,7 @@ _tree.set_headers_visible(false);
Inkscape::UI::Widget::ImageToggler *eyeRenderer = manage( new Inkscape::UI::Widget::ImageToggler( - INKSCAPE_ICON("object-visible"), INKSCAPE_ICON("object-visible")) ); + INKSCAPE_ICON("object-visible"), INKSCAPE_ICON("object-hidden")) ); int visibleColNum = _tree.append_column("vis", *eyeRenderer) - 1; eyeRenderer->signal_pre_toggle().connect( sigc::mem_fun(*this, &LayersPanel::_preToggle) ); eyeRenderer->signal_toggled().connect( sigc::bind( sigc::mem_fun(*this, &LayersPanel::_toggled), (int)COL_VISIBLE) ); @@ -593,7 +593,7 @@ }
Inkscape::UI::Widget::ImageToggler * renderer = manage( new Inkscape::UI::Widget::ImageToggler( - INKSCAPE_ICON("object-locked"), INKSCAPE_ICON("object-locked")) ); + INKSCAPE_ICON("object-locked"), INKSCAPE_ICON("object-unlocked")) ); int lockedColNum = _tree.append_column("lock", *renderer) - 1; renderer->signal_pre_toggle().connect( sigc::mem_fun(*this, &LayersPanel::_preToggle) ); renderer->signal_toggled().connect( sigc::bind( sigc::mem_fun(*this, &LayersPanel::_toggled), (int)COL_LOCKED) );
=== modified file 'src/ui/widget/layer-selector.cpp' --- src/ui/widget/layer-selector.cpp 2011-07-15 00:21:05 +0000 +++ src/ui/widget/layer-selector.cpp 2011-07-15 07:35:12 +0000 @@ -95,7 +95,7 @@ AlternateIcons *label;
label = Gtk::manage(new AlternateIcons(Inkscape::ICON_SIZE_DECORATION, - INKSCAPE_ICON("object-visible"), INKSCAPE_ICON("object-visible"))); + INKSCAPE_ICON("object-visible"), INKSCAPE_ICON("object-hidden"))); _visibility_toggle.add(*label); _visibility_toggle.signal_toggled().connect( sigc::compose( @@ -116,7 +116,7 @@ pack_start(_visibility_toggle, Gtk::PACK_EXPAND_PADDING);
label = Gtk::manage(new AlternateIcons(Inkscape::ICON_SIZE_DECORATION, - INKSCAPE_ICON("object-unlocked"), INKSCAPE_ICON("object-unlocked"))); + INKSCAPE_ICON("object-unlocked"), INKSCAPE_ICON("object-locked"))); _lock_toggle.add(*label); _lock_toggle.signal_toggled().connect( sigc::compose(
W dniu 15 lipca 2011 09:56 użytkownik ~suv <suv-sf@...58...> napisał:
My mistake - I didn't correct the icon names in both files:
- src/ui/dialog/layers.cpp
- src/ui/widget/layer-selector.cpp
With attached diff it works ok for me (no changes needed on imagetoggler.cpp).
Applied. It was an oversight in the script I used to make this change.
Regards, Krzysztof
On 15/7/11 19:44, Krzysztof Kosiński wrote:
W dniu 15 lipca 2011 09:56 użytkownik ~suv <suv-sf@...58...> napisał:
My mistake - I didn't correct the icon names in both files:
- src/ui/dialog/layers.cpp
- src/ui/widget/layer-selector.cpp
With attached diff it works ok for me (no changes needed on imagetoggler.cpp).
Applied. It was an oversight in the script I used to make this change.
AFAICT the same fix (diff against r10530 attached) is required for the visible/hidden icon in the path effect editor.
~suv
=== modified file 'src/ui/dialog/livepatheffect-editor.cpp' --- src/ui/dialog/livepatheffect-editor.cpp 2011-07-15 00:21:05 +0000 +++ src/ui/dialog/livepatheffect-editor.cpp 2011-08-07 08:12:39 +0000 @@ -138,7 +138,7 @@
//Add the visibility icon column: Inkscape::UI::Widget::ImageToggler *eyeRenderer = manage( new Inkscape::UI::Widget::ImageToggler( - INKSCAPE_ICON("object-visible"), INKSCAPE_ICON("object-visible")) ); + INKSCAPE_ICON("object-visible"), INKSCAPE_ICON("object-hidden")) ); int visibleColNum = effectlist_view.append_column("is_visible", *eyeRenderer) - 1; eyeRenderer->signal_toggled().connect( sigc::mem_fun(*this, &LivePathEffectEditor::on_visibility_toggled) ); eyeRenderer->property_activatable() = true;
On Jul 14, 2011, at 1:23 PM, Krzysztof Kosiński wrote:
I have merged the first batch of work into trunk.
The changes for this feature are fairly localized and there is a substantial improvement in perceived responsiveness, so it would be a shame to hold it back until I'm finished with other unrelated things. The next batch of changes is likely to be more invasive. (Hint: I want to implement a Google Maps-like effect on zooming.)
Sounds good so far. Getting the bugs found and fixed is quite worth it.
After the rest of your stuff is settled, we can take a bit of time and look at some common tricks that can be used to speed things even more.
BTW, while you were in the middle of all that, did you happen to notice how hard it might be for handles to be dynamic or user-configurable sizes?
I can't compile on Kubuntu 10.04 LTS
ivan
ivan@...1510...:~$ cd inkscape ivan@...1510...:~/inkscape$ bzr pull Using saved parent location: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/ M share/icons/icons.svg M src/2geom/bezier-curve.h M src/dialogs/clonetiler.cpp M src/dialogs/text-edit.cpp M src/dialogs/xml-tree.cpp M src/ui/CMakeLists.txt M src/ui/dialog/align-and-distribute.cpp M src/ui/dialog/fill-and-stroke.cpp M src/ui/dialog/layers.cpp M src/ui/dialog/livepatheffect-editor.cpp M src/ui/icon-names.h M src/ui/widget/layer-selector.cpp M src/verbs.cpp M src/widgets/desktop-widget.cpp M src/widgets/gradient-toolbar.cpp M src/widgets/paint-selector.cpp M src/widgets/ruler.cpp M src/widgets/select-toolbar.cpp M src/widgets/stroke-style.cpp M src/widgets/toolbox.cpp All changes applied successfully. Now on revision 10455. ivan@...1510...:~/inkscape$ make make all-recursive make[1]: entrant dans le répertoire « /home/ivan/inkscape » Making all in src make[2]: entrant dans le répertoire « /home/ivan/inkscape/src » make all-am make[3]: entrant dans le répertoire « /home/ivan/inkscape/src » CXX arc-context.o CXX box3d-context.o CXX box3d.o CXX box3d-side.o CXX conn-avoid-ref.o CXX connector-context.o CXX context-fns.o CXX desktop.o In file included from desktop.cpp:77: display/canvas-arena.h:51: error: ISO C++ forbids declaration of ‘cairo_region_t’ with no type display/canvas-arena.h:51: error: expected ‘;’ before ‘*’ token make[3]: *** [desktop.o] Erreur 1 make[3]: quittant le répertoire « /home/ivan/inkscape/src » make[2]: *** [all] Erreur 2 make[2]: quittant le répertoire « /home/ivan/inkscape/src » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /home/ivan/inkscape » make: *** [all] Erreur 2 ivan@...1510...:~/inkscape$ ^C ivan@...1510...:~/inkscape$
________________________________ De : Krzysztof Kosiński <tweenk.pl@...400...> À : inkscape-devel inkscape-devel@lists.sourceforge.net Envoyé le : Jeudi 14 Juillet 2011 22h23 Objet : Re: [Inkscape-devel] First results
I have merged the first batch of work into trunk.
The changes for this feature are fairly localized and there is a substantial improvement in perceived responsiveness, so it would be a shame to hold it back until I'm finished with other unrelated things. The next batch of changes is likely to be more invasive. (Hint: I want to implement a Google Maps-like effect on zooming.)
Regards, Krzysztof
------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
W dniu 15 lipca 2011 09:37 użytkownik Ivan Louette <ivan_louette@...48...> napisał:
I can't compile on Kubuntu 10.04 LTS ivan [SNIP]
The Cairo version shipped with 10.04 doesn't have cairo_region_t - it was introduced in Cairo 1.10. I can temporarily replace this with GdkRegion, but it is deprecated and doesn't exist at all in GTK3. It would be best if you compiled Cairo 1.11.2 from source, which will also fix serious rendering bugs:
1. Download this tarball http://cairographics.org/snapshots/cairo-1.11.2.tar.gz 2. Extract 3. ./configure && make && sudo make install 4. sudo ldconfig
Regards, Krzysztof
Thanks !
I installed Kubuntu 11.04 side by side with my 10.04 to test Inkscape devel and all goes right now with Cairo !
regards, ivan
________________________________ De : Krzysztof Kosiński <tweenk.pl@...400...> À : Ivan Louette <ivan_louette@...48...> Cc : inkscape-devel inkscape-devel@lists.sourceforge.net Envoyé le : Vendredi 15 Juillet 2011 19h50 Objet : Re: Re : [Inkscape-devel] First results
W dniu 15 lipca 2011 09:37 użytkownik Ivan Louette <ivan_louette@...48...> napisał:
I can't compile on Kubuntu 10.04 LTS ivan [SNIP]
The Cairo version shipped with 10.04 doesn't have cairo_region_t - it was introduced in Cairo 1.10. I can temporarily replace this with GdkRegion, but it is deprecated and doesn't exist at all in GTK3. It would be best if you compiled Cairo 1.11.2 from source, which will also fix serious rendering bugs:
1. Download this tarball http://cairographics.org/snapshots/cairo-1.11.2.tar.gz 2. Extract 3. ./configure && make && sudo make install 4. sudo ldconfig
Regards, Krzysztof
participants (11)
-
Alexandre Prokoudine -
Alvin Penner -
Andrew Lutomirski -
Ivan Louette -
John Cliff -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Preben Soeberg -
~suv