Well, as the question above asks. Why does Krita require a massive chunk of KDE to run? Krita seems to require: (List taken from Arch-Linux repositories)

kdebase-runtime
kdeedu-marble
kdegraphics-okular
kdepimlibs

Which in turn require :

Nepomuk-core
kdegraphics-mobipocket
kdelibs

Why is this? It's not like all QT applications require kde runtimes right? So why does Krita?

I also notice in relation to this that the folder structure for calligra apps in my home folder is located in .kde4/... which I think is kind of ugly, but I guess that's only cosmetic.

To be honest I'm not a fan of this since I don't use KDE (It's too slow in my opinion; benchmarks show it slower than Windows' Explorer & Aero even) so I was wondering why this is needed, partially just so I can accept it more easily.

Well, first of all, Krita requires the KDE libraries because, well, it's a KDE application. KDE provides us with the basic building blocks for things like saving settings, loading plugins, creating a mainwindow, handling zip files, common widgets and more. Then Krita is a Calligra application. Calligra provides us with things like vector and text objects, document handling, common widgets and more.

On Linux, distributions' dependency graphs work on the include-everything principle. Because Calligra Words uses the KDE pim libraries to integrate with the address book, one of the calligra libraries links to kdepimlibs. That's not necessary for Krita, and for Krita on Windows I don't include that dependency. But your distro includes it. Marble is used by the RDF library and by the map shape plugin, again, not useful for Krita, but now it becomes a dependency for your distribution. And that's basically the story for all the dependencies you find weird.

If you build Krita yourself, you will only need kdelibs -- and if you build kdelibs yourself you could try to remove more dependencies like nepomuk, dbus and so on.

If you don't want krita to save its settings to the .kde folder, you can set the KDEHOME to something else... On Windows, I've hard-coded that to krita instead of .kde, for instance.

This is a huge achilles heel with Krita unfortunately. I know there isn't a solution to it but I don't use kde either and I'm on Arch. I just updated my system and Krita 2.8 doesn't work. Some kde library problem. Krita ends up being a huge bloated addition to your system. I'm not sure I can be bothered solving these problems all the time.

EDIT: I got it working in the end.

That problem will be solved with KDE Frameworks 5 where everything is modular.

It will still depend on how distributions package things like the calligra libraries. Those things like kordf and koreport kodb which pull in soprano and a database -- krita uses neither of those, but if a distribution packages the calligra libraries as one package, that package will drag in all the dependencies and people will keep complaining. In other words, if installing Krita installs soprano or mysql, complain to your distribution.

Then again, if someone makes half a dozen reasonably complex drawing with Krita, that'll likely take as much disk space as all the dependencies put together, and I know this: if I were a user I'd prefer developers spent their time on fixing bugs instead of removing dependencies.

boudewijn wrote:Well, first of all, Krita requires the KDE libraries because, well, it's a KDE application. KDE provides us with the basic building blocks for things like saving settings, loading plugins, creating a mainwindow, handling zip files, common widgets and more. Then Krita is a Calligra application. Calligra provides us with things like vector and text objects, document handling, common widgets and more.

On Linux, distributions' dependency graphs work on the include-everything principle. Because Calligra Words uses the KDE pim libraries to integrate with the address book, one of the calligra libraries links to kdepimlibs. That's not necessary for Krita, and for Krita on Windows I don't include that dependency. But your distro includes it. Marble is used by the RDF library and by the map shape plugin, again, not useful for Krita, but now it becomes a dependency for your distribution. And that's basically the story for all the dependencies you find weird.

If you build Krita yourself, you will only need kdelibs -- and if you build kdelibs yourself you could try to remove more dependencies like nepomuk, dbus and so on.

If you don't want krita to save its settings to the .kde folder, you can set the KDEHOME to something else... On Windows, I've hard-coded that to krita instead of .kde, for instance.

