From BlenderWiki
There has been some refactoring for the paint systems under blender 2.67.
The work done had a couple of targets:
Decouple texture painting code in 3d projective code and 2d image space code.
This was useful for many reasons, first of all code clarity. The old code did different input coordinate conversions for the two paint contexts using the same variables, meaning that doing something for one system could potentially break the other. Also, the same core code ended up doing lots of unneeded checks for both paint systems and having many variables just for bookkeeping. There is still a common operator for the two systems but stroke stepping, initialization and cleanup are now independent.
Make texture painting code reuse the generic stroke system.
This has a number of benefits, most apparent of which is support for many stroke features that were available to other modes apart from texture paint. Also, a feature available to texture paint (spacing pressure control) was added this way to other modes as well. To reuse stroke code for 2d painting, we also had to account for scaling, since the size of the brush is tied to the zoom of the image editor. This could be unified with brush size locking in the future. Sculpt mode specific features were separated into the stroke system too. This provided rake and anchored support out of the box, though admittedly, anchored brushes require paint context specific implementations to work.
Reuse the 3d viewport texture sampling function
It is useful to reuse the texture sampling function across paint systems because it allows us to support new texture samplers across all modes. As proof of concept to that, texture sampling was added to vertex paint mode. To make this work, the texture sampling function of sculpt mode was separated into a generic brush interface, with the exception of area mapping, which is still sculpt mode specific for now. The 3D sampler works by feeding it the screen space variables of the dab, or the 3D coordinates for 3D mapping. Since getting the 3D coordinates is a paint system specific task, I leave it to the system to detect the mode and act accordingly. This optimizes passing an extra vector to the sampler. Extraneous calculations are avoided by deing done in the paint stroke function rather than at sampling time.
Support for alpha textures
Alpha textures are modulating the strength of the brush directly, rather than the colour of the brush. It turns out there is some conceptual blurring here.
Essentially, sculpt mode has been using "alpha" textures all along. So it might make sense to recode sculpt to use alpha textures (which would mean change mtex to mask_mtex in the code). The challenge is that our stroke code does a lot of manipulation to texture coordinates of the primary texture (which does alpha control for sculpt, colour control for texture paint). So we have the same texture used for alpha control AND for colour control depending on the paint context. This is not ideal, but the stroke system itself makes us distinguish between primary and secondary textures (which would be alpha/mask textures in texture paint mode). Besides, the usefulness of a few mapping modes, such as rake and anchored can be debated for secondary textures and it would be a pain supporting all combinations for both primary and secondary textures.
Reuse overlay code
Support for overlay is not too difficult, but there is a challenge if we want color support. Luckily, a query function was introduced to detect what mode we are in so we can detect and enforce color support for vertex and texture paint.
