Smooth strokes

[Mag]

Hi all,

In a mobile project, I'm using mouseMove to let user draw on a canvas. The lines appear a bit 'edgy, do you have some advices to smooth strokes?

[[-hh]]

..........

[Mag]

Thank you so much Hermann!

Lot of things to learn, I hope they are not to much difficult!

[Mag]

The stacks and samples are great, they make me remind of when I used Adobe Illustrator.

I need something more practical (I know it will be almost impossible) and that is a way of round the lines created with the Freehand tool of LiveCode.

I know, not an easy task!

[Mag]

Maybe to make the line smoother I should find a way to add programmatically points in the graphic...

[bn]

Hi Mag,

Maybe to make the line smoother I should find a way to add programmatically points in the graphic...

The edgyness on mobile devides in my experience is due to the fact that "mouseMove" can not sample at a high enough rate. This is due to the time it takes LC on mobile to do the screen refresh. You can see the effect when the user draws fast, that is when edgyness appears.

A little can be gained if you collect say five points (vary this number) and then do a "set the points of graphic "xyz" to tMyCollectedPoints". You could do this with a sampling loop that you "send in time" and a counter that indicates the number of samples. Once the number of sampling cycles is reached you set the points and reset the counter.
The basic mechanism is in a stack that I posted to RevOnline a long time ago. It is here:

http://livecodeshare.runrev.com/stack/3 ... on-Graphic

That stack is a bit overloaded because I wanted to put a lot of bells and whistles into it. But the code I am talking about is the code of image "canvas". The image is only there to trigger the drawing of graphic objects. This is not bitmap painting.

I don't have the time to adapt the code right now and neither for the next few days. (holiday weekend for me). You would have to add the counter (a script local variable that is initialised on mouseDown and used to trigger "set the points of graphic" and strip down the code to your needs.
Maybe that gives you an idea. And it still might not give you the high temporal resolution you want. But it is worth a try.

Kind regards
Bernd

[Mag]

Hi Bernd, I find your stack plenty of interesting things and brilliant solutions. So you choose to use mouseDown instead of mouseMove. This choice is based on the fact that this way you have more control I guess, do you discover also other reasons?

I done some tests and changing the timing of the send command from 90 milliseconds to 4 gives the line almost the smooth I need, but this create a lot of points, I'm just trying to do a finger-drawing app, so don't need to edit/add points, but trying to know if the large number of points could create problems...

I continue to do experiments with your stack...

[[-hh]]

..........

[[-hh]]

..........

[Simon]

Hello Hermann, Bernd,
I haven't had a chance to test out the 2 stacks together but I think you have solved a very worrying question for me and I didn't want the thread to go cold before I had a chance to thank you.
Soon I have to build a mental heath (Alzheimer, Dementia) app of which part includes a drawing test, simple geometric shapes. Knowing how poorly apps even with touch screens respond to drawing I couldn't figure out how to convert what they meant to draw and what the result was. This I think you have solved.

Thanks Bunches,
Simon
PS if I've misunderstood this thread then just thank you for all your contributions.

[[-hh]]

..........

[Simon]

Hi Hermann,
This project is coming up so I haven't sat down to look at all the possibilities/ramifications, this test caught my attention because I wasn't sure where to start.
Using Mag's example at the top of this thread is actually, I think, a very good approximate of a circle when using a touch interface. But I'll have to compute how close to a circle it is (Mag you lose 15% for not closing the circle). The same will be done with squares,triangles etc.
At least with these 2 stacks I believe I and the user will have a fighting chance.

...let the user click/say before what he wants to have (straight lines or curves)

Great idea! I wonder how much I will be allowed to help them.
Yes, yes "adaptive thinking"

As the Mental Heath module gets closer I'll keep you informed.

Simon

[[-hh]]

..........

[Mag]

What I see here is an incredible source of ideas, projects and solutions.

I appreciate so much the work done by many and and the brilliant implementations posted.

Make a smooth line drawn by someone without upsetting his intentions is not an easy task. I think we need to consider a few essential points.

1. It is not possible to try to understand what an user wants to draw and change the path with this in mind. By doing so, the user will tend to lose its spontaneity, and in the end, he/she will behave in a different way from how he/she would like. We just have to correct unintentional errors introduced by tracing, like the flickering and unexpected peaks in a path.

2. The external dimension of the path (the rectangle), as far as possible, should not be changed. The points position in top, right, bottom, and left, should be preserved. For example if an user wants to draw some geometric figures proportionate between them, he/she does not expect that the dimensions are changed. Anyway if you need to make a choice between making larger or smaller the rectangle of a path, then you better make it bigger.

3. A clear corner of a path should not be transformed into a curve (for example, like the one in the letter V) . Especially if this angle is acute, it will definitely be intentional.

4. Often the user wants to draw a straight line (for example the bars of a T) does not want to draw a curve. Not everything in the path must be transformed into a curve.

5. The path created by the user, has to be changed little, almost imperceptibly. A little like it does the anti-aliasing for the fonts. Otherwise, the user will no longer recognize his handwriting and the things that he/she has drawn.

[[-hh]]

..........