Just to quote you on that since I never actually replied (i've had some more time to think now)

I generally feel that krita has outgrown Calligra and should not be a part of it, I never hear of anyone using calligra for anything, however Krita is a subject that pops up from time to time. I Krita is the only application that is a part of calligra I have ever actually heard of to begin with! And I've been around KDE a fair amount too, never have I heard calligra or any of it's applications (except Krita) recommended by anyone for anything.

About having outgrown Calligra,

Firstly Krita does not need Calligra (Why on earth would I want to be able to read documents in Krita? It is just not a good tool to do so at all, no one in their right mind would do that unless he was too lazy to install libreoffice or a proper pdf reader. And besides this, quite frankly the text object implementation for Krita is total ****. When I want to add text to whatever I'm working on in Krita I always have a hard time. They're slow and not easy to use at all, unintuitive, it's an area that I think really needs to be reworked) don't know what you mean by vectors though, but if you do mean vectors as in straight lines and curves, circles and al lthat, that is I guess fairly important. If you're talking about the stuff in the "Add Shape" menu, that is not needed except for the text part which like I said is **** (I need to draw a box, click it three times, get massive amount of lag when I'm typing letters and no resizing support it's just plain bad! and I've been mad at it so many times, this is one of those things that should just be rewritten from scratch or forked from something else and better implemented)

I also noticed a bug where having text in an image (or much of it) will just cause a lot of lag as well (also having many vectors, as in straight lines and such, I think krita has problems with small things like these in big canvases)

Secondly, apart from perhaps the developers I doubt many of the people that use krita actually use (nor want to use) Calligra or even KDE to begin with. This can actually be a pretty big problem for me since calligra and kde dependencies that get pulled in on Linux size up to be fairly big, it's a humongous issue if I'm trying to keep my setup small and if that is my plan it will force me to use KDE over other DE/WM simply because krita forces me to install most of it to begin with.

And thirdly, these building blocks you talked about? why would we want to be able to handle zip files in krita? it is not an archiver! creating a mainwindow should be something QT does, not KDE, saving settings as well, no comment on loading plugins I wouldn't know about that. Not widgets either (are you referring to dockers?) And if you're talking about the file browsing as well (i.e. finding and loading files) that is bad too, not only is it slow but it does not support browsing hard drives (you have to navigate from root("/") to access other hard drives) I think it used to do this properly but a recent update removed that functionality (I may be wrong about that last part though, maybe it never did support browsing by hard drive rather than just root/home folder).

Of course I am not saying krita is bad, I'm saying that calligra and kde are weighing it down a lot and many of the features implemented that depend on these two (or most of them) seem to suck to begin with. Krita is great, but it could be much better.

As for making complex drawings that take up a lot of size to begin with, well there are several reasons to keep your install small.

1: Running a distro off RAMFS/TMPFS for extreme speed (makes SSD look bad really, I imagine when we have CPUs that have RAM intergrated in them, SSDs will replace RAM i.e. be loaded into the DIMM slots rather than SATA, much faster than SATA or PCI-E SSDs could ever be) some distros (very few though) are designed to do that from the start but many experienced users do this if they have the extra RAM (I do it)
2: Small SSDs and hybrid SSD/HDDs which generally may only have like 20GB of SSD space on them
3: Embedded systems (ties in with 1 too since the best way to do this is to load them into RAM because USB are slow) this means you want to keep your distro as tiny as possible, but say an artist likes to travel a lot but doesn't have a laptop (i.e. uses computers that aren't his to work) using a USB3 to store your linux distro would mean that you can do that (or USB 2 + ramfs)

But you're right, bug fixing and improving already existing features is more important both from the developers and end users perspective. It's just that KDE and Calligra like I said are weighing down Krita a lot when it could perhaps be avoided. To more advanced Linux users this can often be a huge turn-off. If Enlightenment wasn't so much prettier than KDE, I would not have a problem with this really (since even if KDE is normally slow as ****, it's not gonna be when running from RAM) but...

cestarian wrote:Firstly Krita does not need Calligra (Why on earth would I want to be able to read documents in Krita?

An image file is a document...

cestarian wrote: It is just not a good tool to do so at all, no one in their right mind would do that unless he was too lazy to install libreoffice or a proper pdf reader. And besides this, quite frankly the text object implementation for Krita is total ****. When I want to add text to whatever I'm working on in Krita I always have a hard time. They're slow and not easy to use at all, unintuitive, it's an area that I think really needs to be reworked) don't know what you mean by vectors though, but if you do mean vectors as in straight lines and curves, circles and al lthat, that is I guess fairly important. If you're talking about the stuff in the "Add Shape" menu, that is not needed except for the text part which like I said is **** (I need to draw a box, click it three times, get massive amount of lag when I'm typing letters and no resizing support it's just plain bad! and I've been mad at it so many times, this is one of those things that should just be rewritten from scratch or forked from something else and better implemented)

