New Tiled Data Manager ideas and tests

Dmitry Kazakov dimula73 at gmail.com
Mon Jun 1 23:41:21 CEST 2009


On Tue, Jun 2, 2009 at 1:00 AM, Bart Coppens <kde at bartcoppens.be> wrote:

> On Monday 01 June 2009, Dmitry Kazakov wrote:
> > Good evening everyone!
> > Today i've commited a draft of KisTiledDataManager. I would be glad if
> > someone reviewed and commented it a bit =)
> Looks like a great start :-)
>
> 3 quick comments:
> * I'd love to see some more documentation on the API (not necessarily all
> functions, but I think at least each class could have a small description
> of
> itself). Adding it earlier ensures that you don't forget it afterwards :-)
>

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 http://www.koffice.org/developer/apidocs/krita-image/annotated.html? I
think it's called something like doxygen, isn't it? Where can i read about
it?


> * As for the race condition in getTileLazy: I think I prefer having a
> clean-looking relockForWrite function.

It's not so easy as the first way =)


> Although I'm not quite sure that's
> even needed? Can't you just lock m_lock at the beginning of getTileLazy,
> and let the other
> functions recursively lock? (Or do I misunderstand what getTileLazy is
> supposed to do?)


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?


> * About the lack of multithreading gain in KisTileProcessor: I'm guessing
> that
> any increase of gain would depend on the complexity of the action applied
> to
> the individual tiles. So that while for now it doesn't have any advantage,
> this might be the case later on, when we use this for more complex
> functionality?


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.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090602/96f1b1fb/attachment.htm 


More information about the kimageshop mailing list