Hi,
[EMAIL PROTECTED] writes:
> > 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
brushes).
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.
Salut, Sven