Vectors are vectors, whether you create them with the Add Shape dialog or the vector tools: it's exactly the same thing. As for the text tool, we know it should be improved.

cestarian wrote:I also noticed a bug where having text in an image (or much of it) will just cause a lot of lag as well (also having many vectors, as in straight lines and such, I think krita has problems with small things like these in big canvases)

That depends a lot on your system.

cestarian wrote:Secondly, apart from perhaps the developers I doubt many of the people that use krita actually use (nor want to use) Calligra or even KDE to begin with. This can actually be a pretty big problem for me since calligra and kde dependencies that get pulled in on Linux size up to be fairly big, it's a humongous issue if I'm trying to keep my setup small and if that is my plan it will force me to use KDE over other DE/WM simply because krita forces me to install most of it to begin with.

"Humongous" is a bit of an exaggeration, isn't it? Everything Krita needs fits in a 110mb installer for Windows, unpacking to about 200mb. That's not humongous -- it's pretty much the same size as an install of Photoshop.

cestarian wrote:And thirdly, these building blocks you talked about? why would we want to be able to handle zip files in krita? it is not an archiver! creating a mainwindow should be something QT does, not KDE, saving settings as well, no comment on loading plugins I wouldn't know about that. Not widgets either (are you referring to dockers?) And if you're talking about the file browsing as well (i.e. finding and loading files) that is bad too, not only is it slow but it does not support browsing hard drives (you have to navigate from root("/") to access other hard drives) I think it used to do this properly but a recent update removed that functionality (I may be wrong about that last part though, maybe it never did support browsing by hard drive rather than just root/home folder).

Well, for instance, we need to be able to handle zip files because .kra, .ora and resource bundles _are_ zip files... The problem with claiming that some dependency is too much, or is superfluous is that you really need to have a good grasp of the codebase, and if you don't, well, you are bound to be wrong every time you claim something isn't needed... We don't link to libraries that we don't use, and if we use a library it's because it makes it possible to achieve a certain functionality with the least amount of work.

cestarian wrote:As for making complex drawings that take up a lot of size to begin with, well there are several reasons to keep your install small.

cestarian wrote:1: Running a distro off RAMFS/TMPFS for extreme speed (makes SSD look bad really, I imagine when we have CPUs that have RAM intergrated in them, SSDs will replace RAM i.e. be loaded into the DIMM slots rather than SATA, much faster than SATA or PCI-E SSDs could ever be) some distros (very few though) are designed to do that from the start but many experienced users do this if they have the extra RAM (I do it)
2: Small SSDs and hybrid SSD/HDDs which generally may only have like 20GB of SSD space on them
3: Embedded systems (ties in with 1 too since the best way to do this is to load them into RAM because USB are slow) this means you want to keep your distro as tiny as possible, but say an artist likes to travel a lot but doesn't have a laptop (i.e. uses computers that aren't his to work) using a USB3 to store your linux distro would mean that you can do that (or USB 2 + ramfs)

That's simply a scenario that I don't think we should care about a lot. Use all the ram you have for image data, that is way more important.

By the way, this may be interesting: http://lists.kde.org/?l=calligra-devel& ... 723345&w=2 -- the notes from our sprint meeting.

Thanks for the reply, but by documents I was referring to non-image documents (like PDFs which krita does support)

My system is quite hardcore I was having this issue in both windows and arch linux, I don't think it depends on the system.

I have 24GB DDR3, i7 2600 (3.4-3.8ghz quad core on 8 threads), nvidia GTX 670 graphics card and Krita itself is installed on an SSD. You still want to say it depends on my system? if it does then it must depend on whether I have an AMD or Intel processor (is Krita more optimized for AMD than Intel?) but as you can see, there's no "not powerful enough" on my end although my processor is getting slightly dated, it's still a high ranking one.

