The least I can say is that the warp tool is in better shape than the cage tool the same time last year. The reason is simple, I learned a lot last year, and the warp tool need similar skills, and even reuse some part of the code.

That said, here is the report:

• All the tool’s infrastructure is here and functional.
• We can apply stroke and deform the canvas.
• 7 behaviors are supported for now:
  • moving pixels
  • growing an area
  • shrinking an area
  • swirl clockwise
  • swirl counter-clockwise
  • erasing a transformation
  • local smooth of a transformation
• Actions on the canvas are done with a round brush, with a gaussian like influence curve.
• Tool’s options are strength, size and hardness.

A quick screencast:

Each actions on the canvas are implemented as a Gegl operation that produce a relative coordinate buffer, that is inserted in the render graph. The final image is computed with a map-relative render operation.

This is what still need to be handled:

• Performances need enhancement. For now, for each stroke on the canvas, each operation already computed are re-rendered (cache does not work correctly), and this for the complete surface of the selection (the legagy code wasn’t designed for that). Other areas for improvement exist, such as the implementation of copy on write (COW) for GeglBuffer. The ultimate goal is to perform actions interactively.
• A good tweaking is needed. For now, behaviors are not consistent.
• UI implementation, as specified by Peter Sikking and his team.
• Undo implementation.

As I’m more confident this year, I’m going a bit deeper and I work on related things, especially in Gegl. An interresting thing is that the warp tool is structurally close than a paint core, and is therefore a step closer to a paint core based on Gegl in Gimp.

That’s it ! This summer again, i will participate to the Summer of Code program !

My last year’s contribution was for me a huge challenge, a way to learn a LOT of things, to meet and work with some very interesting people, and a big source of pride (even for my family, here we can see how much Google’s name mean something for the society nowadays).

This year, I’ll use the  knowledge I learned last year to rewrite the old plugin iWarp as a real internal Gimp tool. His pretty name will be the Gimp Warp Tool). That’s a feature that has been asked and waited for long. Here again, this tool will fit in the ‘big picture’, the future of Gimp (Gegl, live on-canvas preview, ..).

On a more personal note, it’s clear that my task this year is less challenging than last year (another deformation tool, structure relatively close..), and it’s kind of too bad. Nevertheless, it’s always great to work on a big project like Gimp, and users return it well most of the time. And hey, it’s cool to have his brain working during the summer =)

This time, I should be able to do the job right the first time (as opposition to the cage tool, that was kind of a prototype at the end of the summer), and avoid the 3 or 4 partial rewrite that was needed after the deadline. With a bit of luck, this tool can be included in Gimp 2.8. The start of the coding period is in fact not so far !

Expect news !

It’s been a while since i didn’t post update here. There even was months without any change, especially when I got the idea to write a small ERP suitable to a Junior-Enterprise. I spend somes hours on it today, and I feeled like it was time for a small changelog:

• as stated before, a rewrite of the UI management as a state machine, with a lot of cleaning (and some regression, I have to say ..)
• use of a custom data structure, that allow …
• the multi-selection of the cage’s handle, with a rubber band, to allow quicker editing of the cage, or simply moving the whole cage at once
• the possibility to go back to the edit mode, to tweak the source cage
• some optimisation in the Gegl operator that run the transformation

There is still some bugs to catch, the more obvious is that the  image shift from the cage after a return in edit mode. But promess is made, it will be ready for the Gimp 2.8 release ! By the way, further work in the cage tool will be done in the master branch of Gimp, ne need to checkout a particilar branch.

To celebrate all this, I made a quick screencast with a lizard as the victim. Enjoy =)

A quick note however, the first 2 years of hacking is not on the video since the related logs are not available on git.

This video was made using Gource, pretty cool software =)

Clang, which use LLVM infrastructure, is a compiler for the C language family. His goal is to offer a moder alternative to GCC. With Clang come a pretty cool static analyser. Here is how to use it for Gimp.

A small disclaimer before, I shamefully copied and adapted the procedure given by Campbell Barton, form the Blender team. (http://wiki.blender.org/index.php/User:Ideasman42/BlenderClang).

Step 1: compile LLVM/Clang

I first tried the LLVM provided by ArchLinux, but the compilation ended with a fatal error. It goes flawlessly with the development version. To fetch it, Campbell Barton’s script works well.

Step 2: configure Gimp’s compilation

First, we need to add  LLVM’s binary to the PATH:

The only difference with a classic GCC compilation, is that we explicitly ask to use Clang’s compiler:

Step 3: compile

If you just want to compile, the procedure doesn’t change.

If you want to run a static analyse, you have to use scan-build:

Just be aware that a static analyse will take a lot of time (3h40 with my Core 2 Duo E4500).

Etape 4: profit !

The static analyzer of Clang will probably find a lot of bug in the code. Yes, there is false positive, but it’s globally remarkably well done ! You can find here the result of the analyse of master i did today: http://pellelatarte.fr/dawa/gimp-llvm/

Hi,

A quick post to let you know that i started a refactoring of the Gimp cage tool. It’s a mandatory step to achieve a good quality and a solid basis to implement new things. It happens here by rewriting the frontend code as a state machine (as described here a few days ago), change on the data structure, documentation, and a lot of small fixes and simplifications.

In the future, a multi-points selection should come in a few days in the soc-2010-cage-2 branch. This editing mode will work in a similar way as in the path tool.

A proportional editing mode, similar to what you can find in Blender should come too.

Maybe i’ll start to getting satisfied of my work someday… =)

That’s it ! For now 48h, the new Cage tool in on master branch of Gimp ! It will be, unless big surprise, in the next release, the 2.8 !

A big thanks to my mentor, Alexia Death, and Michael Natterer (Mitch) to take care of this merge, and for the cleaning step that come with.

Somebody did a quick review of my cage-based deformation tool for The Gimp and published it in a Gimp community website. It’s on GimpUser.com !

A video of the tool in action is included !

It’s so cool to see that peoples like my work and find it usefull =)

Also, Devv, big thanks for the review and the video !

I really need to find some times to fine tune and clean all this (UI and optimization, mainly) …

Memory allocation with Glib:

memory allocation for objects:

simple allocation:

Hacking Gimp

gobject and glib debug

GTK event debug

autogen.sh

compilation without optimisation

quick install of binaries only

Gobject

gobject is evil.

if you have a warning relative to glib or gobject, try make install

something wrong ? Try make install

Babl

setup a format

convert buffer with a Babl fish

Gegl

create a buffer

buffer leak

Git

push in a remote branch

keep branch up-to-date

To stay in the present, here is the state of things. My tool is in majority done. I mean that the core works well, and it’s usable for a classic utilisation. There is still some teething problem to correct (for instance, it doesn’t works on mask), love to give to UI, and it will be ready for code review and inclusion in master branch of Gimp. At least I hope =)