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.
| [reply] |
Thanks for this very good primer on the underlying concepts of 2D-image processing, Jost. It is much appreciated!
| [reply] |
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. | [reply] |
That makes things much clearer for me, mr_mischief. Thanks so much for closing this gap in my understanding.
As for libraries, I have to admit I am not completely familiar with the concept. My understanding is that they are units of code with well defined interfaces that perform certain complex actions. Is it helpful to think of them as Perl objects which get created by my Perl programme via suitable constructors and subsequently addressed via appropriate methods or subroutines? Or are they actual programmes started by my Perl programme that run in parallel to it and then interact with it at runtime?
Thanks again in advance for clarifying.
Pat
| [reply] |
Primarily libraries are the former -- units of code you call from your code as part of the same program. Many but not all of them use an object interface with modules, while others use subroutine calls.
See perlmod for information on Perl modules, which is how most libraries for use in Perl are presented. See perlboot for a beginner's guide to object-oriented Perl. There's plenty to learn here on PM, too. You can search for different topics that have already been discussed or post questions specific to a module to SoPW.
| [reply] |