I don't think humongous is an exaggeration, Krita's featureset is rather tidy and neat and mostly aimed at the same market group (artists) whereas photoshop is aimed at no one specific but most convenient for editors out of all, photoshop feature wise should be much more bloated than Krita is. 200mb is humongous for krita, I wonder how big mypaint is, of course not a fair comparison to Krita since it is much smaller (but also performs a lot better overall) I think krita shouldn't be much bigger than mypaint (say up to 50mbs tops) but I guess humongous is an opinion. Again though my bigger issue is that I need to pull in more than 100 packages (on gentoo anyways) to install Krita, that is A LOT (and I can remove kdepim there too)

You make a solid point on archiving support (although I wonder why use Kra over the many existing formats) and you're pretty right that I just barely know what I'm talking about (I'll admit)


I agree with you though that the scenario of tmpfs/ramfs based systems is something you should not care about, and the other systems as well. A lot of people have them but if it really matters so much to them, they can pay extra and get a bigger SSD/More RAM (I'll probably do the latter soon, although it will be fun to see how much I can squeeze out of these 24GB, I'm making an AMAZING setup here or planning to anyway with VGA Passthroughed Windows for gaming (already done this bit) and Xen based Gentoo dom0 (similar to qubes-os) running everything except for windows (and some of the bigger linux folders) from my RAM on a ramfs "partition", it's gonna be awesome when I finish it although I'm having the strangest issues with Krita on Gentoo OpenGL somehow messes up the colors on my images (makes everything much darker) and activating the texture buffer creates like a box on the center of my canvas that is transparent (basically punches a hole in my image). I wonder what the hell is up with that :/ I can't work like that.


That doc is interesting indeed I'll be looking forward to 2.9, but I personally think your primary goals right now should be performance and stability upgrades, performance is right now imo one of the weakest points of krita, stability the second-weakest.

As for releasing the full qt5 port as 3.0, I personally think it should rather be 2.9, 3.0 should be when you guys are 100% sure that it's running stable on qt5 and performing as well as possible with it, or thats what I think. Also it is generally a good idea (marketing wise) when bumping the first version number to release a big feature with it (which could be worked on while 2.9 is out with qt5 and qt5 is being thoroughly tested by the community) my 2 cents anyways. You mention taking a real hard look at vectors and text after 3.0, maybe (like I said with 2.9) that should be done over 2.9 and implemented for 3.0 (When the first number of the version is bumped it's always good to make it as shiny as possible right?) the sooner you work on vectors the better, it is a very important (for some the most important) feature for artists (a lot of artists do all of their "line-art" with vectors, but since krita is supposedly a painting application it can be excused to have bad vectors)

I don't know what you're on about with mvc but separating krita from calligra is something i would consider the way to go (as an end user) after all it's best for me if krita is just krita and not calligra-krita. (Thats what I was talking about wasn't I? that I feel krita is outgrowing calligra fast)

As for your strings, I think there is a lot of naming in krita that makes little sense (it's not very easy to get into krita from other image processing programs since most of the tools in krita except for "brush" have a different name than everything else, everything else being photoshop which is the most widely used tool of course, I think an effort should be made to make the naming of the tools in krita match photoshop's tool naming as closely as possible where applicable)

OpenGL as default was a great call!

cestarian, your enthusiasm is commendable, but it might be a good idea to become a little more involved in the project before suggesting such large amount of modification to the roadmap. As it is, you come across as a little bossy, certainly not your intention

For example, those problems you have come across, have you reported them to the bugtracker? The developers are human after all: They are forgetful and don't have a hive-mind. By posting your issues to the bug tracker you help them a lot! All the information regarding one particular issue can be grouped together and numbered, and then checked off from the list as the release date closes in.
This also helps with stability: Without bug reports, they won't even know where to start fixing the stability issues!

This comes to the second issue, the version numbers. Krita has, like blender, a semi-set release scedule. It's not as detailed as Blender's, but each release does represent 6 to 7 months of work.
The reason this is done is to ensure the users can expect a stable release with new features every month. It may not seem like it, but this is really super important to development. If you look at open source projects that don't have release cycles, they tend not to have a sense of urgency, so sometimes they end up never releasing anything D:
On top of that, users using the software is also important, again because of bug reports. But really, let's be honest here, there's nothing as cool for a programmer to see as their program being used to create cool stuff by a happy end-user
The qt port is very important to the programmers, and from previous experience they know that they would like to take their sweet time with it. Certainly, during that time, there's going to be extra attention to Krita's stability. Hence why it's planned to have the whole 3.0 development cycle just for the qt5 port.

