Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/excalidraw/excalidraw/d8mkv4xu6 |
|
Nice. If we end up using the same API as we do for lines, we really need to work on fixing the temporal consistency issues (#760), though it creates some psychedelic visuals:
We'll also want to investigate @pshihn's suggestion, because we want nice and smooth lines (and good perf/size):
And lastly --- current implem doesn't allow to paint in coordinates negative to initial x/y position:
|
|
@dwelle Thank you. I'm investigating the negative coords issue. Not sure what's causing it and I thought someone else could help. Once I have a good first UX implementation I will start looking at perf/visual issues. |
|
Yea. It might actually be a good idea to reuse the lines implem as you're doing, because we'll get shape-filling and hitbox testing for free. |
|
/cc @dai-shi do you see any obvious venue for fixing the bounding-box constraint on drawing to the negative? The implem diverged so much from the original one, that I'm not sure I'll be able to give much pointers here. |
|
We should probably have less points.. bigger threshold for adding a new point.. |
|
Works from the phone as well :) |
|
I can surely help, although it has nothing to do with resizing which I recently modified. There's even an issue with lines.
|
| this.setState({ | ||
| draggingElement: element, | ||
| editingElement: element, | ||
| multiElement: element, |
There was a problem hiding this comment.
This is probably causing the issue.
There was a problem hiding this comment.
Could you please explain a little bit what that property does? (At some point I was just copy pasting code from other places and I probably messed up somewhere :P )
There was a problem hiding this comment.
To be honest, I do not know. 😓 I just assumed this is only the place to cause such an issue. Probably, it's setting the multiElement even when it's only two or less elements. Could you try removing this line and see if the behavior changes? And maybe only add it when it's more than two points. Again, I'm just guessing.
There was a problem hiding this comment.
That's not it, although it was causing issues for arrow/line elements, and even some weird jumping for draw element -- so I removed it. Don't know what was the purpose of adding it, but if it's needed for draw elements, we'll need to adapt it since it's very much tied to arrow/line elements.
|
Pushed a fix for the bounding box/rendering issue. It was caused because you didn't include |
|
While the effect is something the daemons of the Warp would proud of, we need to get rid of it. @pshihn I noticed that only one of the lines is regenerating when drawing, so I tried setting
It looks like the (you may also notice some jumps, but those are almost certainly caused by excalidraw -- when I disabled rendering from element canvases, it went away, so I'll need to take a look at that). |
|
When drawing multiple point lines, are you setting a new seed for every line segment? (btw, i do like the single stroke for free drawing with an additional +0.5 strokewidth you did in the dashed case) |
Not that I'm aware of, but if we did, it would regenerate both lines, not just the secondary one (which I tested by not passing the seed at all).
For lines with many points very close together, yes, but when we implement the algo you proposed to reduce the amount of points, it might be preferable to keep the same render style (but I don't have a strong opinion right now -- would have to see afterwards).
But be it as it may, we still want to fix #760. |
|
There could be an issue in roughjs specific to the curve command which is used for multi point lines. Curves are approximated to a number of points. If the number of points changes, then it affects the randomization with a specified seed. Edit: Noticed you linked to #760 which was my question. Missed that . |
But that doesn't explain why it doesn't randomize the primary curve, if I understand you correctly. |
|
That said, #760 makes me a bit unsure it's rough's fault (as I checked your code and couldn't find anything -- though that doesn't mean much) since this regeneration occurs on commit-only 🤔. But we're definitely not regenerating EDIT: actually, rough is still not off the hook because the difference between moving an uncommitted point and committing it is that after commit there's N+1 points, which is probably significant. |
|
@kbariotis yes that issue is independent of simplification. @dwelle for #760 are you talking about the issue where addin |
|
@kbariotis EDIT: is this PR done? We should take a look at the curve simplification first. EDIT2: oh, forgot you've already done it 😅 EDIT3: that said, that simplification is too aggressive IMO. I'll take a look at it tomorrow if we can make it speed-adaptive. |
|
Some changes I'd do:
|
|
@pshihn looks great! |
|
awesome work @kbariotis. Waiting for this to go live :) |
|
While I'm not satisfied with the simplification algorithm, we can ship it as an alpha implementation and gather feedback while we try to figure out how to improve it. The
And decreasing it to
So there's not much to choose from right now. |
|
I did not notice the issue you described in 0.5 until I really tried. One way to address it - You can try buffering after some length - simplify until you reach a certain length or number of points, buffer them. As you keep drawing, only simplify the new points and add to the buffer. Keep adding to buffer as you keep drawing. (A distance of 1.0 might work great here as well) |
|
Mhm, I may have been inadvertently on a high zoom level. Trying again on 100%, the problem on the 1st GIF can't be easily reproduced. In fact, it now skews more towards the 2nd GIF. Anyway, we can ship this as is, and tinker with the algo as we go. Also, I didn't want to sound unappreciative or anything @pshihn. The work you're doing on rough is amazing! |
|
Sounds good. Have you tried with 1.0? Seems like we jumped from 2.0 to 0.5 |
|
I did -- it feels too rubbery or how to explain it. The lines get simplified in a manner that they often end up in position where you didn't draw them at all, especially when making turns:
And when you make 90° angles, it manifests that behavior from above:
The latter should be fixed when we implement the distance heuristic you proposed. |
|
ah makes sense. Since we are using the curve command to fit these points with roughness there will be artifacts. It still works pretty well with what we have right now. Like you said, can always improve. |
|
I increased to 0.7. I also fixed the following:
I didn't set |
7 participants
This replicates the line/arrow mode, but adds a point to the line on each mouse moving position.
For #25 and #1569