GD, GD::Simple and Image::Magick will let you work with graphics files and save them. Then you'll need something to display those files.

Tk, The GIMP (perhaps with Gimp::Fu managing it), a browser, Prima (particularly Prima::Image perhaps), wxWidgets (with Wx, or something could take care of the display.

Some of those graphics loaders and GUI toolkits let you draw point by point in them, too. See Prima::Drawable and Tk::Canvas.

You can also tie into SDL and OpenGL (perhaps OpenGL::Simple). Those will give you even more graphics control than you're probably looking to use. You can even use SDL n conjunction with OpenGL or WxWidgets in conjunction with OpenGL.

There are Gtk and Qt, which are the graphics toolkits for Gnome and KDE.

Perhaps you're looking for something like Graphics::Simple, which is much like what some languages close to the metal of their platforms used to handle. It's marked as alpha and uses GTK or Postscript back ends.

You don't really say whether you want to show the drawing in progress on the screen or to show the result. Some of these options only really fit well into the completed image work flow. Others work well with updating the graphics on screen as you add or change elements. SDL, OpenGL, Tk, Prima, Gtk, Qt, and Graphics::Simple seem to be among those.

Portability is another issue. Tk, SDL, OpenGL, Qt, and Gtk can be used on most platforms but require the relevant libraries to be there. Prima is an option in Perl, but the others have bindings for other languages.

Your main issue here is that Perl is widget/toolkit/canvas ambivalent. The dialect of Basic you mentioned was tied tightly to the nature of the computer that drew the pixels for it. Once you pick a way to display your pixels, your application will be tied to some library unless you go the extra mile to make a handle of them interchangeable back ends. (That would be a neat trick, and many people would appreciate a module that wrapped Qt, Gtk, Prima, Tk, and SDL's graphics with a unified API. I doubt you're interested in doing that much work on it, though).

Good list. Of all of them, GD is probably the easiest to get started with, the easiest to install and the documentation is quite good (though many of the others are more powerful and/or have better image quality).

I would like to add a plug for Cairo: it has excellent image quality and can export to all kinds of file formats (and to Gnome/Gtk widgets, if you have Gtk2 installed).

"What should it profit a man, if he should win a flame war, yet lose his cool?"

mr_mischief - Thanks for your comprehensive post which outlines a whole spectrum of options!

Can I just ask a newbie question: How exactly does Perl handle the display of graphics? As far as I understand, essentially, I have a Perl programme determine the position, size and colour of a pixel. And then? What exactly is a canvas? Is it a separate programme with an API? ... Sorry, I am just new to this whole area.

Thanks again and cheers -

Pat

Perl itself has no concept of pixels or screens. All it can do is call on libraries that manage displays or abstractions of displays. Most current operating systems will also not allow direct access to the display anyway - usually a program requests a window, which may be a MS Windows type window with title bar, menu etc, or may take up the whole available screen as a drawable map of pixels.

For many applications it's more useful to have the more abstract notion of a canvas, which usually means an area on which you can place a combination of vector (lines, curves, circles, polygons etc) and possibly bitmap primitives with varying levels op transparency, height (IOW place one primitive on top of another), rotations, scaling, translations and so on and let the canvas deal with rendering all those primitives to the screen/window or to some file format (and some file formats like postscript, pdf and svg can store the primitives directly, which is very useful for printing, since you can get a more or less unlimited resolution out of vector primitives)

And this is all just 2D imaging. 3D rendering libraries can be a lot more complex. :-) See OpenGL.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Basically, Perl doesn't do graphics directly. In order to do so, it would need to be tied to the specifics of the host device. The language itself is more than sufficient to hold and manipulate the data structures involved, although in some complicated cases it might be a little slow.

What is needed is a way to get the shape and color data (or pixel data) into hardware for it to be rendered. That's where these libraries come in.

GD, ImageMagick, and Cairo take instructions about shapes, colors, lines, and such and put out graphics formats other systems already understand. They are libraries that are used by your application (C/C++ libraries with Perl wrappers in this case).

