Roadmap discussion for 2.9 and 3.0

[Boudewijn Rempt]

On Friday 21 February 2014 Feb 18:02:50 Sven Langkamp wrote:
> On Wed, Feb 19, 2014 at 11:04 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> 
> > Krita Roadmap
> > -------------
> >
> > 2.8 will be awesome, but after 2.8 comes 2.9...
> >
> > During the 2.8 beta phase, we've been lucky to have had a lot of input on
> > areas where Krita should be better. The main areas are:
> >
> > * MDI interface (more than one document loaded in one window)
> >
> 
> I would give this the top priority, because it's the single feature that
> has be merged before we go to 3.0 and will likely also need a lot of work.

Yes. Progress is good, though I am actually considering making the changes just for Krita. That would kind of fork komain for krita, but keeping all the applications running properly is just way too much work for me, and for very little return.

> > * Performance of the color correction system: the final conversion step
> > for display is now holding us back. We might be able to move that to the
> > GPU as well, for the OpenGL canvas
> >
> 
> Have you measured the impact of that? I have seen many comments about bad
> performance recently. Users expect fast painting with the biggest brush on
> a 10k x 10k image.

I haven't seen a lot of comments about performance, just one or two. But performance always should be better, and images are growing all the time... I did measure the impact of lcms2 on Windows, and according to vtune, it's about 90% of cpu time when painting on a 10k x 10k canvas with a big brush on a 16 bit integer image.

I haven't measured what happens when moving the color correction to a shader yet, but that is pretty similar to what the ocio docker does.

> > * Text and vector tools. We share these with Calligra. The current system
> > is a hybrid of ODT, ODG and SVG. Creating and manipulating text is
> > difficult, the difference between the two text tools is hard to explain,
> > and finally, the results aren't good and we cannot save all features the
> > gui offers.
> >
> 
> That's a very tricky problem. I know that the current system has a lot of
> shortcoming, but there is currently no good alternative for it. We have to
> keep backwards compatibility, so we can't throw it out.

I wouldn't actually care much about backward compatibility, as long as we can convert vector layers from odg to svg on loading, we should be fine.

> The problem with
> the text are more related to bugs in the text tools rather than the
> fileformat (the shadow problem is too). Even if we throw it out, it would
> take months to replace the text tools alone and years if you want to reach
> the capabilities of other applications.

For the text tool, I rather think that the current approach really is broken by design. The ODT format doesn't offer the kind of typographic control that our users need, while on the other hand, it offers a bunch of things nobody needs, down to integration with bibliography databases.

> In any case the text shapes and text tools would have to be replace, if you
> want to store as SVG we would likely need massive changes in Flake too. We
> have seriously question is that is really a justified change, considering
> how much effort would have to be dumped into it.

Flake already supports svg to a surprising extent though.

> *Unified shortcut confguration: Currently many users are confused that the
> shortcuts for the actions and the input manager shortcuts are split over
> two locations. These should be combined into a single UI. The same
> unification should be done for the done for saving shortcuts so everything
> is saved to shortcut profiles (which should be a resource).

Yes... And that probably needs to be done anyway after the MVC merge since the way I see it going now we'll manage shortcuts ourselves, separate from KDE.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl