home contents changes options help

by Robin Rowe 9/26/04

CinePaint has not made as much progress as hoped in the first three quarters of 2004. This is not for lack of great code contributions by developers, but due to lack of administration and QA resources. In other words, programmers are sending the project patches faster than they can be integrated, tested, and released. This document describes why that happened and what is being done about it.

A number of challenges emerged that slowed progress

Solutions being implemented

Goals for the rest of 2004

If this plan succeeds these programs will be released by the end of the year

How this impacts other CinePaint developers

If you're working on the core we should discuss how your changes will migrate to the new architecture. If you're working in other code areas you can continue to develop for the 0.19-gtk1 architecture.


Tom Huffman's Questions -- Sun, 26 Sep 2004 15:29:34 -0700 reply
<< Was reading on the Wiki about the img_img architechture you're working on. It seems it will completely change the core cinepaint code, not a bad thing. >>


<< How massive of a change is this? >>

It's massive change, but hopefully not massive breakage. ;-)

<< Does Cinepaint become a UI on top of img_img, or are they more closely related? >>

Neither. The img_img server (that is, img_server) will run as an independent process. The relationship between CinePaint and img_server is client-server, more like Mozilla and Apache.

<< Is this the beginning of a complete rewrite moving over to fltk as you've talked recently, or is the old gtk version of cinepaint likely to be backported to work with img_img? >>

The beginning. Seems unlikely the GTK version would be backported.

<< In the end I'm wondering how much effort is it worth putting into the current core of CinePaint? >>

For work on the core you should coordinate with me so that your pieces will fit into img_img. Much of what is the legacy core now will be outside CinePaint in the new architecture. The img_server will handle allocating image memory, reading images from files, and writing them out.

We haven't pulled the plug on CinePaint on GTK development. That's going forward in parallel until the FLTK version is solid enough to migrate to.

Robin Rowe

Joshua Boyd's Questions -- Sun, 26 Sep 2004 23:49:00 -0700 reply
<< How does eliminating tiles affect memory usage? >>

The legacy GIMP architecture is 64x64 pixel tiles. Traversing tiles add lots of complexity to the internals of CinePaint. Whether tiles or framebuffer, it's about the same amount of memory. The exception of course is for users who are so memory-constrained that they engage the swap-to-file feature of the legacy tile manager. What we should do for such swap users who could be on very old machines (e.g., Pentium II) or PDAs (e.g., the Sharp Zaurus) is undecided.

<< Also, what is to prevent img_img from becoming a sinkhole like GEGL appears to be? >>

A design goal of img_img is simplicity. It allocates image memory, reads files, writes files, and deallocates image memory. Because it's flat instead of tiled the architecture is simple compared to GIMP's design. GEGL seems much more complex than the legacy GIMP tile system. Probably no one outside the GEGL development team understands the GEGL design.

<< Finally, is it reasonable for plug-in developers to start using FLTK? >>

Something better than FLTK or GTK is coming for plug-ins.

The plug-in GUI has always been a cause of trouble. It takes so much GTK code to do anything. That and dealing with tiles make it hard to code plug-ins. A new plug-in GUI architecture is coming to enable plug-in developers to write GUI elements as metadata strings. For example, a string of "Quality: 1.0-100.0" would specify possible JPEG compression quality settings. The plug-in developer will provide Get and Set functions such as, img_Set("Quality: 75"). Whether the settings dialog is displayed by CinePaint using GTK or FLTK will not be the plug-in author's concern. Separating the GUI from the plug-ins is required to support server-based batch processing using plug-ins. Currently there's no way an automated script could set parameters on a plug-in because it would need to go through dialogs.

Robin Rowe

... -- Mon, 22 Nov 2004 00:44:01 -0800 reply
Every time I try and make a color adjustment the program crashes. Do you have any advice? Have other people complained about this particular problem?


Memory managemeny and img_img -- Thu, 25 Nov 2004 05:30:00 -0800 reply

Will it be possible to implement various memory management strategies with img_img (scanline based, tile based, or flat file) which will be abstracted away by the API?

The idea of GEGL is to have a standard API for accessing raster data, with at least one data representation implementation behind (tile-based for compatibility with existing GIMP structures). It may well be easy to add a second for flat data representation.

How will img_img perform with biggish (say >4000x3000px) images when the whole lot is in memory at the same time? Will CinePaint continue to be able to run on machines with less than 1GB of memory?


Linux Debuggin? -- Thu, 02 Dec 2004 13:39:18 -0800 reply
What about the use of Sun Studio to debug and/or develop on Linux? There's also Intel's C++ Compiler though I don't know if it comes wit h an IDE, though I think Borland has an IDE to plug to it. I've not used these tools myself, but at least you should be aware there are alternatives to GCC and GDB.

Johann Oskarsson

ddd and emacs -- Sat, 22 Jan 2005 19:09:35 -0800 reply
The fancy debugger for Linux is ddd. It even draws out diagrams with arrows to show how your structs are connected by pointers.

The other tools would be gdb via emacs. The two go together; you have to live the emacs life. Edit in emacs, compile from within emacs, and then debug from within emacs. It'll let you jump around in the source code as you'd expect from a normal debugger.

whwn did lucy lu start hollywood -- Tue, 17 May 2005 11:56:29 -0700 reply