How can you think that a simple brush filling algorithm can be the same as one of a complex program?
Okay, I think I see your point now. Correct me if I'm wrong, but you are refuting the basis of my original claim because there is no certainty that a the Photoshop brush is O(n²) due to having to accommodate a lot of features? This is not besides the point
I would still infer that my conclusion is fundamentally apt, and here's why:
It is true that you may do more things with the Photoshop brush tool than render circles. However, for any brush tool there is an enclosed block of n-by-n pixels that are potentially affected by the brush and where the same repetitive work is being carried out for every pixel in that block. This means, that at the very heart of the brush tool lies an O(n²) algorithm because you have to do something to at least n-by-n pixels.
In complexity analysis, only the highest order term is included in the big-O notation due to it being the term that has the highest rate of change. That means that the only way to differentiate between the brush tool that was scrutinized in the article I linked to (which was not the one used in the author's tool, but rather the GIMP implementation) and an algorithm like the one found in Photoshop would be if it could be concluded that Photoshop has a time complexity term that is of higher order than n². At this point, there is nothing to suggest such a conclusion, although it shouldn't necessarily be ruled out. Photoshop could have a higher linear and constant overhead than that of the GIMP implementation for all we know, but they are both still fundamentally O(n²) which is why extrapolating the conclusions of why GIMP performs poorly and applying them to Photoshop makes sense.