BTW, I'm surprised, because there's not just 'sexy' features on that kickstarter. The GPU colour correction for example, if the bottleneck analyses are correct, is going to give a huge boost to performance! The super stretch goal of OSX support is going to require QT5 port, so it will help with that as well.

There's a lot of discussion about the end-user and the programmer's needs on the Krita IRC. So a lot of the things you mention there's very good reasons for, as well after ten years there's always a lot of experience backing up the planning. I hope we can leverage your enthusiasm as well to make Krita a lot better, if you dare report bugs on the bug tracker

(BTW, you can help out the translators as well with suggesting improved names for certain terms. A lot of them have been changed already, and more will be changed if necessary.)

cestarian wrote:Thanks for the reply, but by documents I was referring to non-image documents (like PDFs which krita does support)

Reading PDF files is completely independent from the rest of Calligra. The Calligra code is used opening and editing vector graphics stuff, so every time you do anything with vectors you use Calligra code. It's far more than the "Add shape" docker. All together the shared code is more an 100000 lines.

cestarian wrote:My system is quite hardcore I was having this issue in both windows and arch linux, I don't think it depends on the system.

I have 24GB DDR3, i7 2600 (3.4-3.8ghz quad core on 8 threads), nvidia GTX 670 graphics card and Krita itself is installed on an SSD. You still want to say it depends on my system? if it does then it must depend on whether I have an AMD or Intel processor (is Krita more optimized for AMD than Intel?) but as you can see, there's no "not powerful enough" on my end although my processor is getting slightly dated, it's still a high ranking one.

Well it depends on how you image looks like. The way vectors work is that we let Qt paint the graphics and then convert it to the internal data structure. That process is single threaded and only use the CPU, so most of your system isn't used in that moment. Basically the speed depends on the size of the shape and not on the type.

cestarian wrote:I don't think humongous is an exaggeration, Krita's featureset is rather tidy and neat and mostly aimed at the same market group (artists) whereas photoshop is aimed at no one specific but most convenient for editors out of all, photoshop feature wise should be much more bloated than Krita is. 200mb is humongous for krita, I wonder how big mypaint is, of course not a fair comparison to Krita since it is much smaller (but also performs a lot better overall) I think krita shouldn't be much bigger than mypaint (say up to 50mbs tops) but I guess humongous is an opinion. Again though my bigger issue is that I need to pull in more than 100 packages (on gentoo anyways) to install Krita, that is A LOT (and I can remove kdepim there too)

To some extend that will change in Version 3 because Qt and KDE Frameworks will be much more modular than they are now.

The installation size will definitely not below 50 MB simply because the installed non-code parts are bigger than that e.g. brush, patterns, gradient etc.

cestarian wrote:That doc is interesting indeed I'll be looking forward to 2.9, but I personally think your primary goals right now should be performance and stability upgrades, performance is right now imo one of the weakest points of krita, stability the second-weakest.

We are constantly working on performance and stability. Working on performance isn't easy so only a part of the developers is working on that.

Stability of the application is actually quite good. The only big cause of problems are graphics drivers. If you have a problem you should report it.

cestarian wrote:As for releasing the full qt5 port as 3.0, I personally think it should rather be 2.9, 3.0 should be when you guys are 100% sure that it's running stable on qt5 and performing as well as possible with it, or thats what I think. Also it is generally a good idea (marketing wise) when bumping the first version number to release a big feature with it (which could be worked on while 2.9 is out with qt5 and qt5 is being thoroughly tested by the community) my 2 cents anyways. You mention taking a real hard look at vectors and text after 3.0, maybe (like I said with 2.9) that should be done over 2.9 and implemented for 3.0 (When the first number of the version is bumped it's always good to make it as shiny as possible right?) the sooner you work on vectors the better, it is a very important (for some the most important) feature for artists (a lot of artists do all of their "line-art" with vectors, but since krita is supposedly a painting application it can be excused to have bad vectors)

