Hi All,
I'm not an expert on this kind of thing, but is there a reason why we don't distribute libinkscape as a shared library? At the moment, Inkscape and Inkview share a huge amount of code and they are both pretty big executables. Presumably, we'd save a lot of installation space with a shared lib.
AV
On 5-8-2012 21:13, Alex Valavanis wrote:
Hi All,
I'm not an expert on this kind of thing, but is there a reason why we don't distribute libinkscape as a shared library? At the moment, Inkscape and Inkview share a huge amount of code and they are both pretty big executables. Presumably, we'd save a lot of installation space with a shared lib.
Reason: it is a complete waste of time and energy to try to save 15 MB of disk space (or 5 M download size).
:) Johan
I would have thought it would be much more of a saving than that, and it doesn't strike me as being a difficult thing to do (see attached patch).
I haven't tested it, but if if really is only a 15 MB saving, then fair enough.
AV
On 5 August 2012 20:39, Johan Engelen <jbc.engelen@...2592...> wrote:
On 5-8-2012 21:13, Alex Valavanis wrote:
Hi All,
I'm not an expert on this kind of thing, but is there a reason why we don't distribute libinkscape as a shared library? At the moment, Inkscape and Inkview share a huge amount of code and they are both pretty big executables. Presumably, we'd save a lot of installation space with a shared lib.
Reason: it is a complete waste of time and energy to try to save 15 MB of disk space (or 5 M download size).
:) Johan
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I guess my argument would be more along the lines of: "then someone would use it" :-) Maintaining an API is a lot of work, and the stuff that we'd want to share between Inkview and Inkscape wouldn't necessarily be things that we'd want to maintain as an API.
--Ted
On Sun, 2012-08-05 at 20:57 +0100, Alex Valavanis wrote:
I would have thought it would be much more of a saving than that, and it doesn't strike me as being a difficult thing to do (see attached patch).
I haven't tested it, but if if really is only a 15 MB saving, then fair enough.
AV
On 5 August 2012 20:39, Johan Engelen <jbc.engelen@...2592...> wrote:
On 5-8-2012 21:13, Alex Valavanis wrote:
Hi All,
I'm not an expert on this kind of thing, but is there a reason why we don't distribute libinkscape as a shared library? At the moment, Inkscape and Inkview share a huge amount of code and they are both pretty big executables. Presumably, we'd save a lot of installation space with a shared lib.
Reason: it is a complete waste of time and energy to try to save 15 MB of disk space (or 5 M download size).
:) Johan
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Attachment: shared_lib.diff === modified file 'src/Makefile.am' --- src/Makefile.am 2012-04-14 13:50:00 +0000 +++ src/Makefile.am 2012-08-05 18:28:12 +0000 @@ -24,9 +24,9 @@ internal_GDL = libgdl/libgdl.a endif
+lib_LTLIBRARIES = libinkscape.la
noinst_LIBRARIES = \
libinkscape.a \ dom/libdom.a \ libcroco/libcroco.a \ libavoid/libavoid.a \@@ -39,6 +39,7 @@ libinkversion.a
all_libs = \
$(lib_LTLIBRARIES) \ $(noinst_LIBRARIES) \ $(INKSCAPE_LIBS) \ $(GNOME_VFS_LIBS) \@@ -211,7 +212,7 @@ # ################################################
# this should speed up the build -libinkscape_a_SOURCES = $(ink_common_sources) +libinkscape_la_SOURCES = $(ink_common_sources)
inkscape_SOURCES += main.cpp $(win32_sources) inkscape_LDADD = $(all_libs)
=== modified file 'src/extension/dbus/Makefile_insert' --- src/extension/dbus/Makefile_insert 2010-07-16 22:29:25 +0000 +++ src/extension/dbus/Makefile_insert 2012-08-05 18:28:23 +0000 @@ -57,7 +57,7 @@ # DBus Interface Helper Lib ############################
-lib_LTLIBRARIES = \ +lib_LTLIBRARIES += \ libinkdbus.la
libinkdbusincludedir = $(includedir)/libinkdbus-0.48/libinkdbus
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Ted,
My personal impression was that inkview was not really maintained anyway.
Alexandre
On Mon, Aug 6, 2012 at 6:49 PM, Ted Gould wrote:
I guess my argument would be more along the lines of: "then someone would use it" :-) Maintaining an API is a lot of work, and the stuff that we'd want to share between Inkview and Inkscape wouldn't necessarily be things that we'd want to maintain as an API.
--Ted
On Mon, 2012-08-06 at 09:49 -0500, Ted Gould wrote:
I guess my argument would be more along the lines of: "then someone would use it" :-) Maintaining an API is a lot of work, and the stuff that we'd want to share between Inkview and Inkscape wouldn't necessarily be things that we'd want to maintain as an API.
Part of the reason for creating an API is the hope that there would be many more users of the library and not just two organised by the same people.
Instead of thinking about how much it will cost us, perhaps we should be thinking about how to push the library out of it's rut and into wider use. Something that will require a shared burden to maintain the API, test suites and the code itself. Reducing costs for everyone.
We could, if we were minded, ask the original requester to do the work of instigating an API, creating the documentation and staying with the project to continue the work?
Martin,
On Mon, Aug 6, 2012 at 7:49 AM, Ted Gould <ted@...11...> wrote:
I guess my argument would be more along the lines of: "then someone would use it" :-) Maintaining an API is a lot of work, and the stuff that we'd want to share between Inkview and Inkscape wouldn't necessarily be things that we'd want to maintain as an API.
I agree that it's a sticking point. I think we've also already proven bad at the stabilizing an API with lib2geom (it's a lot of work is right). We could however just say it's not stable and therefore not recommended nor actively supported for 3rd party use at this time. Also, isn't the stuff we'd want to share between the two that we wouldn't want to maintain where a private api would be appropriate?
Cheers, Josh
2012/8/6 Ted Gould <ted@...11...>:
I guess my argument would be more along the lines of: "then someone would use it" :-) Maintaining an API is a lot of work, and the stuff that we'd want to share between Inkview and Inkscape wouldn't necessarily be things that we'd want to maintain as an API.
Shipping a shared library is not synonymous with a stable API for that library. I don't think anyone expects to have a stable public API for every single DLL or SO present on their system.
+1 for a shared libinkscape or removing Inkview.
Regards, Krzysztof
On Sun, Aug 5, 2012 at 12:57 PM, Alex Valavanis <valavanisalex@...400...> wrote:
I would have thought it would be much more of a saving than that, and it doesn't strike me as being a difficult thing to do (see attached patch).
I haven't tested it, but if if really is only a 15 MB saving, then fair enough.
I think any savings is worth it.
A) I've never used inkview and my guess is a majority of users probably haven't either (I think most cases want to create and edit vector graphics and display is handled elsewhere). B) It's bloat and I'm trying to take into account the hardware and net connections in poorer countries.
Either way, this is dangerous territory you're wandering into... you might unintentionally get people like me to beg you about fixing our linux packaging while you're at it. ;)
You know, broken down to the usual stuff...
inkscape inkscape-data inkscape-data-extras inkscape-extensions inkview
Note: That wasn't an actual request, but if you felt like taking it on I'm sure you'd make lots of new friends. :D
Cheers, Josh
On Tue, Aug 7, 2012 at 3:21 AM, Josh Andler <scislac@...400...> wrote:
I think any savings is worth it.
A) I've never used inkview and my guess is a majority of users probably haven't either (I think most cases want to create and edit vector graphics and display is handled elsewhere). B) It's bloat and I'm trying to take into account the hardware and net connections in poorer countries.
+1. While I can understand that an API can be difficult to develop and maintain, I do not think it is worth to add 15 MB which nobody uses (or at least very few people actually use) to a download, especially considering those on slower connections and mentioned above.
Maybe initially one can distribute the inkview executable separately and see how many people actually need it, then later on remove it entirely once it is known that it is not in demand... Heck, whoever wants to view an SVG can just load up Inkscape!
So, it's been discussed, but let's actually ask the question. Who would be upset if we dropped inkview?
--Ted
Who would be upset if we dropped inkview?
- not me, I never use it
Alvin
-- View this message in context: http://inkscape.13.n6.nabble.com/Shared-library-tp4964983p4965172.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
No upset here.
Cheers, Josh On Sep 2, 2012 8:47 AM, "Nicolas Dufour" <nicoduf@...48...> wrote:
Who would be upset if we dropped inkview?
Not me. I used it a couple of times onlly, when trying to reproduce related bugs... Regards, -- Nicolas
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Sep 2, 2012 at 8:33 PM, Josh Andler <scislac@...400...> wrote:
No upset here.
Cheers, Josh
On Sep 2, 2012 8:47 AM, "Nicolas Dufour" <nicoduf@...48...> wrote:
Who would be upset if we dropped inkview?
Never even used it.
Alexandre Prokoudine http://libregraphicsworld.org
On 02/09/2012 16:18, Ted Gould wrote:
So, it's been discussed, but let's actually ask the question. Who would be upset if we dropped inkview?
Since we have received feature requests as well as patches for inkview during the past year, there still seem to be users out there actually interested to have a separate viewer with additional features (like the slide-show) available.
Latest related reports in the bug tracker tagged with 'inkview':
Bug #1009711 https://bugs.launchpad.net/inkscape/+bug/1009711 Feature req - pipe to inkview
Bug #901141 https://bugs.launchpad.net/inkscape/+bug/901141 Larger default size of inkview window
Bug #771916 https://bugs.launchpad.net/inkscape/+bug/771916 SPSVGSPViewWidget does not resize its canvas when changing the page size of the SVG doc
Bug #771365 https://bugs.launchpad.net/inkscape/+bug/771365 Inkview rendering with incorrect scaling when slide showing multiple files.
Bug #770595 https://bugs.launchpad.net/inkscape/+bug/770595 SPSVGView works with incorrect scale factor
OTOH there is also this (open) request:
Bug #278001 https://bugs.launchpad.net/inkscape/+bug/278001 Inkscape package contains very large (8MB) inkview binary file - please package it separately
~suv
On Sun, Sep 2, 2012 at 3:18 PM, Ted Gould <ted@...11...> wrote:
So, it's been discussed, but let's actually ask the question. Who would be upset if we dropped inkview?
--Ted
By drop do you mean abandon entirely, or not put in the main package? I dont see a problem with not putting it in the standard package, however as suv says, people clearly do use it I wouldnt want to kill it based on the fact they arent here...
I use it as quick preview for svg files, it's pretty handy for icons.
I would agree packaging it separatedly.
salud: Néstor
El dom 02 sep 2012 21:43:35 CEST, John Cliff escribió:
On Sun, Sep 2, 2012 at 3:18 PM, Ted Gould <ted@...11...> wrote:
So, it's been discussed, but let's actually ask the question. Who would be upset if we dropped inkview?
--TedBy drop do you mean abandon entirely, or not put in the main package? I dont see a problem with not putting it in the standard package, however as suv says, people clearly do use it I wouldnt want to kill it based on the fact they arent here...
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Sep 02, 2012 at 09:18:21AM -0500, Ted Gould wrote:
So, it's been discussed, but let's actually ask the question. Who would be upset if we dropped inkview?
We know that some people use it, and we also know that many people don't use it.
Evidence for the former can be seen in bug reports filed in the last year, and in various postings to inkscape-devel. I also use it myself, for its smooth slideshow-like behaviour that can't be reproduced in Inkscape proper, and isn't as good in other SVG viewers I've tried.
(The following isn't especially relevant to Inkview or shared library discussions, but it's an interesting application of SVG (and Inkview, for the reasons described above) that readers might be interested in. The meteorology service in my country publish radar images of rainfall over the last half hour, but they also publish the individual components such as the map and transparency-using PNGs of the rainfall. SVG allows combining these components along with components that I supply such as marking landmarks of interest to me so that I can more accurately see whether it's about to rain (or stop raining) where I am. I then use inkview to view a sequence of these SVGs, so that I can see how fast the rainfall is moving and hence estimate how long until it rains or stops raining.)
As for a shared library: As I was going to write before Krzysztof said it for me, I don't think we have to give thought to a stable API, I think we just bundle together whatever objects are shared between the two. From memory, when I last looked at this, that meant just about everything: the source file that describes how to draw a shape also has the code for editing that shape, which in turn pulls in other editing dependencies. I considered separating out the bits needed only for rendering, but it's something that could only be done after discussion.
pjrm.
Hm of course why didn't I think of that -- the stuff can be separated into a sharedlib without a public API being available. The private API can be shared between inkscape and inkview and the binary download size hence reduced.
But all the same, I really don't see much of a case for inkview. Sure there have been feature requests for inkview as suv pointed out, but they are like to allow piping input, resizing the window size or such. And as such I do not see what kind of a feature can apply to only inkview and not to inkscape. Surely one can add commandline switches to inkscape for defining the window size etc? Even a read-only mode for view-only?
On Tue, Sep 04, 2012 at 02:40:19PM +0530, Shriramana Sharma wrote:
But all the same, I really don't see much of a case for [a separate binary]. Sure there have been feature requests for inkview as suv pointed out, but they are like to allow piping input, resizing the window size or such. And as such I do not see what kind of a feature can apply to only inkview and not to inkscape. Surely one can add commandline switches to inkscape for defining the window size etc? Even a read-only mode for view-only?
At a technical level, one can (as I believe mental has previously suggested) merge the two binaries instead of using a shared library, i.e. have main() do
if (streq (program_name, "inkview") || have_inkview_flag) { existing_rest_of_inkview_main(); } else { existing_rest_of_inkscape_main(); }
Compared to using a shared libinkscape, this would on one hand use slightly less disk space, while on the other might be very slightly slower (to the extent that inkview is smaller; also, we might be able to avoid pulling in as many shared libraries, e.g. those to do with import/export or editing, such as spell-checking).
I wonder whether a shared library would have disadvantages for developers, e.g. whether one needs to do `make install' before testing a change, or whether it imposes link-time costs that make it worthwhile marking functions as to whether they should be exported from the library. Can others comment on whether these or other costs are likely?
I like the idea of a library that might evolve towards something more focused that encourages the development of other SVG-rendering-related programs. However, the existence of librsvg does make a hypothetical libinkrender less valuable. (Incidentally, the existence of the commonly-used librsvg does also suggest an answer to the question "what API should libinkrender have": maybe the API should be just what's needed to be able to create a wrapper with a librsvg interface, so that one can swap between librsvg and libinkrender.)
Somehow I hope that a shared library ends up being better than a merged binary, but in absence of more knowledge about those concerns above I'd prefer a merged binary.
pjrm.
On Wed, Sep 5, 2012 at 4:06 AM, Peter Moulder <peter.moulder@...2349...> wrote:
I wonder whether a shared library would have disadvantages for developers, e.g. whether one needs to do `make install' before testing a change,
I suppose one would prefer to do in-source-tree (or at least in-build-dir) testing rather than installing, and on Linux I have been able to do export LD_LIBRARY_PATH=. to allow loading sharedlibs from the current dir. (Windows allows that by default :-/)
IIUC if you enclose a series of commands in paranthesis it will execute them in a subshell and the export values in it will not affect the outer shell and this is recommended for security reasons:
[samjnaa@...2899...] (export LD_LIBRARY_PATH=. ; ./inkscape)
On Fri, Sep 07, 2012 at 05:32:12AM +0530, Shriramana Sharma wrote:
able to do export LD_LIBRARY_PATH=. to allow loading sharedlibs from the current dir.
Oh, I hadn't thought of that.
Btw, you can do
LD_LIBRARY_PATH=. ./inkscape
to localize the effect of the environment setting instead of using parens.
pjrm.
"TG" == Ted Gould <ted@...11...> writes:
TG> So, it's been discussed, but let's actually ask the question. Who would TG> be upset if we dropped inkview?
I would. I use it regularly.
Inkview is the best choice for viewing (as opposed to editing) svgs.
-JimC
On Thu, Sep 6, 2012 at 10:13 PM, James Cloos <cloos@...1016...> wrote:
I would. I use it regularly. Inkview is the best choice for viewing (as opposed to editing) svgs.
Hi -- I'd like to know what you find advantageous in inkview due to which you prefer it over inkscape itself for viewing SVGs.
"SS" == Shriramana Sharma <samjnaa@...400...> writes:
SS> Hi -- I'd like to know what you find advantageous in inkview due to SS> which you prefer it over inkscape itself for viewing SVGs.
Size, speed and the fact that it is a viewer and not and editor.
One does not want to open an editor to view a file. The UI is wrong and they are generally much heavier weight.
I just tried viewing a simple svg in inkview and inkscape, closing each as soon as the window mapped. This is on an amd rs880 box.
:; time inkview BesselI.svg
real 0m4.163s user 0m0.380s sys 0m0.127s
:; time inkscape BesselI.svg
real 1m27.183s user 1m16.044s sys 0m0.300s
Waiting even four seconds is a bit much, but ninety seconds?
With a hot cache inkview got the window mapped in under one second.
Inkscape still needed *way* too long.
Gnu time(1) gives more details. This is with a hot cache:
:; gtime -v inkview ~/BesselI.svg Command being timed: "inkview /home/cloos/BesselI.svg" User time (seconds): 0.21 System time (seconds): 0.04 Percent of CPU this job got: 45% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.57 Maximum resident set size (kbytes): 154720 Minor (reclaiming a frame) page faults: 10389 Voluntary context switches: 73 Involuntary context switches: 109 Page size (bytes): 4096
:; gtime -v inkscape ~/BesselI.svg Command being timed: "inkscape /home/cloos/BesselI.svg" User time (seconds): 77.22 System time (seconds): 0.14 Percent of CPU this job got: 98% Elapsed (wall clock) time (h:mm:ss or m:ss): 1:18.24 Maximum resident set size (kbytes): 506512 Major (requiring I/O) page faults: 25 Minor (reclaiming a frame) page faults: 33126 Voluntary context switches: 262 Involuntary context switches: 9329 File system inputs: 6040 File system outputs: 856 Page size (bytes): 4096
(I elided all of the rows which were zero, to make it easier to view.)
Those differences make inkscape useles as a viewer. Which is expected, anyway. It is, after all, an editor.
Inkview is small, fast (including in contrained environments -- it worked fine on my old pent-iii 1/2-gig laptop, even with lots of other stuff running) and efficient. It does exactly what one wants an svg viewer to do.
Calls to eliminate it are misguided at best.
P.S. Remember that most users do not follow inkscape-dev.....
-JimC
On Fri, Sep 7, 2012 at 5:43 AM, James Cloos <cloos@...1016...> wrote:
Calls to eliminate it are misguided at best.
Hi and thanks for your reply. I see your point. From what I can see the present problem with static linking is just the objectionable file size. And from previous comments of others, it is neither feasible nor necessary (given rsvg) for there to be a public Inkscape API. That doesn't mean that there can't be a private API shared as a SO/DLL between Inkscape and Inkview. IMHO that is the way to go forward given the current feedback.
P.S. Remember that most users do not follow inkscape-dev.....
You mean like we should be asking on the general inkscape users list before pulling inkview right?
On 07-09-12 02:13, James Cloos wrote:
... I just tried viewing a simple svg in inkview and inkscape, closing each as soon as the window mapped. This is on an amd rs880 box.
:; time inkview BesselI.svg
real 0m4.163s user 0m0.380s sys 0m0.127s
:; time inkscape BesselI.svg
real 1m27.183s user 1m16.044s sys 0m0.300s
Waiting even four seconds is a bit much, but ninety seconds? ...
Wow. That's impressive. I can't check the file sizes at the moment, but is there anyone with more insight into inkview who can comment on this HUGE difference? (And whether this is typical or dependent on the system, file, etc.)
Hey Jasper,
I'm just assuming a bulk of the savings is due to not dealing with icon checking and rendering, the fontconfig overhead, or interface & widget construction.
Cheers, Josh On Sep 7, 2012 12:38 AM, "Jasper van de Gronde" <th.v.d.gronde@...528...> wrote:
On 07-09-12 02:13, James Cloos wrote:
... I just tried viewing a simple svg in inkview and inkscape, closing each as soon as the window mapped. This is on an amd rs880 box.
:; time inkview BesselI.svg
real 0m4.163s user 0m0.380s sys 0m0.127s
:; time inkscape BesselI.svg
real 1m27.183s user 1m16.044s sys 0m0.300s
Waiting even four seconds is a bit much, but ninety seconds? ...
Wow. That's impressive. I can't check the file sizes at the moment, but is there anyone with more insight into inkview who can comment on this HUGE difference? (And whether this is typical or dependent on the system, file, etc.)
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (17)
-
Alex Valavanis -
Alexandre Prokoudine -
alvinpenner -
James Cloos -
Jasper van de Gronde -
Johan Engelen -
John Cliff -
Josh Andler -
Kris De Gussem -
Krzysztof Kosiński -
Martin Owens -
Nicolas Dufour -
Néstor Díaz Valencia -
Peter Moulder -
Shriramana Sharma -
Ted Gould -
~suv