<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Monday 14 September 2009, Boudewijn Rempt wrote:<br>
> On Monday 14 September 2009, Cyrille Berger wrote:<br>
> > On Monday 14 September 2009, Dmitry Kazakov wrote:<br>
> > > It seems that 70% of the time is consumed by<br>
> > > KisBrightnessConstrastFilter::createTransformation(cs, config) method,<br>
> > > not by filtering itself. =)<br>
> ><br>
> > We use to cache those, but it was triggering multithreading issues, it is<br>
> > clearly worth to investigate those issues, and restore the caching.<br>
><br>
> LCMS 2.0 should make that a lot easier, with its improved thread-safety.<br>
I think it was more our own fault, deleting stuff in an unsafe way. Since the cache was owned by the configuration, if the configuartion was edited, the cache would be regenerated even if there is a filter running. For me, the solution would probably be to store the transformation in a smart pointer class. <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Cyrille Berger</p></body></html>