spacedeck / spacedeck-open

Spacedeck, a web based, real time, collaborative whiteboard application with rich media support
GNU Affero General Public License v3.0
1.01k stars 243 forks source link

Scribble tool bugs #87

Open yrammos opened 4 years ago

yrammos commented 4 years ago

I am grouping two bugs under a single issue suspecting that they are closely linked. Both issues come most apparent with the board zoomed in (at or near 200%). In principle, they manifest at any zoom level.

  1. The hairline cursor of the scribble is misaligned with the curve. As the following video shows, the cursor center appears just above the curve. Not an issue with large freehand objects, but prohibitive when drawing letters, math, geometry exercises, and other fine objects.

  2. The curve is minutely displaced while the scribble tool is dragged along the board. This is also demonstrated in the video.

screenshot

I suspect an glitch in the spline routine in both cases. This is the kind of issue that could benefit from @MishkinBerteig's chops.

Thanks.

MishkinBerteig commented 4 years ago

I'll look into it! :-)

FWIW, I'm very new with Github and Git so I'm not yet comfortable starting coding a new task until the last PR is accepted. (Hint @mntmn .). And, I really really really want to get some automated testing in place.

yrammos commented 4 years ago

Thanks once again, @MishkinBerteig. I'm thinking that the first issue, at least, might be due to inherent limitations of vector drawing (I mentioned "spline" in my original post but in fact am not sure which algorithm is used). Specifically, a minimal displacement of the hairline might be necessary before ink is released in order to determine an initial tangent for the curve.

I'm jumping the gun here as I haven't looked at the algorithm. But if my assumption is correct, I'm thinking that it might be best to add a new "bitmap" drawing tool to Spacedeck as a complement to the existing vector-based scribble. Bitmap lines would likely raise new technical questions (particularly with respect to pixel resolutions and zooming in/out). But they would also be excellent for non-artistic drawing (teaching), also making possible the introduction of an eraser tool (which currently doesn't exist). Just a few thoughts thinking down the road. Happy to hear thoughts of any other folks. Thanks, MishkinBerteig.

mntmn commented 3 years ago
  1. I think it is just that the Y position is offset a few pixels, that's all. It should be relatively easy to fix by looking at the coordinates of the scribble tool.
  2. This is a result of the simplification/smoothing code. It can be adjusted to add more points if necessary.
  3. I'm not planning to add a bitmap drawing tool at this point.
tekhnee commented 3 years ago

@mntmn, I beg to differ — unless my understanding of the code is flawed, which is likely.

I think it is just that the Y position is offset a few pixels, that's all. It should be relatively easy to fix by looking at the coordinates of the scribble tool.

Not so simple, perhaps, because this offset depends on the zoom level (and is especially acute ca. 200%). I played around with the padding parameter in render_vector_drawing(), to no avail.

This is a result of the simplification/smoothing code. It can be adjusted to add more points if necessary.

Are you referring to simplify_scribble_points? Again, I tried bypassing it—expecting the curve to be rendered with all its control points—but no success.

I'm not planning to add a bitmap drawing tool at this point.

Fair enough, in fact this request would be obviated if the two aforementioned issues were addressed.

Thanks!

rds13 commented 3 years ago

I've done a little digging around this problem. All the coordinate calculation seems good. What I've found is the svg placement is dependent of it's height in the spaceboard. So two shapes starting at the same point won't be rendered by the browser at the same position if for example the height of the second shape is smaller. As you start drawing this is exactly what is happening. The problem to my understanding is that it's the bottom of the svg component that is fixed and the not the top. If you edit a svg artifact in the html and change its height you will see the component moving down.