Implement Software Cursors

interface
Tags: #<Tag:0x00007f0a4867d1e0>

#1

I’ve noticed some brushes will stop resizing if you make the brush too big, Is there a way to make the cursor track the brush size no matter how big it gets? It’s hard to tell how big my strokes are until I place them.


Wrong brush preview size
#2

You’re seeing a hard limit there: our existing “hardware” cursors can only get so big, and we use those because they’re the fastest kind. These are the cursors used almost everywhere else, and they’re faster because they’re stored as a little texture in the GPU, no need to redraw as you move.

It may be time for a change to more flexible “software” cursors, though they’ll be laggy compared to the real deal. Perhaps a hybrid approach, with hardware small-circles . o O but a combination hardware mini-crosshair and software big-circle ( + ) would work OK?


#3

I dunno, I’m not too knowledgeable to the technical stuff, I just know that the other programs I’ve used in the past did with little issue and they didn’t lag for me, but the cursor problem is pretty common in open-source software for some reason, I guess because everyone pools their knowledge.

It isn’t really a big deal or anything if major changes have to be made for it, I just found it a bit strange because I’m coming off commercial software. I can probably adapt to it with practice.


#4

Could we have an outline of the brush shape in the cursor? Or at least a line showing the angle of the brush?

See also my request here Flat brush about easily change the brush rotation.


#5

Just a thought:
Maybe doing a switch from soft to hard cursor when you start drawing would solve a possible lag, if there’s any (maybe it’s just premature optimization?).

That way you have feedback from the cursor when not drawing, and from the effect when drawing.


#6

Yeah, that’s a possibility. Some mini-ring that reflects the tilt maybe? So let’s talk UX for this. Here’s the back-and-forth in my head…

  • Let’s say the user is zoomed all the way in and using a huge brush
  • They’re gonna want to see where their cursor is centred.
    • Perhaps the outline ring will be bigger than their screen.
    • So maybe the ring is software and they get a little + cursor to show the centre?
  • That little hardware “+” might be hidden if it’s bigger than the ring though
    • Or replaced with a hardware cursor ring? We’re taking about 32 or 48 pixels here, hardware issues won’t really apply.
  • It’ll update quickly even if the ring lags.
    • Eyes focus on centres of things when doing. Ppl have real tunnel vision!
    • But where you’re not focused, you spot motion better. Blame our evolution for this. There might be a leopard lurking where you’re not looking directly!
    • Perhaps the inevitable software/hardware lag won’t be that disturbing if artists are fixating on the middle “+”. It’s worth testing.
  • Some users are very particular about the look of the drawing cursor.
  • Need to keep redraws minimal to avoid lag.
  • Is there a good algorithm for deciding what tiles need redraws based on a ring shape (probably an elliptical one, angled for tilt)
  • The rendering cache we already have will help a lot during these redraws.

While the stylus is in contact with the drawing surface, do we need the same level of visual cursor feedback as when the stylus is hovering? I think a lot of the feedback here is provided by the brushstroke itself rendering. We could diminish the cursor to just the “+”, just a maximum-sized hardware ring-and-"+", or nothing at all.


#7

For me personally, the cursor is mostly important so that I can see where to begin the stroke.

It can be useful during the stroke too, when the stroke lags behind the stylus. Some sort of indicator would be sufficient for that.

Perhaps we could have a hardware ring as long as the brush size is within the maximum sized ring. If the brush is larger, then use a + with no ring.


#8

Ok, that seems hard…
Related: https://gamedev.stackexchange.com/questions/12836/ellipsoid-v-box-collision-detection
It’s about ellipse-rectangle collision detection, but the interesting idea is to apply an inverse matrix transform to everything, making the ellipse transform into a circle, and the rectangles become quadrilaterals.
That way you could check if all 4 points are either inside or outside the circle, which is just distance from the center (all that after filtering by bounding box or whatever).

I don’t see this as a deal breaker, just a minor inconvenience.