Krita 2.9 will be used to finish the Qt 4 based changes that are still in progress. With 3.0 we will switch to Qt 5. Increasing the version number at that point makes sense because after that point Krita won't be available anymore for Qt 4 only systems like older versions of CentOS etc. Krita 3 will be released once it's running stable on Qt 5. The change isn't expected to lead to major breakage.

Most of the vector work will likely be only on the way the vectors are stored in the fileformat. Only the text part will need bigger changes and those will take much longer. Any changes there have to wait until the Qt 5 port is completed and will take a few months at least. I doubt that it will be done earlier than 3.2 or 3.3.

As the poster said, some users might not want to get Krita as it can be a little big by itself, and it doesn't help that distros build all binaries with almost all dependencies, as boud said. Even some users avoid downloading anything that pulls KDE/QT if they are using other desktop/toolkit environment (I was in that pack). Today I don't think it is a super urgent issue to fix. HD space has become very cheap and probably no one would turn down a software that does the job for saving couple (hundreds) of megs.

I am also a little restrained on space after installing the system on a 30 Gig partition (I was supposed to only test the distro), and for a source based distro it can be pretty low to be honest, but that's not really the software fault

@cestarian
For gentoo to play economic with calligra (krita only), you need to tweak kdelibs ebuild to avoid pulling nepomuk (default ON by upstream) and other nasty stuff. And probably make a another ebuild just for calligra-krita (to avoid pulling okular and others). I remember latest calligra-9999 from portage installed Kexi, Karbon, Krita, Words, etc, even with the use flags set to install krita only . So in the end you might end up doing a meta-package for krita and build from git source (1G repo + 500MB install, but you can place either of those anywhere).

BTW: This is all the kde stuff I have in my system (it could probably be less).

Code: Select all

kde-base/katepart-4.12.5
kde-base/kde-env-4.12.5
kde-base/kde-l10n-4.12.5
kde-base/kdelibs-4.12.5
kde-base/kdesu-4.12.5
kde-base/khelpcenter-4.12.5
kde-base/knewstuff-4.10.5
kde-base/libkdcraw-4.12.5
kde-base/oxygen-icons-4.12.5
sys-auth/polkit-kde-agent-0.99.0-r1


That is only counting kde named packages + another 10 for qt based packages. Not that much really. ( No kdebase-runtime, kdeedu-marble, kdegraphics-okular or kdepimlibs)

cheers!

@TheraHedwig, you are right my intention was not to be bossy rather just deliver my opinionated thoughts. As for bug reports, I have not submitted any, this is not because I haven't encountered any bugs but because I was having a hard time thinking up detailed reproduction steps and because I didn't understand "why" the problem was happening.

