Hi, egger@xxxxxxx 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
