> > I think a better solution would be a definable pressure curve, much
> > like Wacom's Windows driver has.  That'd probably be a feature of the 
> > general mechanism you described and perhaps what you have in mind.
>  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 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...

>  I made an entry into bugzilla so we don't forget that. I'd like to wait
>  for Sven and Mitch to complete the changes so we don't have to implement
>  this in several places hopefully.

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.

- 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

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

Salut, Sven

Reply via email to