Kritia 4.0 Released, Conversation With The Team
Another high-quality article from Alexandre Prokoudine <http://libregraphicsworld.org/blog/entry/krita-4-0-interview> about the just-released major revamp of Krita. It now straddles both “paint” and “draw” worlds, with Inkscape-styled SVG-based vector functionality added to the older paint functions. Oh, and it does animations as well. The item links to the “official” release video, but another informative one worth checking out is this <https://www.youtube.com/watch?v=OXvHHJUyBDg>.
Another high-quality article from Alexandre Prokoudine
<http://libregraphicsworld.org/blog/entry/krita-4-0-interview> about the just-released major revamp of Krita. It now straddles both “paint” and “draw” worlds, with Inkscape-styled SVG-based vector functionality added to the older paint functions. Oh, and it does animations as well.
The item links to the “official” release video, but another informative one worth checking out is this <https://www.youtube.com/watch?v=OXvHHJUyBDg>.
...and scripting via Python. ;-) " Why did you pick Python for scripting and not Lua (which is thread-safe)? Boudewijn: Because pretty much the entire VFX world uses Python, and because I wrote a book about Python in 2000 :-). And... Well... There is no safety in threads." Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/
On Mon, 26 Mar 2018 14:30:38 +1300, Peter Reutemann wrote:
...and scripting via Python. ;-)
I had a quick look at the APIs for that. I was hoping for something DOMish, like you get with Blender. But while there is a bit of that, much of it seems to rely on directly exposing PyQT and expecting you to make calls into that layer.
"Why did you pick Python for scripting and not Lua (which is thread-safe)? Boudewijn: Because pretty much the entire VFX world uses Python, and because I wrote a book about Python in 2000 :-). And... Well... There is no safety in threads."
I posted a comment on the article about that. Quite a few people are keen to make Python (specifically, CPython) more “thread-friendly”. An inescapable part of this is getting rid of the infamous “Global Interpreter Lock” (which prevents multiple Python threads within a process from using CPU at the same time), which in turn means doing away with reference-counting and moving towards a pure garbage-collection model, like you get with Java. But that means also adopting Java’s requirement that you actively manage the heap allocation that you give to a program, rather than simply leaving the program to allocate as much (or as little) as it needs, as at present. Multithreading is something you avoid unless you absolutely have to use it. The main need for it is when your code is CPU-bound.
participants (2)
-
Lawrence D'Oliveiro -
Peter Reutemann