Jakub "Jimmac" Steiner has reviewed Inkscape 0.40 on Ubuntu Linux. http://primates.ximian.com/~jimmac/blog/Artwork/Inkscape
I've CC'ed this message to Jimmac and I'll try to quickly answer some of his questions and address the ones which are known issues. I encourage you all to read his comments which I found very interesting. I didn't want to crosspost to the user list, I'll try and remember to post the link there later when this thread is done.
You may already be familiar with Jimmac or at be familiar with his work because he's created significant amounts of artwork from Gnome and he works for Ximian. http://jimmac.musichall.cz/
The review is pretty thorough (long for a journal entry) and I wouldn't be surprised if various news sources pick up on it (but I'm not going to be the one feeding it to them).
It is great that he has finally given Inkscape a try.
Read his post first to see the praise and suggestions which I've skipped for brevity. I'll try and respond to some of his questions and criticisms:
Jimmac mentions things not being consistant with the GNU Image Manipulation Program. Hopefully as things get more configurable and more standard widgets are used (part of the plan) users will be able to resolve much of that for themselves. Some of the inconsistancies will need careful work to figure out what is really the best solution (and I'm trying not to be contraversial so I'll move on).
Layer support is ... unfinished
Work in progress
Vector icons ... good idea [but] it doesn't work in my opinion
there is workin in progress (already in CVS I believe) that allows Inkscape to use different icon themes (but it is not complete, I can elaborate more later as needed).
two rows of tabs in the tool options
mockups for a new preferences dialog were done, no tabs a bit more like the gimp. implementation seems inevitable, others may know but I wont guess when.
some sort of library [for] brushes, gradients
thats a known issue but not specifically on the roadmap http://inkscape.org/roadmap.php i think there are a few requests already filed
Deleting objects with Backspace. While Del works, my powerbook doesn't
have the del key ;).
dont think anyone has mentioned that before.
Object blending. Select two objects and pick how many inbetween states
you want or optionally a path along which to do the morph. Essential time saviour when duplicating objects
Sounds like Tweening to me. Complicated but again I'm reasonably sure there are requests for it already. Knowing the Inkscape developers someone will come along and surprise us with this feature out of nowhere.
Converting stroke into objects. Sometimes you want to have more control
about the dotted outline.
I get the feeling this might be already be possible. Anyone?
If you didn't read Jimmacs review of Inkscape http://primates.ximian.com/~jimmac/blog/Artwork/Inkscape my comments may seem out of context but I hope they were interesting/useful and I think I've managed to be (relatively) brief.
Sincerely
Alan Horkan
Free SVG Clip Art http://OpenClipArt.org Dia is for Diagrams http://gnome.org/projects/dia/ Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com
On Fri, 21 Jan 2005, Alan Horkan wrote:
Jakub "Jimmac" Steiner has reviewed Inkscape 0.40 on Ubuntu Linux. http://primates.ximian.com/~jimmac/blog/Artwork/Inkscape
This is great, I'm glad to see this high level critique. I was pleased with the feedback. It's true there's still much to work on but Jimmac seemed to appreciate the progress we've made so far.
I've CC'ed this message to Jimmac and I'll try to quickly answer some of his questions and address the ones which are known issues. I encourage you all to read his comments which I found very interesting. I didn't want to crosspost to the user list, I'll try and remember to post the link there later when this thread is done.
Alan, if you'd be interested, I'd like to co-author an official response with you. If you have time, it would be great to post a response in the Feb timeframe.
Jimmac mentions things not being consistant with the GNU Image Manipulation Program. Hopefully as things get more configurable and more standard widgets are used (part of the plan) users will be able to resolve much of that for themselves. Some of the inconsistancies will need careful work to figure out what is really the best solution (and I'm trying not to be contraversial so I'll move on).
This is true. It is worth noting that when we started, there was a feeling that blind adherance to Gimp's interface approach was holding us back, so for Inkscape we were especially open to non-Gimp ideas. But the current Gimp is much different than had gone before.
Layer support is ... unfinished
Work in progress
Yes, we needed to get _something_ out for layer usage in that release. Hopefully for 0.42 we can give more. I think there's still some uncertainty over exactly how this should function, but hopefully we can get some good ideas incorporated.
Vector icons ... good idea [but] it doesn't work in my opinion
there is workin in progress (already in CVS I believe) that allows Inkscape to use different icon themes (but it is not complete, I can elaborate more later as needed).
I'm really glad he brought this up - this is something I too have felt similarly about.
I have felt that the best approach for us would be to use SVG as the originating syntax, but render to png or bmp, and load those. From my perspective the benefit would be in load times; I think they'd have other benefits as well.
two rows of tabs in the tool options
mockups for a new preferences dialog were done, no tabs a bit more like the gimp. implementation seems inevitable, others may know but I wont guess when.
I wouldn't bet money on the dual-row tab approach surviving the gtkmm redesign work.
some sort of library [for] brushes, gradients
thats a known issue but not specifically on the roadmap http://inkscape.org/roadmap.php i think there are a few requests already filed
It's in the roadmap but not for a while. This is definitely an area we could use a highly motivated developer to take charge. We have a lot of rough ideas but what we need is someone with a strong vision and good coding chops to put it into practice.
Deleting objects with Backspace. While Del works, my powerbook doesn't
have the del key ;).
dont think anyone has mentioned that before.
Nope, but Bulia's already implemented it. ;-)
Object blending. Select two objects and pick how many inbetween states
you want or optionally a path along which to do the morph. Essential time saviour when duplicating objects
Sounds like Tweening to me. Complicated but again I'm reasonably sure there are requests for it already. Knowing the Inkscape developers someone will come along and surprise us with this feature out of nowhere.
Agreed. Very cool idea, certainly not on the roadmap, but definitely the sort of thing to suddenly pop into being. ;-)
Converting stroke into objects. Sometimes you want to have more control
about the dotted outline.
I get the feeling this might be already be possible. Anyone?
I'm not sure what he meant by this one. You may be right that it's already possible.
Bryce
On Sat, 22 Jan 2005 21:45:45 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:
Alan, if you'd be interested, I'd like to co-author an official response with you. If you have time, it would be great to post a response in the Feb timeframe.
Well, actually I answered most of his points yesterday in comments. And he said he would join the devel list, so we might just sit and wait for him here :)
I have felt that the best approach for us would be to use SVG as the originating syntax, but render to png or bmp, and load those. From my perspective the benefit would be in load times; I think they'd have other benefits as well.
I disagree, as I said loading times of icons are not any kind of bottleneck right now.
mockups for a new preferences dialog were done, no tabs a bit more like the gimp. implementation seems inevitable, others may know but I wont guess when.
I wouldn't bet money on the dual-row tab approach surviving the gtkmm redesign work.
Two (and more) rows of tabs are bad when this is actually one row which is too long and is wrapped. Here, it's not the case. It's a hierarchy. And as such it makes it more logical and convenient, not less.
It's in the roadmap but not for a while. This is definitely an area we could use a highly motivated developer to take charge. We have a lot of rough ideas but what we need is someone with a strong vision and good coding chops to put it into practice.
Agreed
Deleting objects with Backspace. While Del works, my powerbook doesn't
have the del key ;).
dont think anyone has mentioned that before.
Nope, but Bulia's already implemented it. ;-)
yesterday
Object blending. Select two objects and pick how many inbetween states
you want or optionally a path along which to do the morph. Essential time saviour when duplicating objects
Sounds like Tweening to me. Complicated but again I'm reasonably sure there are requests for it already. Knowing the Inkscape developers someone will come along and surprise us with this feature out of nowhere.
Agreed. Very cool idea, certainly not on the roadmap, but definitely the sort of thing to suddenly pop into being. ;-)
It should not be difficult to borrow the algorithm from Skencil, which has always had it. We just need a coder willing to work on that.
Converting stroke into objects. Sometimes you want to have more control
about the dotted outline.
I get the feeling this might be already be possible. Anyone?
I'm not sure what he meant by this one. You may be right that it's already possible.
Of course it is. The second command in the Path menu.
On Sun, 23 Jan 2005, bulia byak wrote:
On Sat, 22 Jan 2005 21:45:45 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:
Alan, if you'd be interested, I'd like to co-author an official response with you. If you have time, it would be great to post a response in the Feb timeframe.
Well, actually I answered most of his points yesterday in comments. And he said he would join the devel list, so we might just sit and wait for him here :)
Ah, cool. Well I was thinking just from a PR perspective it could show that we're listening and responding to feedback from users, if we published our response to the comments. I figure if a user goes to the trouble of publically writing up all the issues they see, the public would appreciate seeing the software provider's responses.
I have felt that the best approach for us would be to use SVG as the originating syntax, but render to png or bmp, and load those. From my perspective the benefit would be in load times; I think they'd have other benefits as well.
I disagree, as I said loading times of icons are not any kind of bottleneck right now.
Guess we can disagree on this one. For my usage, fast load-up times are critical. I am annoyed every time I have to wait > 1 sec for Inkscape to start that it doesn't take < .5 sec. ;-)
Admittedly, I could probably be satisfied if inkview were to take < .5 sec to load.
mockups for a new preferences dialog were done, no tabs a bit more like the gimp. implementation seems inevitable, others may know but I wont guess when.
I wouldn't bet money on the dual-row tab approach surviving the gtkmm redesign work.
Two (and more) rows of tabs are bad when this is actually one row which is too long and is wrapped. Here, it's not the case. It's a hierarchy. And as such it makes it more logical and convenient, not less.
Tabs are the wrong metaphor for representing hierarchies. (Period.) Some of the ideas that users have proposed are much better than what we have. I look forward to seeing what the team can do, and expect we'll have a much superior solution to what we're currently providing.
Bryce
On Sat, 22 Jan 2005 21:45:45 -0800, Bryce Harrington wrote:
I'm really glad he brought this up - this is something I too have felt similarly about.
I have felt that the best approach for us would be to use SVG as the originating syntax, but render to png or bmp, and load those. From my perspective the benefit would be in load times; I think they'd have other benefits as well.
Actually the main problem is that icons have to be redrawn for small sizes. It doesn't matter when or with what you do the scaling, SVGs generally just don't scale well to 16x16 type sizes. Jimmac seems these days to draw icons by hand in the Gimp for small sizes, and then provide an SVG as well for larger sizes.
Loading time is usually a non-issue here, SVG icons usually load faster than PNGs do anyway because of the overhead of the gzip compression (or that is what I have read, strange but true).
If you want to optimise loading time then I have a bunch of tips on that, it's kind of a pet hate of mine too (not Inkscape specifically, just apps in general). Working closely with MS Office and Internet Explorer, both of which start much faster than the native equivalents, has taught me quite a bit about how to make programs start up fast ;)
thanks -mike
On Sun, 23 Jan 2005 12:32:46 +0000, Mike Hearn wrote:
On Sat, 22 Jan 2005 21:45:45 -0800, Bryce Harrington wrote:
I'm really glad he brought this up - this is something I too have felt similarly about.
I have felt that the best approach for us would be to use SVG as the originating syntax, but render to png or bmp, and load those. From my perspective the benefit would be in load times; I think they'd have other benefits as well.
Actually the main problem is that icons have to be redrawn for small sizes. It doesn't matter when or with what you do the scaling, SVGs generally just don't scale well to 16x16 type sizes. Jimmac seems these days to draw icons by hand in the Gimp for small sizes, and then provide an SVG as well for larger sizes.
IMHO the problem is that SVG does not support hinting like TrueType fonts do.
Regards, Helge
On Sun, 23 Jan 2005, Mike Hearn wrote:
Loading time is usually a non-issue here, SVG icons usually load faster than PNGs do anyway because of the overhead of the gzip compression (or that is what I have read, strange but true).
Hmm, well I've heard this several times but have never seen numbers. I suppose it's possible, if you're comparing png vs. librsvg. But if you're caching the icons for speed, you'd probably be using a bmp format, not png anyway.
If you want to optimise loading time then I have a bunch of tips on that, it's kind of a pet hate of mine too (not Inkscape specifically, just apps in general). Working closely with MS Office and Internet Explorer, both of which start much faster than the native equivalents, has taught me quite a bit about how to make programs start up fast ;)
Yes, I'd love to hear your tips. The icon loading is something I've measured and know roughly how large of an impact it is, but if there are other things that can be done to speed it up, that'd be great to hear.
Bryce
On Sun, 23 Jan 2005 10:18:55 -0800, Bryce Harrington wrote:
Yes, I'd love to hear your tips. The icon loading is something I've measured and know roughly how large of an impact it is, but if there are other things that can be done to speed it up, that'd be great to hear.
I'm hardly an expert, just an interested observer, but:
- Reducing the size of the codepath between main() and entering the main loop is important. Static linking GTKmm doesn't help here but as few apps use it the difference on most systems will be negligable (even an improvement as you optimize out the linker overhead). Lots of template usage can make code bigger too but there's not much we can do about that
- Putting anything that can be put off until the main loop goes idle for the first time is usually good
- Compiling for size not speed in some areas of the code may be useful (nail that all-important disk io!)
- Working set optimization is used *very* effectively at Microsoft, unfortunately we don't really have any good equivalent: Nats grope is probably the closest but it was designed to be a user tool. We need tools that let you profile and optimize the working set at compile time
- Constructing GUI can take a while, so it's best to delay loading/initialization of dialogs and palletes until they are needed
- Right now Inkscape and Inkview are *both* 7mb when I statically link GTKmm. Perhaps libinkscape should be turned into a dynamic library?
- Rearranging code in the source files can make a difference: strange but true. ld (I think) normally just concatenates the object files together. So by putting functions that are called together physically close in the source code, they're more likely to be in the same page on disk, reducing the number of page faults therefore reducing disk io
In case it's not obvious disk IO is *the* number one cause of startup time problems. Looking at the Inkscape startup code it's quite large, but then it's doing quite a lot of stuff (argument parsing, etc). I wonder if extensions could be loaded after the rest of the program?
I don't really see any obvious stuff though that could be removed from the startup path (which would make a difference).
thanks -mike
participants (5)
-
Alan Horkan -
Bryce Harrington -
bulia byak -
Helge Hielscher -
Mike Hearn