Skip to content
GitLab

Add variable softness to fill tool and contiguous selection tool

Merged Deif Lou requested to merge deiflou/krita:deiflou/floodfill_improvements into master

This adds a softness parameter to the fill and contiguous selection tools.

  • Adds the functionality to KisScanlineFill/KisFillPainter/FillProcessingVisitor
  • Now the smooth/not-smooth variants are separated in two selection policies in KisScanlineFill
  • Changed implementation of the selection policies to use only integers
  • Add slider in the fill tool to set the softness
  • Add slider in the contiguous fill tool to set the softness and hide the antialias option
  • Now the contiguous fill tool uses the flood fill policies for softness so no custom code to make the selection aliased is needed.

NOTE: Some tests fail. I think that may be because of one or two things:

  • I changed the selection policies to use only integer arithmetic. (It seems to be the next point).
  • I changed some conditions in the hard variants of those policies. In HardSelectionPolicy::calculateOpacity and HardSelectionPolicyExtended::calculateOpacity member functions (the not-smooth variants) I use: 
    return this->calculateDifference(pixelPtr) < m_threshold && this->calculateSelectedness(x, y) > 0 ? MAX_SELECTED : MIN_SELECTED;
    instead of the previous: 
    if (!useSmoothSelection) {
    return diff <= m_threshold ? MAX_SELECTED : MIN_SELECTED;
}
    The decision to change that is because I think there was a difference between the smooth and not-smooth code. The smooth code was: 
    quint8 selectionValue = qMax(0, m_threshold - diff);
quint8 result = MIN_SELECTED;
if (selectionValue > 0) {
    qreal selectionNorm = qreal(selectionValue) / m_threshold;
    result = MAX_SELECTED * selectionNorm;
}
result;
    In this case if the difference is equal to the threshold, the code in the if is not executed and the result is MIN_SELECTED, the opposite as in the not-smooth code, where if diff <= m_threshold the result is MAX_SELECTED.
    I dont know If I should leve the code as before or as I changed it (or maybe change the smooth case intead of the not-smooth one). Also, I guess that if it is changed I should fix the tests?

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
Edited by Deif Lou