|
Marble gets "temperature" and "precipitation" maps, and a "stars" plugin. More work on "fuzzy searches" in Digikam. Konqueror gets support for crash session recovery and session management. Runners can now be managed using a KPluginSelector-based dialog, and attention-blinking support in Plasma. Various Plasma applets move around KDE SVN before the KDE 4.1 feature freeze takes effect, with WebKit applet support moving into kdebase. SVG stuff from WebKit starts to be integrated into KHTML. More optimisations in KHTML, with KJS/Frostbyte, a version using bytecode and other enhancements, moving back into kdelibs. Start of an implemention of the JavaScript scripting API for PDF documents in Okular, based on KJS. Continued work on KJots integration into Kontact, and creating/editing links between entries in KJots. More work on theming in Amarok 2. Various improvements in kvpnc. More configuration user interfaces in KNetworkManager. Enhancements in the KTorrent bandwidth scheduler plugin. Support for CUPS printing options in KDE printing dialogs. Mailody moves to kdereview. The "OnlineSync" plugin is merged into Akregator. Initial commit of a new MSWord-to-ODF filter for KWord, and a caligraphy tool for Karbon. KDevMon is ported to KDE 4. Development of the Shaman2 package manager is moved into KDE SVN (playground/sysadmin). The PHP-Qt bindings move from playground/bindings to the kdebindings module. KDE 4.1 Beta 1 is tagged for release.
|
Bart Coppens writes about the next-generation tile system recently introduced to Krita:
|
First, some background. For about as long as there has been a "modern" Krita, it has always had a "tiled backend". This means that the raw image data of its paint devices (layers, etc) was chunked into squares of 64x64 pixels. That meant that instead of always needing to have all image data in memory, we have had the ability to only keep the most recently used pieces of image in the memory, while swapping older data into swapfiles.
For example, if we are drawing in a big picture, we typically change only a small piece of the image at a time. Most parts aren't changed at all, and can be swapped to disk without much of a cost.
Another example is undo data. If you start painting, we need to store information about past image states. Usually this information will not be needed anymore by the user, but we have to store it for the unexpected case where it *will* be needed. This information can just as well be stored in disk, instead of sitting in the memory.
Reducing the memory footprint is extremely important, especially on machines with less RAM: if we would not manually swap out our data, other applications of the user might be swapped out, which is usually undesirable.
Now, our specific implementation of paint devices led to some interesting advantages over other applications like The GIMP. Unfortunately for us (and luckily for The GIMP), our tile backend was good enough to get along with, so we didn't innovate as much anymore. However, with GEGL picking up a lot of steam lately, this means that we are starting to miss out on some very cool features that the GIMP will have (or even has already). To ensure that Krita is also able to do those things, I've been slowly reworking our old backend code into a more flexible design (as far as the other API allows for that, of course).
One of the major issues I have worked on up to an initial stage is trying to make the tiles backend somewhat more robust in a multi-threaded environment. Our old code was pretty ugly in that regard. The code regarding tile management was safeguarded by a single big lock (called the "Big Krita Lock" ;-)). After the rewrite, I'm hoping that more parts will be more usable in a multi-threaded context. Some work still remains to be done, but I'm hopeful that with the new code, it should be a lot easier to implement the required changes than with the Krita 1.6 framework (famous last words!).
Another new feature that is already implemented is the introduction of shared tiles. This means that multiple paint devices can have a single source of tiles in memory (a sort of implicit copying of tiles). We already had a rudimentary approach for a single kind of tile: the "default" tile. That meant that if a paint device was read at a place where the corresponding tile wasn't yet created, it used a single tile as a "source" for all those empty spots.
Unfortunately that approach wasn't scalable enough to be used throughout Krita. The rewritten code takes care of that, and we should be able to have several whole paint devices share the exact same tile data.
The feature I've been playing with most recently, is the ability to load the content of paint devices directly from image files. The old (and current) way of loading an image file is to read in the image, and copy all data into a paint device (or multiple devices in case of multiple layers). This unfortunately means that you have the same data available twice: all data for the layer is already present in source image, and then we load it into Krita (and then swap it out again) anyway.
Giving paint devices the ability to get their data directly from a file thus means that we cut out this middle step. In the long run, this should give an improvement in memory/swap usage of *big* image files. Of course, this implies a penalty because you have to decode part of the image each time you want to access some tile data. We'll just have to find out at which point it will be in our favor to use this approach.
Currently this functionality is merely implemented at the backend level, so Krita just has some nice code that abstracts most ugly things away from the file format people. I've ensured myself that the backend works (at least decently) by writing a unit test that fakes loading an image from a file directly. I'm guessing that in time, other Krita developers who have greater affinity with the image loading code will try to implement the code needed to load specific image formats.
The most interesting surprise while developing all this, is that my new code unintentionally detects some new Krita memory leaks :-). At Krita shutdown, the new code has much more stringent consistency checks, including one that complains if it thinks it's leaking tile data (which it did!). Much to my surprise, if I enabled the check, it got triggered by some different places in Krita that appeared to leak memory at exit.
As for the future, I'm hoping to iron out all the bugs, of course ;-). Obviously, I'd like to see more features, and one of them that I've been wanting to implement for more than a year is a MipMap for the paint devices at the tile-level. It's something that GEGL and The GIMP already have, and I think that Krita would also benefit from it. Basically, the idea is that you efficiently pre-"render" some scaled-down versions of your image, so that you become a lot faster when zooming out.
Another thing that would be very cool is sharing of a single paint device across applications. This would be quite interesting for collaborative painting applications. GEGL already has some support for this (this was demonstrated at Libre Graphics Meeting 2008 very recently), and I'm hoping that Krita will join the club. My work towards loading tiles directly from "disk" should be generic enough to also easily allow files to be loaded from the network and so on. I'm guessing that the hardest part there would be handling the synchronization issues, etc (but without trying an implementation, I don't know for sure).
There are of course lots of other things on the todo-list, but they are more small implementational details (like using QAtomicInt now that it is available for real through Qt 4.4). That's it for now!
Note: People wanting to try out this code will have to manually enable it at compile time. Just change the USE_OLD_TILESYSTEM value in krita/image/CMakteLists.txt. Be aware that most changes are not visual, and that there remain some known issues with the code!
|
|
Percy Camilo Triveño Aucahuasi talks about taking over maintainership of KColorEdit:
|
I'm the current maintainer of KColorEdit. Artur Rataj was the former maintainer but he asked me to work on this project. The following things are finished:
- Ported the old version to KDE 4
- Now it uses the Model/View design to list colors
- Added new features, like moving items
- Improved the load dialog
- Fixed all the bugs from the previous version
All of these things were discussed in my communication with Artur, and so he has been my guide up until now. I always sent Artur screenshots and reports of the current status of KColorEdit, and he gave me his opinion about the progress of development.
My goal is to create a fun and useful application to edit and create color palettes.
The problems that this application solve are basically the creation and editing of color palettes. While there are many tools that can do this, they are often non-Free software. There is Agave from GNOME which tries to assist in the same tasks. Many image editors like Krita, GIMP, and Kolourpaint have embedded widgets/dialogs to manage the color palette, but with KColorEdit this task is performed in a better way, and all of these image editors can import the files that KColorEdit creates.
With the current state of KColorEdit, you can perform all the things of the previous version and more, like adding comments to your palette, moving the items, adding a name to your palette, view a description of your palette, manage 2 views of your palette, and so on.
In the near future, I want to ensure KColorEdit has the same features of many tools that perform the creation of palettes. Also, I will continue to report the status to Artur.
In a technical way, here are the things that KColorEdit should do in the future:
- Select a color from an image, the desktop, and from a gradient
- Show the colors with many schemes, like complementary colors (the complement of the current color)
- Add many colors to the palette in a "line", meaning that if I define a line in some colorspace then the application automatically adds all the colors that follow this line (with a delta).
I'm not sure if you are familiar this feature, but let me say that it could be very useful. - Generate a "presentation" of the palette, you can define how to view the palette (aside from default views)
- And finally, add the undo/redo feature with the Memento pattern, but I think that KDE 4 has its own implementation of this pattern.
I have been working in this application for about five months, so of course I have more technical comments:- This application would be more easy to maintain (and also I think other apps) if we had a common API to represent color selection, for instance the color selector of KColorDialog is an embedded widget, it would help more if this "selector widget" was someting like a KColorSelector class in the API, the same with the color selector of Krita (i'm talking about the triangle color selector that looks similar to the GTK color selector), this would be for instance named KGtkColorSelector.
In short we should define a common interface for color selectors. I had to cut code of KColorDialog and KOffice to use those implementations (of course I respect the credits). - There isn't a "KColor" class that wraps QColor, but there are so much actions that this class could do, like get the luminance of the color, or convert between colorspaces, etc. I think that there is a class named "KColor", but it is in the playground module, and so I can't used.
- KColorCollection doesn't have support for comments, only for one description.
- It would be great if all palette stuff had a model/view design, KColorCells (possible view) and KColorCollection (possible model) do not follow this concept.
From my experience, I don't see the point of the application KColorChooser, as KColorEdit can replace the duplicated functionality between the two. I have already sent an email to the kde-core-devel list about this topic, but have unfortunately received no feedback yet from my proposal.
 |
|
|
Lots of people killing lots of bugs this week, which is nice to see (with summer approaching!).
|
|
![[*]](/images/standard/features.png)
![[*]](/images/standard/optimise.png)
![[*]](/images/standard/other.png)
![[*]](/images/standard/bugfixes.png)