[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: My ideas about GSOC Tiles project
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2009-04-02 7:33:32
Message-ID: Pine.LNX.4.64.0904020932570.1820 () calcifer ! valdyas ! org
[Download RAW message or body]

On Thu, 2 Apr 2009, Dmitry Kazakov wrote:

> >
> > > An issue with "m_projection requests _changed_ tiles" could be done with
> > > tile-versioning. Every tile could have a revision that was used by
> > KisImage
> > > to keep the projection up-to-date. But it's quite difficult to implement
> > > and we have to think over it properly.
> > Hm... Yes, that sounds pretty complicated.
> >
> 
> It could use Qt-signals, maybe. Are they queued? Well, i'll think it over at
> my leisure =)


They can be queued across threads, as long as the destination object is in a thread with an eventloop.
> 
> 
> > > I think it's not the worst problem. By the way where this paint device
> > > moving used?
> > Whenever you move a layer using the move tool.
> >
> 
> Now i see.
> There is an potential for future expansion: moving paint device across tiles
> in background...
> 
> 
> 
> > > So to say, can two KisPaintLayers be merged tile by tile?
> > Yes, provided the origin is the same.
> >
> Sounds  promisingly :)
> 
> Well, i submitted my proposal last Sunday.
> http://socghop.appspot.com/student_proposal/show/google/gsoc2009/dmitryk/t123835355302
> 
> I think it's quite detailed. Did i forget something?

I think it looks very good.

Boudewijn

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]