Options and Futures    Paint

Paint tool

I miss a free good paint tool for X-Windows. I'm currently using xpaint, which annoys me by (a) being too simple, (b) being too buggy, and (c) simply terminating when it runs out of memory.

Editor writers, if your program runs out of memory, give the user a chance to save the files. This has been a public service announcement. Thank you.

Perhaps the lack of a free industrial-strength paint tool is that writing a paint tool, like the interest in visual programming, is a rite of passage for beginning programmers; a simple paint tool seems to be conceptually easy to program and to design. A good paint tool quickly turns into a product.


The first problem everybody seems to be having with paint tools is integrating geometry and pixel-oriented graphics. What I would like to try is an approach similar to that regular graphic artists use when they airbrush: cut the shape out of a foil and then use the brush in the shape. That way, you get both clear lines and intuitive artistic control. The mask that one works through is editable just like a regular drawing; one can use masks to make masks...

Plus, I get to steal from Xerox for the interfaces; they have some experience with transparent tools, some of that should carry to transparent documents.

(The equivalent of masking in 3D is texturizing. Paul Haeberli has a paper about that.)


Usually, paint tools let me draw shapes by specifying points through which a curve is fit, or by specifying points that are simply connected. Depending on which mode I choose, I get a wobbly cloud or a star. What I really want to do is have one shape where I can, for each point, specify whether this is a corner (like for a star) or just a point to lay a spline through.


When I "draw" a pixel, I apply a function, from all planes to all planes. For example, drawing a pink line on one plane means copying pixels from the pink plane to the line plane. The function absolutely needs to be programmable. I don't know yet how to make this both fast and understandable, but it needs to be. What is displayed on screen, of course, is also the result of applying a function.

Perhaps have a graph of planes. At the nodes of the graph, functions determine the output planes (above) from the input planes (below). The functions are mathematical: if the input doesn't change, the output doesn't change either. (Give optimization a chance.) The graph is displayed, browse- and editable. Viewing something on a screen is a function in a node; it outputs a screen. If you add stuff above the screen, you simply don't see it. By moving the screen around in the graph, you can look at different aspects of the drawing.

Are there interaction primitives (like "drag-and-drop") for moving things around in graphs? There are directories, but those are kind of limited. I wonder what being able to quickly manipulate graphs would feel like...


Pens are a function that maps the input coordinates of the user's pointing device to invocations of the drawing function. Those are the real first function. The usual pixel-toggling drawing function then determines a shape (e.g., a line) and applies the drawing function to the shape. Others might draw parametrized geometry (a square, a circle with a certain diameter.) Again others might apply their own, more complicated functions parametrized with time, e.g. to simulate the movement of a brush.


A spraycan injects color into the image. That color absolutely needs to be mixed into the colors that are already there - the sprinkling of colored pixels that is frequently used to implement the spraycan is totally useless.

Parametrizable images

Transparency is a special case of parametrizable images. One needs to support transparency, of course, and one needs to support alpha factors, but what I would really like to do is support arbitrary parametrizable images - have a paint program that outputs, if necessary, a function rather than a fixed image.

I think one needs to look for larger-than-element parameters in many things, not just in painted images. Take fonts, for example; ``handwritten'' fonts should be composed from the individual letters parametrized by the larger rhythm of the line, with the strokes of the previous character, perhaps even with the frequency of the word in the text.

Help lines

Another thing that would fall naturally out of the mask idea is the possibility to have auxiliary elements - perspective lines, geometric constructions, etc. - that are not part of the finished picture, but that can be visible on screen. Since that, too, would be just another plane, it can be edited like any other part of the picture.

Foreign environments

Editing 24-bit color images on an 8-bit screen, or color images on a black and white screen, is not fun, but it should be possible. The 24-bit/8-bit problem could be solved by having a color table fish-eye view - the currently focused area is displayed with accurate color values, while the remainder gets dithered into the allocated colors.

Screen appearance

The image elements of the interface need to be editable, in particular their color. Editing a dark grey on dark blue picture in front of a bright blue frame is painful. I would see more if the contrast wouldn't distract me.

The beta channel

Three RGB values a 8 bit each fill 24 bits; what to do with the remaining 8 in an 32-bit word? The alpha channel says how transparent the current color is, and already makes for some neat tricks. How about using only 5 bits for the alpha channel and allocating the remaining 3 to a beta channel that specifies the diameter, in pixels, of the area used to calculate the pixel value? That would be a way of creating "blurry" transparent areas...