Week 1 recap- research and prep

Hi welcome to the blog. It's Week 1 and most of this time is allocated to researching and learning how the code base works. The main point is that I am trying to understand how exactly Krita "draws" aka puts polygons onto the canvas. Right now there are a few files that seem to be relevant like:

"kis_brushop" - kis_brush op has a constructor that initializes various brush options like size, ratio, rate, etc., and sets up the m_dabExecutor which manages the actual painting operations. This is where I might need to introduce new parameters or configurations for the perfect-pixel option.

"KisPainterBasedStrokeStrategy" - This code sets up and manages the initialization, execution, and cleanup of painting strokes, including handling indirect painting and masking brushes. The 'initPainters' function configures painter for both direct and indirect painting scenarios, while 'deletePainters' ensures proper cleanup. The ‘initStrokeCallback’ function organizes the sequence of operations needed to start a stroke, including setting up devices and initializing painters.

"KisToolFreeHand" - this seems to handle a stroke event, and KisToolFreehandHelper::paintEvent() contains information like the pointer's position, pressure, etc, and then forwards it to the paintEvent method from KisToolFreehandHelper

"KisToolFreehandHelper::paint" - following the logic from KisToolFreeHand gets us here. This function handles actual painting logic, including smoothing the stroke when necessary. I am not too sure what the difference between this and logic from kis_painter is yet, but both files seem to handle the math/logic for the grid-based "drawing" Krita does.

---

It's going to be important to be able to understand how pixels are placed specifically because for our perfect-pixel algorithm to work, while this option is selected, we are going to make adjustments to how pixels are placed. The implementation from Tom Cantwell in his blog involves three important coordinates to track. 1.) The last drawn pixel, 2.) the “current pixel” - this is where your cursor currently is - and 3.) the “waiting pixel” which is an intermediary point that you have to keep track of, waiting to draw only until it’s confirmed to be in the desired direction. His idea is to wait to draw the next pixel (the waiting pixel that is always adjacent to the last drawn pixel) until we confirm that the current pixel is going in the same direction as the last drawn pixel. So while the current pixel is still adjacent to the last drawn pixel ( this is a straight line) the waiting pixel becomes the current pixel. While the current pixel is in the same direction as the last drawn pixel but further than one pixel away fill in the waiting pixel ( so that we can get a straight line ). Then for the case where the current pixel deviates and is no longer adjacent/in the same direction, we do not place the waiting pixel and instead change the last-drawn pixel to the current pixel.

Currently, we are debating on where/how exactly this this option should be. The leading implementation is that there be a checkbox option inside the brush editor for this option. Asked KA for any preference for how this is done, but it seems that most of them wouldn't mind if this option is just a new brush preset with this option ticked.
The two options are that in the brush editor, we can either have this perfect-pixel checkbox under sharpness ( since pixel brushes are just brushes with 100% sharpness, the option being right next to 'Align the brush preview outline to the pixel grid' ) or we can make a new tab "Pixel Art" and put the perfect-pixel option here along with the 'Align the brush preview...' option.

In the meantime, started a new merge request for this feature and made a new placeholder option under sharpness. The next steps will be to figure out how to make a new brush preset with this option ticked and to get to the meat and bones of things and tackle the actual algorithm. Thanks for reading the blog that's all for week one.