4 ms·

I ran into this problem in my app and found that rotating around the center of the bounding circle instead of the bounding box was a suitable solution.

shahar2k 5y ago
as someone who works with vector drawings often I would say that's unintuitive simply because the selection highlights are usually rectangular... there are many cases (lets say 3 objects in a triangle) where if you show a rectangular selection the rotation "center" will then be quite off the intuitive center
mkl 5y ago
Good idea. It seems more expensive to compute, especially for curves and pen stroke elements. Did you have any problems along those lines?
- kingcharles 5y ago
  More expensive to compute? I guess technically, but I don't think you could ever measure or see the difference without running a debugger.
  - mkl 5y ago
    If you have a page full of writing, all sorts of things get slow. I do a lot of digital writing, and have encountered a number of strange slowdowns, even in apps designed for the purpose. In particular, selecting a large number of strokes can be quite a problem. There are minimum bounding circle algorithms that are O(n) where n is the number of points, but n can get big enough that you may not want to be doing that in an interactive program. You can put objects in a quadtree or similar to look them up quickly, and that may let you discard entire strokes in e.g. Welzl's bounding circle algorithm, but with stroke or curve data you'll still need to search along each one somehow for the extreme points by whatever measure you're using (and a Bezier curve has uncountably infinitely many points, so maybe you can only find an approximate bounding circle?).
spankalee 5y ago
How do you efficiently compute the bounding circle, especially in the presence of curves?
- iainmerrick 5y ago
  Curves aren’t important in this scenario because the circle isn’t visible, it’s purely there to provide a consistent center of rotation. It doesn’t matter if it hugs the curves or not. This is the kind of thing where there are plenty of well-established algorithms (although there might not be a good off-the-shelf implementation in your language of choice). I doubt efficiency is going to be a problem unless you have many thousands of points.
  - mkl 5y ago
    Good point, but the centre of the circle is the important thing, and that is visible if you want good UX. It does matter that it consistently leaves out the same part of sticking-out curves in different rotations. You could sample some number of points along each curve or something. Many thousands of points is exactly what you have in a page of handwriting. They're organised into strokes, which should help.
    - tonyarkles 5y ago
      Just spit-balling here, but it seems to me that you could probably get away with just using the endpoints and maybe the control points. There might be some odd cases where this falls apart, but in general I suspect it would work pretty well and in the edge cases it probably wouldn't be too confusing; you'd still get a point to rotate around in the vicinity of the curve at the centre of a line between the endpoints. If you included the control points, it would still end up roughly close to the centre of the visual curve.

shahar2k 5y ago

as someone who works with vector drawings often I would say that's unintuitive simply because the selection highlights are usually rectangular... there are many cases (lets say 3 objects in a triangle) where if you show a rectangular selection the rotation "center" will then be quite off the intuitive center

mkl 5y ago

Good idea. It seems more expensive to compute, especially for curves and pen stroke elements. Did you have any problems along those lines?

kingcharles 5y ago
More expensive to compute? I guess technically, but I don't think you could ever measure or see the difference without running a debugger.
- mkl 5y ago
  If you have a page full of writing, all sorts of things get slow. I do a lot of digital writing, and have encountered a number of strange slowdowns, even in apps designed for the purpose. In particular, selecting a large number of strokes can be quite a problem. There are minimum bounding circle algorithms that are O(n) where n is the number of points, but n can get big enough that you may not want to be doing that in an interactive program. You can put objects in a quadtree or similar to look them up quickly, and that may let you discard entire strokes in e.g. Welzl's bounding circle algorithm, but with stroke or curve data you'll still need to search along each one somehow for the extreme points by whatever measure you're using (and a Bezier curve has uncountably infinitely many points, so maybe you can only find an approximate bounding circle?).

spankalee 5y ago

How do you efficiently compute the bounding circle, especially in the presence of curves?

iainmerrick 5y ago
Curves aren’t important in this scenario because the circle isn’t visible, it’s purely there to provide a consistent center of rotation. It doesn’t matter if it hugs the curves or not. This is the kind of thing where there are plenty of well-established algorithms (although there might not be a good off-the-shelf implementation in your language of choice). I doubt efficiency is going to be a problem unless you have many thousands of points.
- mkl 5y ago
  Good point, but the centre of the circle is the important thing, and that is visible if you want good UX. It does matter that it consistently leaves out the same part of sticking-out curves in different rotations. You could sample some number of points along each curve or something. Many thousands of points is exactly what you have in a page of handwriting. They're organised into strokes, which should help.
  - tonyarkles 5y ago
    Just spit-balling here, but it seems to me that you could probably get away with just using the endpoints and maybe the control points. There might be some odd cases where this falls apart, but in general I suspect it would work pretty well and in the edge cases it probably wouldn't be too confusing; you'd still get a point to rotate around in the vicinity of the curve at the centre of a line between the endpoints. If you included the control points, it would still end up roughly close to the centre of the visual curve.