On 7 Feb, Sven Neumann wrote:
>> Hm, generating a lookup table and getting the pressure from there
>> instead directly from the driver would be trivial to implement and
>> seems like a worthy feature to me.
> What driver are you speaking about?
The standard Intuos Win driver.
> The code to use a LUT to map brush pressure to a more sophisticated
> curve is already in the paint_core (only #ifdef out). Look for the
> FANCY_PRESSURE define. Actually this is not what we want...
Why not? Finegrained control is never bad. For example I have to press
too hard to get maximum pressure which is really annoying. With Win
I can easily change that. So I'd like to have a per-tool-LUT.
> Currently Mitch is working on the previews and selection dialogs for
> data objects. IMHO there is a need for at least two more things to
> think about:
> - A cache mechanism to avoid holding all the data objects in memory.
Positive. I'd propose just keeping the previews in memory and loading
the brush on demand. This way we'd just have to keep small icons in
memory and load the big brushes/pipes just when someone wants to see
the complete brush or use it.
> - A mechanism to select different data from the same object depending
> on paint_core parameters (like the brush-pipe we have now, only more
> general). This does not imply that all data has to be stored on disk
> as pixmaps, it could also be the result of applying a transformation
> on pixmap data or could even be completely calculated (think
> generated brushes).
Think mathematical brushes calculated in realtime depending on
toolfeedback and an UI.
> The paint_core should be changed to work with abstract data objects
> instead of distinguishing between brushes, patterns, textures and
> images. While this might be a good way of sorting things for the user,
> there is no reason why I shouldn't be able to paint with an image,
> using a pattern as texture. The paint_core doesn't really need to know
> the difference.