11:20 p.m.
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
12:07 a.m.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:39 a.m.
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
3:41 a.m.
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?
https://bugzilla.gnome.org/show_bug.cgi?id=650213
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
11:44 a.m.
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?
>
> https://bugzilla.gnome.org/show_bug.cgi?id=650213
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
1:31 a.m.
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?
>
> https://bugzilla.gnome.org/show_bug.cgi?id=650213
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
1:42 a.m.
similar to LP Bug 806105
--
View this message in context:
http://old.nabble.com/First-results-tp32029693p32050549.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
8:41 p.m.
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2:57 p.m.
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(a)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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
8:21 p.m.
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(a)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(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
1:35 a.m.
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,
9:15 p.m.
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
http://pastebin.com/TWhxC0Mh
Alexandre Prokoudine
http://libregraphicsworld.org
8:45 p.m.
W dniu 12 lipca 2011 23:15 użytkownik Alexandre Prokoudine
<alexandre.prokoudine@...400...> napisał:
Current revision segfaults for me on startup
http://pastebin.com/TWhxC0Mh
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
2:24 p.m.
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
8:23 p.m.
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
12:13 a.m.
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
4:02 a.m.
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.
5:37 a.m.
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
7:17 a.m.
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
7:56 a.m.
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(
5:44 p.m.
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
8:36 a.m.
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;
3:58 a.m.
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?
7:37 a.m.
New subject: Re : First results
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(a)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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
5:50 p.m.
New subject: Re : 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
2:15 p.m.
New subject: Re : Re : First results
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(a)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
4499
days inactive
4528
days old
inkscape-devel@lists.inkscape.org
27 comments
11 participants
participants (11)
-
Alexandre Prokoudine -
Alvin Penner -
Andrew Lutomirski -
Ivan Louette -
John Cliff -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Preben Soeberg -
~suv