There'd been some comments about the quality of the Inkscape drawing tool compared with Sodipodi. I experimented around a bit with both. I see what they mean, but it's difficult to quantify the issue. Inkscape's drawing tool "feels" snappier, it doesn't lag like Sodipodi, and it produces lines smoothly, but it just doesn't "feel" right.
I can't draw worth beansy, but I could see the difference when I tried writing my name:
http://bryceharrington.com/freehand_drawing.png
Try signing your name with the two apps and see if you notice a difference.
Bryce
I can't draw worth beansy, but I could see the difference when I tried writing my name:
http://bryceharrington.com/freehand_drawing.png
Try signing your name with the two apps and see if you notice a difference.
Oh yes. Of course I notice a lot of difference. It's only that the difference is entirely the opposite :)
http://inkscape.org/cgi-bin/wiki.pl?SandBox2
I really cannot understand how you got the results you got, other than by drawing very small and very slow (and I still cannot quite reproduce this no matter how I try). When I draw, using a tablet pen, with my normal speed and normal range (the same as on paper), I get the results shown above. Inkscape reproduces my hand correctly enough, and it's readable. I can also make very smooth curves, as the spiral shows. Sodipodi awfully lags behind, making writing totally unrecognizable, and while it also produces smooth spiral, this spiral is in fact useless because due to the lag, it ended up about twice smaller than the shape I really drew with my pen.
So, to me the comparison is clear. Inkscape's tool is not ideal but is usable, while Sodipodi is a joke (it might be worth considering if there was a user setting to reduce the lag, but there is none). Just use a pen and don't try to cram a complex curve into 50x50 pixels. It's not supposed to be used that way.
By the way, judging by the layer selector widget in your screenshot, you have a very old Inkscape. So it may be that you don't have Peter's relatively recent (about 3 weeks ago) changes to the pencil tool.
On Wed, 10 Nov 2004, bulia byak wrote:
By the way, judging by the layer selector widget in your screenshot, you have a very old Inkscape. So it may be that you don't have Peter's relatively recent (about 3 weeks ago) changes to the pencil tool.
No, it's only about 12 days old. I'd try it against CVS but I'm still working on the code.
I found that if I set the pencil tolerance to about 2.75, it works a bit better, although I still obtain better results from Sodipodi.
Bryce
How much different is that code...aka, copy and paste the old and update and see how much different.
But, is it really that much different, or mainly preferences...
Jon
Bryce Harrington wrote:
On Wed, 10 Nov 2004, bulia byak wrote:
By the way, judging by the layer selector widget in your screenshot, you have a very old Inkscape. So it may be that you don't have Peter's relatively recent (about 3 weeks ago) changes to the pencil tool.
No, it's only about 12 days old. I'd try it against CVS but I'm still working on the code.
I found that if I set the pencil tolerance to about 2.75, it works a bit better, although I still obtain better results from Sodipodi.
Bryce
This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I found that if I set the pencil tolerance to about 2.75, it works a bit better, although I still obtain better results from Sodipodi.
Yes, I noticed today that decreasing tolerance makes it behave better for small curves. I will decrease the default though I haven't yet decided by how much.
As I understand, the underlying code for this has changed considerably.
Btw, I tried it against code from 3 days ago, and still get better results from Sodipodi. I'm using a mouse btw, not a tablet.
With the 2.75 setting, the results are closer to being correct but the issue is that now the benefit of smoothing isn't there so the results look jagged and sloppy in comparison to Sodipodi.
I've tried this both with Inkscape and Sodipodi at their default initialized window size, as well as maximizing and drawing as large as I can, but it doesn't really make a difference.
Also, I notice that when drawing with Inkscape, occasionally there are these flashes as though a line is projecting across the screen to the border.
Bryce
On Wed, 10 Nov 2004, Jon Phillips wrote:
How much different is that code...aka, copy and paste the old and update and see how much different.
But, is it really that much different, or mainly preferences...
Jon
Bryce Harrington wrote:
On Wed, 10 Nov 2004, bulia byak wrote:
By the way, judging by the layer selector widget in your screenshot, you have a very old Inkscape. So it may be that you don't have Peter's relatively recent (about 3 weeks ago) changes to the pencil tool.
No, it's only about 12 days old. I'd try it against CVS but I'm still working on the code.
I found that if I set the pencil tolerance to about 2.75, it works a bit better, although I still obtain better results from Sodipodi.
Bryce
This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
With the 2.75 setting, the results are closer to being correct but the issue is that now the benefit of smoothing isn't there so the results look jagged and sloppy in comparison to Sodipodi.
It does not make that much difference to me at all. I draw smooth curve and I get smooth curve, with just a barely noticeable increase in bumpiness at 2 than at 10.
OK, I guess this is really a useless argument because the results depend too much on your manner of drawing and the tool (mouse/pen) you use. For you, Inkscape is unnatural; for me, Sodi is absolutely unusable. Personally, I do not feel any pressing need for improving the Inkscape freehand tool now, except for lowering the default tolerance and fixing the ghost spikes, and I would certainly not welcome changing it towards Sodi's lagginess and oversmoothness. So if you make any changes to this code, I want to ask you to leave the current Inkscape behavior available because that is what I prefer.
On Wed, 10 Nov 2004, bulia byak wrote:
With the 2.75 setting, the results are closer to being correct but the issue is that now the benefit of smoothing isn't there so the results look jagged and sloppy in comparison to Sodipodi.
It does not make that much difference to me at all. I draw smooth curve and I get smooth curve, with just a barely noticeable increase in bumpiness at 2 than at 10.
OK, I guess this is really a useless argument because the results depend too much on your manner of drawing and the tool (mouse/pen) you use. I would certainly not welcome changing it towards Sodi's lagginess and oversmoothness. So if you make any changes to this code, I want to ask you to leave the current Inkscape behavior available because that is what I prefer.
I have no intent to do any changes to this piece code. I don't ever use the freehand drawing tool; my goal was simply to understand the complaints that people voiced, and provide some feedback. I'm sorry to see the feedback being dismissed as useless. Perhaps the changes in 0.40 and the default setting will be sufficient to settle the complaints.
Bryce
On Tue, Nov 09, 2004 at 10:19:01PM -0800, Bryce Harrington wrote:
I'm sorry to see the feedback being dismissed as useless.
Not at all, I'm glad you posted, and I think Bulia was just saying that it isn't useful to further pursue the discussion as to which is better, rather than to say that the discussion to date was entirely useless.
pjrm.
My first inkscape task after Friday:
If a "ghost spike" is detected (i.e. if the curve goes too far from the data points) then use a sharp corner instead of a smooth node.
I wouldn't expect this to have much effect on the cases being discussed here.
After that, there are a couple of possible freehand changes, and also three non-freehand patches, which I'll discuss first because they're more ready, and in the hope of comments as to what stuff's worth doing when.
- A simple patch adding a g_return_val_if_fail to something in sp-object.cpp. There are two possible conditions: one equivalent to what would cause a crash now anyway, or a tighter but simpler (and less random-looking) test. I'd like to check callers to see whether I can use the simpler tighter test. And get mental's opinion too.
- A patch whose correctness one can be fairly confident of but whose benefits are relatively minor:
- Rejecting some strings that have a valid value as a prefix, e.g. rejecting foo=nonebglx rather than treating it as foo=none.
- Minor efficiency gain through using memcmp instead of strcmp (though a reviewer may prefer to keep strcmp for simpler-looking code).
- A patch that makes our style string parsing more conformant, both in what we accept and what we reject. The patch more or less rewrites sp_style_merge_from_style_string, so is harder to verify correctness. We could just fix where we currently reject style strings that have lots of whitespace (caused by confusion as to whether trim_space sets *right to a length or final index) and delay applying the rewrite until after 0.40, so that it gets more testing.
Back to freehand:
- I have a fairly short patch that affects only the first segment of the curve (so it's helpful for short / smooth curves but no significant effect for the signature example). Its effect will improve fairly straight lines, but worsen curves that start with a sharp bend: more specifically, curves whose initial radius of curvature is comparable to or smaller than the tolerance.
Actually, you can tell what its effect will be by looking at the current CVS version of inkscape and comparing the start of the curve with the end of the curve (which already has this modification).
See below for comments on tolerance setting.
- I have a larger, unfinished, patch that delays committing a curve until we have two (or more) curves' worth of data points. This patch would approximately triple the CPU cost of freehand drawing, in exchange for a small improvement in curve fidelity.
That improvement can be built on if we use more sophisticated maths for curve estimation (for yet more CPU cost, as well as of course development effort).
On the subject of the default tolerance setting:
I really think the ideal tolerance would be a function of pointer speed. (I'm not commenting on how worthwhile it would be to implement this.) The thinking is that if one is moving fast then clearly[*1] one is not paying much attention to the exact position of the pointer, so we can use a larger tolerance and get smooth curves (assuming smoothness is considered good). If moving slowly, then it may be that one cares about the position, or maybe the user's just resting the pointing device, so we shouldn't make the tolerance too small, but at least it needn't make allowance for the broad-strokes case.
[*1]: Exception: if using a tablet and tracing around a physical object (e.g. the templates used by architects when using pencil on paper, or tracing something with a distinctive shape, for use as line art).
Some experimentation would be needed as to the right function, and we'd want, say, two parameters instead of the current one. That should be enough to adjust for different people's thinking speed (which may differ markedly if on medication, and I'd guess in other cases too, though I wouldn't know).
pjrm.
I also do not notice much difference between 2.75 and 10 with Inkscape but I do notice a difference with SodiPodi. SP is smoother but not particularly slow -I am using a mouse, Win2k, and a 933 PC. However, I am not really interested in SP.
Of more interest to me is that with Inkscape I do notice a great difference between Freehand at 2.75 or 10 and the Calligraphic tool. I find that the calligraphic tool with Width 0.01, Thinning 0.00, and Fixation at 0.00 is a very smooth drawing tool. I realise that it is laying down double nodes but the look and feel is much smoother to me. Any comments on this from others?
Can the code for the calligraphic tool be adapted for the freehand tool or am I the only person imagining the difference between the two tools?
On a related topic, Bulia, you were looking at smoothing via laying down smooth or symmetric nodes rather than the present corner nodes. What are your thoughts on this one now? In my own work I find that corner nodes are the exception in a "smooth" drawing, and I end up doing a Ctrl A and making them all symmetric. What do most other users feel on this one?
vellum
On Wed, Nov 10, 2004 at 11:08:00PM +1100, vellum wrote:
am I [merely] imagining the difference between [freehand tool, and the calligraphic tool with Width 0.01, Thinning 0.00, and Fixation at 0.00] ?
They do use different code in some respects.
On a related topic, Bulia, you were looking at smoothing via laying down smooth or symmetric nodes rather than the present corner nodes.
Is that for calligraphic tool or for pencil tool? The pencil tool in current CVS should be producing smooth nodes; indeed at present it never produces corner nodes, though we intend to change that before 0.40, so that it does use corner nodes if a smooth curve doesn't fit closely enough.
Can you confirm that you're using current CVS? Perhaps wait for a week before replying, in the hope that I commit one or two things (see another of my posts in this thread).
pjrm.
Peter, Yes. I'm using a current (build 041109) version.
Using the pencil tool. I'm sorry, I'm not being clear. The nodes look smooth when they are laid down, and on the canvas they look smooth but when you examine them individually they behave as corner nodes. Ctrl A and making them all symmetric has a marked smoothing effect on the drawn curve. Have you looked at laying down the curve with symmetric nodes?
Using the calligraphic tool. These nodes are more obviously corner when you examine them individually. Ctrl A and making them all symmetric has a marked smoothing effect on the curve.
Do you agree that the calligraphic tool has a much less "jerky" drawing action than the pencil tool?
I'm happy to wait. :-)
vellum
----- Original Message ----- From: "Peter Moulder" <Peter.Moulder@...38...> To: inkscape-devel@lists.sourceforge.net Sent: Wednesday, November 10, 2004 11:25 PM Subject: Re: [Inkscape-devel] Freehand drawing tool
On Wed, Nov 10, 2004 at 11:08:00PM +1100, vellum wrote:
am I [merely] imagining the difference between [freehand tool, and the calligraphic tool with Width 0.01, Thinning 0.00, and Fixation
at 0.00] ?
They do use different code in some respects.
On a related topic, Bulia, you were looking at smoothing via laying down smooth or symmetric nodes rather than the present corner nodes.
Is that for calligraphic tool or for pencil tool? The pencil tool in current CVS should be producing smooth nodes; indeed at present it never produces corner nodes, though we intend to change that before 0.40, so that it does use corner nodes if a smooth curve doesn't fit closely enough.
Can you confirm that you're using current CVS? Perhaps wait for a week before replying, in the hope that I commit one or two things (see another of my posts in this thread).
pjrm.
Not at all, I'm glad you posted, and I think Bulia was just saying that it isn't useful to further pursue the discussion as to which is better, rather than to say that the discussion to date was entirely useless.
Exactly. It was useful to demonstrate that the needs of people may be very different, but it's likely to not be useful to try to persuade each other that one particular set of requirements is more important than the other :)
On a related topic, Bulia, you were looking at smoothing via laying down smooth or symmetric nodes rather than the present corner nodes. What are your thoughts on this one now? In my own work I find that corner nodes are the exception in a "smooth" drawing, and I end up doing a Ctrl A and making them all symmetric. What do most other users feel on this one?
Doing all nodes smooth was exactly the change Peter made about 3 weeks ago. Before that, most if not all nodes were sharp, now they are all smooth. However, making them all symmetric as well as smooth would be an overkill I think. A symmetric node implies that the curvature before and after the point is constant, which is rearely the case.
Using the pencil tool. I'm sorry, I'm not being clear. The nodes look smooth when they are laid down, and on the canvas they look smooth but when you examine them individually they behave as corner nodes.
The handles of the node are collinear, that's what makes the node smooth. If the handles do not rotate together in the node editor, that's a problem with the node editor which we must fix.
Ctrl A and making them all symmetric has a marked smoothing effect on the drawn curve. Have you looked at laying down the curve with symmetric nodes?
Surely making them symmetric adds smoothness. But I'm afraid that making them symmetric while drawing would make the line too distorted (i.e. too far from the line you drew) and "jerky" as you describe below. We might try, however.
Do you agree that the calligraphic tool has a much less "jerky" drawing action than the pencil tool?
If by "jerky" you mean that calligraphic is closer to the actual line you drew, then yes. But I think the purposes of the two tools are different. For calligraphic, I need exact reproduction of my movements, with all trembles and wiggles, because that makes calligraphy look natural. With freehand, I usually need to draw some abstract geometric shape, and here I need it to generalize and smooth my drawing, much as it does now. The problem seems to be that when people draw on too small a scale (like Bryce did) it generalizes out the essential elements of the line rather than the artifacts, and that gives the impression of jerkiness. I draw on a larger scale and faster, so for me this generalization works very well.
--- Peter Moulder <Peter.Moulder@...38...> wrote:
Is that for calligraphic tool or for pencil tool? The pencil tool in current CVS should be producing smooth nodes; indeed at present it never produces corner nodes, though we intend to change that before 0.40, so that it does use corner nodes if a smooth curve doesn't fit closely enough.
Actually CVS never uses smooth nodes as far as i can tell, its always corner nodes. (it always uses curves instead of lines, but thats a different distinction.)
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
--- bulia byak <buliabyak@...400...> wrote:
Actually CVS never uses smooth nodes as far as i can tell, its
always
corner nodes. (it always uses curves instead of lines, but thats a different distinction.)
Can you show a sample of corner nodes produced by CVS freehand tool?
http://inkscape.org/cgi-bin/wiki.pl?SandBox2
they might have the handles lined up, but that doenst make them smooth nodes, if you move one handle, the other doesnt move too. smooth nodes would be squares instead of diamonds (different again from symmetric)
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
they might have the handles lined up, but that doenst make them smooth nodes, if you move one handle, the other doesnt move too. smooth nodes would be squares instead of diamonds (different again from symmetric)
As I explained in this thread, this is a problem with the node editor, not with freehand tool. You might want to file a bug for it, or try to fix it yourself (it's simple; when loading the path into SPNodepath, just consider the node smooth if its handles are collinear and there is no sodipodi:nodetypes).
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <vellum@...68...> Cc: inkscape-devel@lists.sourceforge.net Sent: Thursday, November 11, 2004 1:44 AM Subject: Re: [Inkscape-devel] Freehand drawing tool
On a related topic, Bulia, you were looking at smoothing via laying down smooth or symmetric nodes rather than the present corner nodes. What are your thoughts on this one now? In my own work I find that corner nodes
are
the exception in a "smooth" drawing, and I end up doing a Ctrl A and
making
them all symmetric. What do most other users feel on this one?
Doing all nodes smooth was exactly the change Peter made about 3 weeks ago. Before that, most if not all nodes were sharp, now they are all smooth. However, making them all symmetric as well as smooth would be an overkill I think. A symmetric node implies that the curvature before and after the point is constant, which is rearely the case.
Bulia, have you or Peter tried making them them all symmetric? It may not be 'overkill' since although 'the curvature before and after the point (node) is constant', the final drawn curve that actually runs through the node is not a mirror image because the curve is also affected by the nodes on the opposite end of each adjacent curve segment.
It may make little difference, but I'd like to see the overkill statement made on experiment rather than thinking. :-)
vellum
There is another small problem with symmetric nodes. When I change a node from corner or smooth to symmetric, the node does change. However its symbol does not. It goes to a square rather than a small rectangle. Is this also a node editor bug?
The same thing happens with the nodes in calligraphic tool.
vellum.
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "John Cliff" <simarilius@...36...> Cc: "inkscape" inkscape-devel@lists.sourceforge.net Sent: Thursday, November 11, 2004 6:36 AM Subject: Re: [Inkscape-devel] Freehand drawing tool
they might have the handles lined up, but that doenst make them smooth nodes, if you move one handle, the other doesnt move too. smooth nodes would be squares instead of diamonds (different again from symmetric)
As I explained in this thread, this is a problem with the node editor, not with freehand tool. You might want to file a bug for it, or try to fix it yourself (it's simple; when loading the path into SPNodepath, just consider the node smooth if its handles are collinear and there is no sodipodi:nodetypes).
On Thu, 11 Nov 2004 08:58:06 +1100, vellum <vellum@...68...> wrote:
There is another small problem with symmetric nodes. When I change a node from corner or smooth to symmetric, the node does change. However its symbol does not. It goes to a square rather than a small rectangle.
i.e. from diamond to square
Is this also a node editor bug?
not really a bug, just that we don't have a visual indication for symmetric nodes. You can file a RFE.
The same thing happens with the nodes in calligraphic tool.
Calligraphic tool has no nodes. Node tool works with any paths as paths, no matter how they were created.
Doing all nodes smooth was exactly the change Peter made about 3 weeks ago. Before that, most if not all nodes were sharp, now they are all smooth. However, making them all symmetric as well as smooth would be an overkill I think. A symmetric node implies that the curvature before and after the point is constant, which is rearely the case.
Bulia, have you or Peter tried making them them all symmetric? It may not be 'overkill' since although 'the curvature before and after the point (node) is constant', the final drawn curve that actually runs through the node is not a mirror image because the curve is also affected by the nodes on the opposite end of each adjacent curve segment.
Admittedly we haven't tried symmetric nodes yet. If Peter can code this I would be interested to compare.
On Mi, 2004-11-10 at 15:36 -0400, bulia byak wrote:
they might have the handles lined up, but that doenst make them smooth nodes, if you move one handle, the other doesnt move too. smooth nodes would be squares instead of diamonds (different again from symmetric)
As I explained in this thread, this is a problem with the node editor, not with freehand tool. You might want to file a bug for it, or try to fix it yourself (it's simple; when loading the path into SPNodepath, just consider the node smooth if its handles are collinear and there is no sodipodi:nodetypes).
hmm, but shouldn't there just be a nodetypes for a newly drawn path? Where is the sense in creating a new path withouth them?
David
hmm, but shouldn't there just be a nodetypes for a newly drawn path? Where is the sense in creating a new path withouth them?
That's a possible approach, but it's not elegant, because sodipodi:nodetypes would not contain any information which would not already be present in the path itself, in implicit form. So it's much better to teach the node editor to recognize node types on its own - this way it will work better with any paths, not only Inkscape-generated ones.
On Wed, 10 Nov 2004 17:41:47 +1100, Peter Moulder <peter.moulder@...38...> wrote:
My first inkscape task after Friday:
If a "ghost spike" is detected (i.e. if the curve goes too far from the data points) then use a sharp corner instead of a smooth node.
Good, that's what is needed.
I wouldn't expect this to have much effect on the cases being discussed here.
Yes, but otherwise it's important.
After that, there are a couple of possible freehand changes, and also three non-freehand patches, which I'll discuss first because they're more ready, and in the hope of comments as to what stuff's worth doing when.
A simple patch adding a g_return_val_if_fail to something in sp-object.cpp. There are two possible conditions: one equivalent to what would cause a crash now anyway, or a tighter but simpler (and less random-looking) test. I'd like to check callers to see whether I can use the simpler tighter test. And get mental's opinion too.
A patch whose correctness one can be fairly confident of but whose benefits are relatively minor:
Rejecting some strings that have a valid value as a prefix, e.g. rejecting foo=nonebglx rather than treating it as foo=none.
Minor efficiency gain through using memcmp instead of strcmp (though a reviewer may prefer to keep strcmp for simpler-looking code).
sounds OK to me, but perhaps still worth delaying until after 0.40
- A patch that makes our style string parsing more conformant, both in what we accept and what we reject. The patch more or less rewrites sp_style_merge_from_style_string, so is harder to verify correctness. We could just fix where we currently reject style strings that have lots of whitespace (caused by confusion as to whether trim_space sets *right to a length or final index) and delay applying the rewrite until after 0.40, so that it gets more testing.
Good, certainly after 0.40
Back to freehand:
- I have a fairly short patch that affects only the first segment of the curve (so it's helpful for short / smooth curves but no significant effect for the signature example). Its effect will improve fairly straight lines, but worsen curves that start with a sharp bend: more specifically, curves whose initial radius of curvature is comparable to or smaller than the tolerance.
Hmm, I'm afraid that initial small curves were part of the problem Bryce experienced. This needs to be tested.
I have a larger, unfinished, patch that delays committing a curve until we have two (or more) curves' worth of data points. This patch would approximately triple the CPU cost of freehand drawing, in exchange for a small improvement in curve fidelity.
That improvement can be built on if we use more sophisticated maths for curve estimation (for yet more CPU cost, as well as of course development effort).
Hard to say, needs testing, after 0.40 I think
I really think the ideal tolerance would be a function of pointer speed. (I'm not commenting on how worthwhile it would be to implement this.) The thinking is that if one is moving fast then clearly[*1] one is not paying much attention to the exact position of the pointer, so we can use a larger tolerance and get smooth curves (assuming smoothness is considered good). If moving slowly, then it may be that one cares about the position, or maybe the user's just resting the pointing device, so we shouldn't make the tolerance too small, but at least it needn't make allowance for the broad-strokes case.
That's a good idea. Actually it must depend on the intended radius of curvature that the user has in mind, but since this is hard to estimate, the speed seems to be a good approximation. Though it's not ideal; for example when I'm trying to draw a good straight line I may move it slower than when I'm trying to do a smooth sweeping curve. So if you can implement this one I'd certainly want to test it out.
On Wed, 2004-11-10 at 01:41, Peter Moulder wrote:
- Minor efficiency gain through using memcmp instead of strcmp(though a reviewer may prefer to keep strcmp for simpler-looking code).
Yes. Unless you have a compelling reason (i.e. order-of-magnitude performance improvements as demonstrated by profiling), please don't.
n.b. I'm also decidedly uncomfortable with macros, especially those that reference local variables. Makes later refactoring painful.
-mental
So after watching all of the conversation on this topic, today I decided to bust open Illustrator (v. 10) to see how it handled the freehand tools (pencil & brush, the equivalent of our freehand & calligraphy tools)... it's pretty interesting and of course extremely accurate. I know in this conversation was comparing Sodi & Inkscape initially, but I figured we should also compare to how the "big guy" does it too (even though there's no access to source code to find out how they _really_ do it).
For the pencil it lays down a dotted line as a placeholder and the brush lays down a crude raster line as a placeholder (reflecting brush size, etc), and both then replace that placeholder with the real vector line when you are done drawing (on mouse button release).
I have to say it appears that there are two (perceived) benefits for handling drawing like that:
1) Illustrator remains responsive regardless of length of line or speed of stroke, whereas with Inkscape the longer the line gets (or if you go turbo speed), the less responsive the app/tool is. I love the Calligraphy tool, but it gets painful to work with if you try to write fast or for long.
2) It gives the program additional time to calculate results that are more accurate (since it's not quite working in "real-time" w/ actual vectors).
As I said, those are perceived benefits and may not necessarily be accurate as to how those tools in Illustrator really function (specifically relating to perceived benefit #2). Either way, my guess is that Adobe does it for a good reason.
I just figured that it might be good to see how the closed source apps do it to figure out what else may be done to improve our tools. So maybe a placeholder of sorts, so that there is additional time to more accurately lay down a vector as well as keep inkscape responsive?
Just my .02 (since I don't _really_ know much about this, those are pesos)
Oh and as for the comparison of Inkscape vs Sodi with a signature, prior to changes made yesterday to the freehand tool I have to say that Inkscape had better results for me.
-Josh
-----Original Message----- From: inkscape-devel-admin@lists.sourceforge.net
[mailto:inkscape-devel-
admin@lists.sourceforge.net] On Behalf Of Bryce Harrington Sent: Tuesday, November 09, 2004 9:14 PM To: inkscape-devel@...6... Subject: [Inkscape-devel] Freehand drawing tool
There'd been some comments about the quality of the Inkscape drawing tool compared with Sodipodi. I experimented around a bit with both.
I
see what they mean, but it's difficult to quantify the issue. Inkscape's drawing tool "feels" snappier, it doesn't lag like
Sodipodi,
and it produces lines smoothly, but it just doesn't "feel" right.
I can't draw worth beansy, but I could see the difference when I tried writing my name:
http://bryceharrington.com/freehand_drawing.png
Try signing your name with the two apps and see if you notice a difference.
Bryce
This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I've made some changes to the freehand code. We now do better estimation of initial & final tangent. I've also got rid of the ghost spike problem.
You may wish to experiment with the pencil tolerance setting (double-click on the pencil tool) and/or the array size in src/pencil-context.h.
I was going to increase the array size from 16 to 256:
* src/pencil-context.h: Increase maximum number of data points per bezier from 16 to 256. This results in longer curve segments, and more CPU time, and greater importance of having a small tolerance value in the pencil settings (say 2.5 or 3).
but am inclined to prefer the existing size of 16, despite the theoretical advantages of the larger buffer. I think this reflects either that we need to be smarter about the tolerance value (perhaps using the speed idea mentioned elsewhere in this thread) and/or "guess what radius of curvature the user intends" as Bulia suggested in reply. At first that sounds as if it requires telepathic I/O, but we could get results by being more explicit about what curves are more likely than others.
A change that would improve things for fairly straight curves (fairly large radius of curvature) is the pending patch that allows more than one uncommitted (red) bezier segment, rather the existing code where the tangent at nodes is chosen solely from the data points that come before the node.
An extreme version of that is suggested by Joshua / Illustrator, where we don't commit any of the curve until mouseup.
Maybe the array size can be increased to such a large value once one of those changes has gone in. For the moment, try playing around with values near the existing 16.
pjrm.
I've now had a look at sodipodi's freehand tool, e.g. looking at diffs between sodipodi 0.29 (roughly what we inherited in Inkscape) and 0.34.
Between those two versions, sodipodi has rewritten the curve stuff, e.g. changing the behaviour according to how long has elapsed since the last movement event. Thankfully, Inkscape's & sodipodi's changes are complementary: we can incorporate sodipodi's additions while still benefitting from Inkscape's improvements, and similarly I can notify sodipodi list of changes in Inkscape that they may consider incorporating into sodipodi.
I suggest that we're too late into 0.40 to add a bunch of new code, so this will have to wait for 0.41.
pjrm.
Yes, top-posting is the devil... sorry.
First off, I'm resurrecting this thread as I have updated information/observations from trying most of the big commercial apps to compare various functions, here's what I noticed with freehand drawing.
In all of the commercial apps, they lay down placeholders of the lines you draw with freehand tools while you are drawing them. In CorelDRAW & Freehand it is just a raster line it plots and then replaces it with the vector line on mouseup. Illustrator does that for one type of drawing tool, the other uses a dotted line (like a vector line with stroke set to a decently spaced dotted pattern). And in Xara it appears that it lays down a vector line that is not antialiased, as well as it is a bit more rugged than the finished line (you see more straight segments while plotting, but they smooth out when it commits the line).
What I'm getting at is that we should probably look at doing something similar with our freehand drawing & calligraphy tools to keep them more responsive while drawing. The pencil tool in Inkscape is significantly less responsive than our commercial counterparts (especially if you try long strokes... the longer the line, the less responsive we are). In fact, the commercial apps all stay just as responsive from start to finish regardless of line length, so that's definitely a reason to look into it. I think it mainly has to do with us trying to lay down the end result while it's being drawn. Is there any way we can achieve the rough/low quality placeholder lines just while drawing to keep those tools responsive?
In my testing, the commercial apps are all a lot more accurate than we are (we don't compare too well at this point), with Illustrator being the most accurate by quite a bit. So, even if you say that people should just draw shorter lines to keep it responsive... it also seems like we could theoretically improve accuracy as well, as it would help give us extra time to calculate the appropriate type and location of nodes as well as more accurate curves.
These were just my thoughts/observations on the subject since I'm doing comparisons of various features of the big apps with ours.
I'm not thinking that any work would be done on this for a while, but I just wanted to see what others think.
-Josh
So after watching all of the conversation on this topic, today I
decided
to bust open Illustrator (v. 10) to see how it handled the freehand tools (pencil & brush, the equivalent of our freehand & calligraphy tools)... it's pretty interesting and of course extremely accurate. I know in this conversation was comparing Sodi & Inkscape initially, but
I
figured we should also compare to how the "big guy" does it too (even though there's no access to source code to find out how they _really_
do
it).
For the pencil it lays down a dotted line as a placeholder and the
brush
lays down a crude raster line as a placeholder (reflecting brush size, etc), and both then replace that placeholder with the real vector line when you are done drawing (on mouse button release).
I have to say it appears that there are two (perceived) benefits for handling drawing like that:
- Illustrator remains responsive regardless of length of line or
speed
of stroke, whereas with Inkscape the longer the line gets (or if you
go
turbo speed), the less responsive the app/tool is. I love the Calligraphy tool, but it gets painful to work with if you try to write fast or for long.
- It gives the program additional time to calculate results that are
more accurate (since it's not quite working in "real-time" w/ actual vectors).
As I said, those are perceived benefits and may not necessarily be accurate as to how those tools in Illustrator really function (specifically relating to perceived benefit #2). Either way, my guess
is
that Adobe does it for a good reason.
I just figured that it might be good to see how the closed source apps do it to figure out what else may be done to improve our tools. So
maybe
a placeholder of sorts, so that there is additional time to more accurately lay down a vector as well as keep inkscape responsive?
participants (9)
-
Bryce Harrington -
bulia byak -
David Christian Berg -
John Cliff -
Jon Phillips -
Joshua A. Andler -
MenTaLguY -
Peter Moulder -
vellum