You are also right that I should definitely try to become a little more involved, being both a (wannabe ) artist and a programmer puts me in a rather unique position here, the sad part however is that in both of these areas I am rather lacking in experience, as for translation efforts, I could most certainly take some time one of these days and map out which things I think should be renamed, and what I think they should be renamed into then submit it to somewhere, I could also do an Icelandic translation effort although I think that is unimportant since people who speak the language are only like 350k, and most people in my generation have simply adapted to having computers and everything in them set to English (there are few things I hate more than when applications default to Icelandic language, because there is consistency in having everything in english, "settings or options" but when the program has been translated even if it is to a language I am familiar with, I don't know what exactly it was translated to. It confuses me greatly when it happens)

@slangkamp: thanks for your reply well being single threaded can certainly be a problem, but I am pretty sure even single threaded tasks should perform very well on my system since each thread is running at 3.4ghz to begin with. But in my experience I created a grid out of vectors, then added text here and there, it was in a reasonably high resolution (I don't remember but at most it would have been 4000x4000) and the whole thing lagged uncontrollably rasterizing the layers did help a little though. BUt I guess dragging objects around in krita is highly unoptimized to begin with (at least when I do it...)

I know performance is tricky, stability is not as tricky though, just insert try and catch everywhere ultimate crash preventation at least when I write something (but then again I have never written anything truly big, like krita) but krita is largely stable indeed, although I notice more crashes on linux than in windows, I can't tracet them though but usually it doesn't actually crash when I'm doing something important so all good.

@ghevan: Thats one of the reasons I'm on gentoo but nepomuk is disabled by default now (kde has some new thing, forgot what it's called, nepomuk has been deprecated basically, this is a good thing as I always hated it so it's safe your to remove the -nepomuk use flag now) theres also setting "CALLIGRA_FEATURES="krita"" to prevent the emerge of calligra to pull in the whole package. (Krita is considered part of the calligra package for gentoo as is, and on arch it's called "calligra-krita" this is a bit annoying) There's also the "-Os" CFLAG (instead of "-O2") which supposedly sets "optimize for size" on everything. I'm using gentoo because of how easy it is to optimize it for size, my install is 7GB currently, but I will be moving /usr/portage to another drive which will lower it to less than 5GB. (Basically portage is big because it holds on to all sources it's downloaded in "/usr/portage/" as well as some other stuff. But for my specific setup I not only needed Gentoo for it's size optimizations, but also for Portage's ability to apply user patches automatically on compilation (for some packages anyways) from "/etc/portage/patches/..." this way I can apply an ACS Override and VGA_ARB patches to the Kernel and Nvidia proprietary drivers everytime I update my system without any manual work. There's also a similar situation with my G510 keyboard, and when you have some super specific and elaborate setup in mind, Gentoo is usually the most efficient way to do it.

These are indeed not so many packages. I would very much like to see what use flags you had to keep it so minimal (even though on my end I just went with the flow and installed kdebase-meta, it can't hurt that badly to have a backup window manager if enlightenment fails takes a wrong turn somewhere)

As for the problems I was having and I mentioned in the post above, I knew my system wasn't completely properly set up yet and as it turned out direct rendering was unavailable for my user and opengl support was only up to 2.1 (my card supports 4.2 or 4.3) I just had to add myself to the video group to fix all that. Basically don't enable opengl and texture buffer if direct rendering is not available it is unsafe.

Putting try catch blocks everywhere in C++ certainly isn't going to help much, especially not in KDE applications which don't use exceptions usually.

Although you seem to have the exact opposite opinion, I believe Gentoo is the largest part of your problem. If you were using a regular binary package distribution, you'd just type <$package_manager> install krita and wait three minutes and not ever care about its dependencies again.

cestarian wrote:@slangkamp: thanks for your reply well being single threaded can certainly be a problem, but I am pretty sure even single threaded tasks should perform very well on my system since each thread is running at 3.4ghz to begin with. But in my experience I created a grid out of vectors, then added text here and there, it was in a reasonably high resolution (I don't remember but at most it would have been 4000x4000) and the whole thing lagged uncontrollably rasterizing the layers did help a little though. BUt I guess dragging objects around in krita is highly unoptimized to begin with (at least when I do it...)

In general it's the dragging something large is the worst case you can have because you need to redraw a lot of pixels. What happens is that we first draw with Qt into a temporary image that is then drawn onto the Krita layer. Then the the layer stack needs to be up composited into the final image which is then drawn on screen. That currently happens at the full resolution.

There are ways to fix this or at least work around it:
- use mipmapping. That what other applications like Photoshop do where they instead of using the full sized image draw onto a smaller image that as big as the image you see on the screen. Sounds easy, but implementing that is far more difficult than one might assume
- composite the image on the GPU. That's something we might do in the future, but it requires good graphics driver and a lot of graphics RAM.
- do a preview rendering outside the layer stack. That would preview the vector graphics on top of the image and only update the stack once the the user action is finished. That's easier to do, but it doesn't give you an accurate preview of what would happen.

cestarian wrote:I know performance is tricky, stability is not as tricky though, just insert try and catch everywhere ultimate crash preventation at least when I write something (but then again I have never written anything truly big, like krita) but krita is largely stable indeed, although I notice more crashes on linux than in windows, I can't tracet them though but usually it doesn't actually crash when I'm doing something important so all good.

The normal crash isn't caught by the usual try/catch. In most cases it's a segmentation fault that happens somewhere which is not an exception. There are ways to catch that too, but there isn't really a way to recover from that. If you got a segmentation fault it's likely safer to crash than working with something corrupted.

That said if you get regularly crashes that's more likely a problem with your system than something internally in Krita. Especially if it's not reproduceable.