<br><br><div class="gmail_quote">On Tue, Jun 2, 2009 at 1:00 AM, Bart Coppens <span dir="ltr"><<a href="mailto:kde@bartcoppens.be">kde@bartcoppens.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Monday 01 June 2009, Dmitry Kazakov wrote:<br>
> Good evening everyone!<br>
> Today i've commited a draft of KisTiledDataManager. I would be glad if<br>
> someone reviewed and commented it a bit =)<br>
</div>Looks like a great start :-)<br>
<br>
3 quick comments:<br>
* I'd love to see some more documentation on the API (not necessarily all<br>
functions, but I think at least each class could have a small description of<br>
itself). Adding it earlier ensures that you don't forget it afterwards :-)<br>
</blockquote><div><br>There is some documentation in comments in sources. I agree, i should add more. Btw, how can i automatically translate those comments into html like in <a href="http://www.koffice.org/developer/apidocs/krita-image/annotated.html">http://www.koffice.org/developer/apidocs/krita-image/annotated.html</a>? I think it's called something like doxygen, isn't it? Where can i read about it?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* As for the race condition in getTileLazy: I think I prefer having a<br>
clean-looking relockForWrite function.</blockquote><div>It's not so easy as the first way =)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Although I'm not quite sure that's<br>
even needed? Can't you just lock m_lock at the beginning of getTileLazy, and let the other<br>
functions recursively lock? (Or do I misunderstand what getTileLazy is<br>
supposed to do?)</blockquote><div> </div><div>Heh... :) QReadWrite lock is written so, that you can't recursively lock for another type of access :( I.e. if you have read-lock acquired, you can't get it for write access even sitting inside the same thread. If you try, you'll get a deadlock. Maybe this is a bug? And we should report it?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* About the lack of multithreading gain in KisTileProcessor: I'm guessing that<br>
any increase of gain would depend on the complexity of the action applied to<br>
the individual tiles. So that while for now it doesn't have any advantage,<br>
this might be the case later on, when we use this for more complex<br>
functionality?</blockquote><div> </div></div>That's why i like this idea! Simple reading/writing i too easy job for two cores and they are stuck in the bottleneck - shared memory controller. But scaling and other stuff... they are good pretenders for TileProcessors. But first i should solve problems with object-oriented stuff (constructors, etc.) that takes about 20% of time.<br>
<br clear="all"><br>-- <br>Dmitry Kazakov<br>