Tk, Gtk, Qt, SDL, WxWidgets, and OpenGL are APIs for external libraries that are built to actually draw into the windows on various OSes. They each allow you to write to their API and they write to the Windows, X11, Cocoa, or whatever API on the actual OS and device. Each of them is a separate API apart from the others on the list except that a couple of them can use OpenGL as an intermediate back end. All of them AFAIK work on Windows and OS X as well as Linux, Irix, and Solaris. Tk, Gtk, Gtk2, Qt, and WxWidgets are "graphical toolkits". They're made for bringing applications to GUIs without having to write all the windowing code and such. SDL and OpenGL are more general graphics things. There are implementations of those for framebuffer devices and for windowed GUIs (I think Qt has a framebuffer backend for embedded devices, too).

In order to just write to the pixels being shown, you'd have to have fairly direct (driver level or lower) access to the video subsystem. In a protected, multi-user OS that's a bad idea. That's why these libraries exist, aside from also making many things easier and more uniform than everyone reinventing their own wheels with incompatible hubs and tires. On a sufficiently single-user system with a smallish single-user OS, one could write to video memory or to the framebuffer device provided by the OS directly still today. The trick is finding such a device.

You will find however, that pixel plotting (single pixels) is VERY intensive, so you really want to use some sort of lines( actually curves, a line is just a straight curve :-))

You also might like to look at Tk Patio/Office layout designer for circles, polygons, etc. that are draggable.

Here is a sample of styles.

I recall doing the same thing as you: drawing, say, a bunch of diagonal lines on a screen using BASIC, and people coming up to me and going, "Whoa! What's that?" But that was in 1978 or so. :) These days, most people don't plot stuff like that on the console - although you still can, if you want to, at least in Linux (that's what the 'svga' library is for.) Assuming that you are running Linux, and want to do this with Perl, you could use Linux::Svgalib:

# From the module docs
use Linux::Svgalib;

my $svga = Linux::Svgalib->new();
$svga->init();
$svga->setmode(G640x480x16);

# Set the color for the subsequent ops
$svga->setcolor($color);
# Place a pixel
$svga->drawpixel($x, $y);
# Draw a line
$svga->drawline($x1, $y1, $x2, $y2);

# ...and so on; see the other methods in the documentation

$svga->setmode(TEXT);
[download]

This may be as close as you'll get to the old BASIC experience. :)

Update: Linux::Svgalib doesn't compile on my system (an error in the XS portion, which I'm too lazy to troubleshoot); however, vga seems to compile just fine, and appears (per the docs) to handle the same functions.

-- 
Human history becomes more and more a race between education and catastrophe. -- HG Wells

oko1 -

Thanks for your input ... and the shared bit of history which sounds similar to what I recall (even if my memory only takes me back as far as the late 80s ;-).
Must try the library you suggest on my Linux machine. From the code snippets you provide I suspect this may be close to what I was looking for.
Thanks again!

Cheers -

Pat

Thanks, John -

I was hoping to draw points, lines, circles and maybe some other geometric shapes in different locations on my screen. Essentially, the decisions on which shape is to be drawn where will depend on the individual use case and should not be of importance to the module recommendation requested here. The graphics thus produced will be the product of individual pixel decisions and do not need to be scalable (hence vector graphics may not be what I am looking for).

Thanks again for your input!

Best regards -

Pat

I'd echo SDL for the nearest thing to old-school BASIC graphics from perl.

And - to be a little heretical - I'd say that the closest+easiest thing today is javascript in a browser which supports the 'canvas' HTML element (e.g. firefox).

That allows you to run in an interactive way, use moveto/lineto as you may be used to and also easily allows you to share your fun with other people (since you can serve the javascript from a static HTML file hosted somewhere.

Hi, jbert -

This sounds very interesting. How exactly do you do this?

Thanks for your post!

Pat

You need to be able to:

• Write a basic html page
• Add javascript to the page
• Add a 'canvas' element to the page
• Start writing javascript to draw on the canvas.

As noted in the canvas link above, you'll need a browser which supports canvas (e.g. firefox). You can just open the .html file in the browser and you should see your code running. If you put your HTML and javascript on a web host somewhere, other people can see it too.

Have fun :-)

More recently, I just wrote Perl to output SVG, then rendered using inkscape and converted to PDF.

--John

SVG has been mentioned, so I will just throw in this suggestion to keep things interesting: PostScript.

I'm not aware of any modules that can help you produce PostScript, but it's not really that hard to use if you are prepared to do a little reading - there are plenty of tutorials online.

What I like about PostScript (and SVG) is that it is not a binary format - just plain text commands.