Week 9 recap - Dealing with sharp corners

·

3 min read

So after filtering out tiny movements and duplicate outputs, the thing left is to look at small corner inputs. Here's the three pointer that I'm working on in kis_tool_freehand:paint: ( Lets say the scenario is that we are drawing a straight line from left to right) We start at point(0,0) Right now there is no last drawn pixel, just a current pixel and a waiting pixel that is set to the current pixel . If there is another doStroke or mouse release we just draw this pixel. (basically always draw this pixel) Try to imagine that the waiting pixel is basically the current pixel that performs the drawing, but always slightly lags behind.

We moved the cursor to (0,1) That last waiting pixel of the last iteration is drawn, and becomes last drawn pixel. Now we are at point(0,1) where both the current pixel and waiting pixel is. Now we wait for the next doStroke or mouse up. Here is where basically nothing happens just waiting on another point to see if we are allowed to draw this waiting pixel.

two scenarios here: We moved the cursor to (0,2) from (0,1) 1.) If the NEXT currentpixel is still in the same x or y axis as the last drawn pixel, the waiting pixel is drawn and we reset waiting pixel = currentpixel.

We moved the cursor to (1,1) instead from (0,1) 2.) If the NEXT currentpixel is NOT in the same x or y axis as the the last drawn pixel, the waiting pixel is not drawn and we reset waiting pixel = currentpixel.

Now we are at (1,1) and we can practically restart from the start again. There is "no last drawn pixel", and we just draw at (1,1) and then apply the rest again (waiting for the next pixel, checking if its in a line. If so draw it, if not update waiting pixel without drawing and then restart again.)

A few problem that has come up is that, compared to other programs with pixel-perfect, this doesn't seem to proactively draw at the same time AND reactively get rid of the corner ( when you draw a straight line, the corner pixel does seem to pop up UNTIL you input a third non-striaghtline pixel, in which the last pixel in the previous line disappears ). I was wondering if there is a way that I can erase reactively like this as well, or maybe calling draw on m_d->previousPaintInformation with the previous color. The other problem I'm dealing with is the initialization of these Qpoints might be a little flawed because, depending on the stroke speed or the type of stroke, since at paint we might completely skip some pixels. I also need to work on some sub-pixel inaccuracies, probably by getting rid of floats.