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

List:       kde-kimageshop
Subject:    Re: Plugins for Krita
From:       Patrick Julien <freak () codepimps ! org>
Date:       2004-02-11 1:00:43
Message-ID: 200402102000.43939.freak () codepimps ! org
[Download RAW message or body]

>
> yep that's true. I see two ways to implement this :
> 1) I check the color model, and I must implement my algorithm for each
> model 2) I made a general algorithm, but I need to know the number of color
> channels and if there is an alpha channel. But I didn't see any information
> about channels in core/color_strategy, maybe we need to add such
> information in a const array in kis_global.h. Maybe it already exists and I
> didn't find it.

The information is in KisPaintDevice.

>
> > 3) Not checking for events.  Until we have a pipeline where you a simply
> > queuing concrete commands to a worker thread.  The application will look
> > frozen when this is going on.  Not much of a problem on small image, but
> > on a moderate size one, Krita will just hang there while this executes.
>
> How can I check for events ?

qApp -> processEvents();

>
> > Even  with a worker thread, this would need to access the data on a tile
> > boundary so that you can lock the tiles you are working on right now.
>
> I am not quite sure I have understood this very well, do you mean that two
> process may want to access to the image at the same time ?

Several threads in the same process.   Since the image is cut up in tiles, 
it's easy for different threads to access the same image at the same time by 
"locking" a tile.  

_______________________________________________
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]