faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Oh what joy
by Simon Edwards on Monday 20/Sep/2004, @03:45
|
Boudewijn, could you take a guess as to how much of code you write for Krita is CPU-bound pixel pushing vs GUI stuff? I'm guessing that 70% - 80% of the code is GUI stuff and not speed critical. (At least that is what I noticed the last time I wrote a graphics application in the early 90s, in 680x0(!!) assembler. oh the joy of being young and having too much spare time. :-) )
What did you think of the idea of writing the canvas/image/document/pixel-pushing class in C++ and the rest of the code on top using Python? What made you not go that route? just curious.
cheers,
--
Simon |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Oh what joy
by Boudewijn Rempt on Monday 20/Sep/2004, @04:05
|
I'm not sure of the actual ratio... Let's take a look. Krita is, according to sloccount about 50.000 lines of actual code.
The UI subdir is 5000 lines -- these are the special widgets, dialogs and so on. Stuff that would be easy to do in Python.
The tools subdir is 4079 lines. A nasty mix of ui code and event handling. The event handling is critical: we handle way more events per mouse movement than an ordinary app, in order to draw an accurate line. That wouldn't be doable in Python.
The plugins subdir is 2971 lines. A mixture of plugin admin code (which wouldn't be needed in Python, UI code, and finally code to filter pixels.
The modules subdir contains the color models, complete with code to composite pixels. This is 1918 lines, and it is too slow as it is in C++. We might need to use some mmx/sse/altivec assembly from the Gimp here.
The core is 18.577 lines. This includes a lot of code that simply ties slots to signals in the main view, but also all the data handling, which is complex and performance sensitive for an application that pretends to do more than wrap QImage. Much of it is also infrastructure definition: factories for paint operations, resources, tools -- some of it would not be needed in this form if we were using a language that has a class object. The main view class and the main document class could be done in Python, and perhaps the resource loading. But the image import/export/loading/saving, the painting is very critical.
In the end, I think that doing the interface in Python would not make much difference, because it isn't the largest part of the code in terms of work needed to get going. Coding a Qt interface is not much more work to do in C++ than in Python. It's data structures and application logic that are not performance critical where Python shines. After all, when you've used Qt Designer, most of the interface work is already done.
Not that I did have a choice: Krita is by now five years old, and I merely picked up the threads were they'd fallen to the ground. I never contemplated doing a complete redesign, especially not since that would place Krita outside KOffice.
The paint application I tried to do in Python before I discovered Krita could be worked on was completely in Python. I found that Python was too slow and memory-hungry for the pixel-pushing part, and just when I had resigned myself to doing that bit as a core C++ library, I found Krita, and never did it. Otherwise it might have been a mixture of gcj-compiled Java and interpreted Jython code all using qtjava.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
