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

List:       kde-kimageshop
Subject:    Re: Preset widgets refactoring
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2015-07-13 11:35:37
Message-ID: alpine.LNX.2.00.1507131310460.11323 () calcifer ! valdyas ! org
[Download RAW message or body]

On Sat, 11 Jul 2015, Dmitry Kazakov wrote:

> Then though, boud: are you basically suggesting to rethink the whole resource \
> management?

Yes. I just haven't had the stamina to write up a plan. I've been meaning 
for a week to asnwer Stefano's mail in more detail, but I haven't managed 
yet.

> Because i know the interaction requirements for the widgets and presets (and well \
> also the tag should be easy), but i don't know how all the rest is done.

Well, I think even the selectors and tagging widgets interaction need a 
rethink before we can be sure it's worth spending the time on; there are a 
bunch of problems with the selectors we have now.

> You might have to expand a bit what's your idea because for instance "ranging from \
> us having to load all resources on startup to present them in the selector widgets \
> (which takes lots of memory) ", do you mean that you think about a widget that just \
> shows name and icons for the preset but it actually loads each preset on the fly \
> when they are selected and then they are kept in memory, forever or unloaded again \
> when some number of loaded preset is reached? So like a "pool" but with fixed size.

Right now, for some resources actually load, generate the icon, then 
discard the data until the resource is selected. (Or did I only do that in 
a branch which never got merged...).

What I want is:

* on startup, we read a database with name, filename and icon for all 
resources.
* on startup, we check whether there are new resources that are not in the 
database, then add those.
* on selecting a resource for the first time, we load the real data

Whether we try to keep memory consumption low by dropping resources in a 
sort of fifo isn't something I've thought about yet, but it could be a 
good idea.

> I think we don't need to limit loaded resources. If loaded, it can be kept in \
> memory forever. We just need to avoid loading everything at once on start. Right \
> now, all the loaded resources take about 100MiB right on start of Krita, even when \
> no image is open.

In a default install - but artists will have way, way more resources than 
we package by default, which is one reason why photoshop uses the 
libraries concept. When you load a new pattern library, the other patterns 
are removed from memory.

Right now, krita cannot handle a situation where a user has collected 5000 
brush tips: it will cause a slowdown on startup, eat memory uselessly and 
the gui doesnt really support hanlding that many resources.

> i find it a bit difficult doing it just "on paper" without knowing all the \
> requirements and without seeing what the current code does, so that i know, when i \
> tear everything apart, what functionality i need to restore, plus all the widgets \
> that needs specific interaction/notices (as in KisPaintOpBox).

Sure, we're not at at stage where we can work on the code yet. And I might 
be out of context, but was this something you intended to work on now? I 
thought it started with the refactoring Smjert was thinking about.

> 
> How about collecting all the requirements in one place? I have just created a page \
> on the wiki [0], let's use it for all the requirements we could think of.
> 
> There is also a page that Ilya Portnov from the Russian Community created with the \
> wishes for the presets infrastructure [1].
> 
> [0] - https://community.kde.org/Krita/docs/Requirements_For_The_Resource_Management
> [1] - https://community.kde.org/Krita/docs/Krita_Presets_Wishes

Sure, but it'll take a bit of time and this time I really, really want to 
have a proper design for resource management. It's one of the oldest bits 
of Krita and has grown over the years through accretion.


> And about the central class, KisCanvasResourceProvider, yes it's central but it's \
> not exactly what i had in mind (well nothing says that the way i was thinking is \
> the way to go, but want to explain where i see a difference from what i was saying \
> and what you both said): the provider right now is pretty dumb, more than a manager \
> that decides things, is just something that does what other tell it to do.
> 
> 
> Yes, I'm totally agree with you. And what is more, KisCanvasResourceProvider \
> resulted in being just a convenience wrapper around KoResourceManager, resulting in \
> two different ways of accessing resources, which is a bit ugly :(

Very ugly. And it's been confusing me ever since that was split up, back 
when we did the Qt4 port.
> 
> 
> It just stores resources and then emit the canvasResourceChanged signal to inform \
> others that something has changed.
> Currently it's KisPaintOpBox that actually behaves like the class i was thinking \
> about (its setCurrentPaintOp does a lot of work and "decisions"), except that it's \
> a widget which imho shouldn't do all that work.

Yes, I totally agree with that. And that sometyhing we can ghet started on 
in any case, without looking at the whole resource management problem.

> 
> 
> Agree.
> 
> 
> --
> Dmitry Kazakov
> 
> 


[Attachment #3 (text/plain)]

_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


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