I'm curious regarding the expected behavior of any of the image draw modes when used in conjunction with a pattern set via
setPattern. For context, let me first enumerate the different ways to set a pattern for drawing:
setPattern(image, [x, y])
setDitherPattern may be used in conjunction with
setColor to indicate which color the dither pattern should be drawn in. We can largely ignore this option for the purposes of this discussion.
setPattern, by contrast, bakes the color information into the encoded
pattern or pattern
image, and as such the currently set color has no effect. (In fact, calling
setColor clears the current pattern.) Thus, for most purposes, the pattern behaves just like an image when it comes to drawing. This is reasonable, especially given that option 3 literally sets the pattern using an image.
Fonts are also essentially represented as images. Somewhere along the way I learned the trick of using the image draw modes (e.g.
kDrawModeInverted) to turn would-be-black text into white text which would appear against a dark background. Because the fonts are images under the hood, calling
setImageDrawMode on the current graphics context impacts their display.
This brings me to the question: would one expect the current image draw mode to affect the rendering of patterns? Given the similarity with fonts, I assumed this would be the case — I was mistaken. I can pre-process the images passed to
setPattern, of course. However, I'm working on a system that pre-renders various pattern images at initialization and then draws using them later on, and I was surprised to discover the need to create separate patterns for light-on-dark vs. dark-on-light applications given that neither
setImageDrawMode will affect the displayed pattern.
Do others share my expectation? Is this a bug; a quirk of the API where there was no strongly defined expectation in its initial design; or are there good reasons that patterns behave this way?