I'm taking some lessons from pensieve.love here. It seem like specific
pixel thresholds don't matter too much for plain lines.love.
I'd probably feel safer if I just used Text.cursor_out_of_screen in
these places, but it means we draw the screen twice for most events[1].
Let's see if we can get by with the current approach.
[1] Or we have to start scheduling things for the next draw, which is
more complex to orchestrate.
The way Text.draw is called by edit.draw, we know it'll never be called
for lines above screen_top1.line. Comparing every line on screen with
screen_top1 makes no sense. The intent is really just to compare with
screen_top1 only for the first line, and otherwise to ignore this check.
scenario:
slowly press down mouse button and drag to draw a line
release mouse button
Before this commit the point would jump just a little bit on release,
and points would go slightly to the left of where I expect.
Yet another thing it's hard to write an automated test for.
Thanks Lion Kimbro for pointing out this issue.
I still have to use floats for start/end angles of arcs. That might be a
sign that I don't have the right serialization yet for them. Or that
that feature needs to go.
I started out with a hazy idea of only using 8-bit ints for coordinates,
but now I'm not sure how committed I am to that constraint. While the
width is always 256 units, it might be nice to create long portrait
drawings at some point, whose height is greater than 256 units.
Disquieting that none of my tests caught these. On the other hand, I
also haven't noticed any issues in practice. Perhaps cache invalidation
is often unnecessary.
The published version of lines.love was broken for almost an hour. The
cursor would render one position to the right of where it really is. To
fix it, this commit rolls back 26ba6e4e5a. There doesn't seem a good
way to test it.
Kartik K. Agaram