The Quick Start Guide to the GIMP, Part 1
As with nearly all X applications, the GIMP supports the ability to run on one machine and display on another. Most X applications accept, through the Xt toolkit, the -display command-line option to specify a remote host to display on. The GIMP accepts a similar command except that two dashes are required. Somewhere in the evolution of Linux there was a migration from one to two dashes for command-line options. I'm sure there is a valid reason for it—I just never figured out what it was. In any case, the command-line option for displaying on a remote system is:
--display <remote host>:<display number>.<screen>
For most users, the display number and screen will both be 0 (zero).
The GIMP has been ported to many of the well known Unix platforms, including Solaris, SGI, FreeBSD and, of course, Linux. The software is not hardware specific since it makes use of the low-level X11 interface provided by Xlib (GIMP's toolkit, gtk+, does not rely on either the Xt toolkit or Motif). This allows the X server to handle the actual screen drawing and lets the GIMP provide the computational work of the display. Consequently, the GIMP works with all of the well known X servers for Linux (MetroLink, Xi Graphics and XFree86). As with any high-end graphics tool, you'll have better results with the high-end graphics adapters. I use a Matrox Mystique at 1152x900 with 4MB of video memory that allows up to 16 million colors. Be sure to check the server documentation or vendor's marketing material to find out if the video adapter you use is supported.
One extension to the X Window Protocols that many X servers support is the MIT Shared Memory Extension. This extension provides a method for an X application to make use of the shared memory resources of the operating system without having to go through the Xlib interprocess communication channel. For this reason, the processing of large images by the low-level X routines can be done much faster. The GIMP makes use of this feature to help provide speed enhancements. Unfortunately, not all X servers provide support for this extension. If it appears the GIMP is not behaving well, you can try starting it with the --no-xshm command-line option to disable the use of the MIT Shared Memory Extension. One common scenario which often needs this option is when a user starts the GIMP on one machine but has it display across the Net on another system.
Note that all three of the major X server vendors (MetroLink, Xi Graphics and the XFree86 Project) currently provide servers for Linux that support this extension. However, older versions of these servers may not. Some of the popular (but older) X terminals from NCD also do not support this extension. To find out if your server has this support, type:
xdpyinfo | grep MIT-SHM
If this command prints out “MIT-SHM”, your server supports the extension. If it doesn't, you need to use the --no-xshm option. On the Xi Graphics AcceleratedX 3.1 server running with a Matrox Mystique video card, the shared memory extension appeared to function incorrectly and the GIMP had to be run without the use of the X shared-memory support. A small number of other cards had similar problems with this server. If you have few problems other than the windows which display images are being redrawn incorrectly (they appear to have overlapping tiles, for example), you should consider running with the X shared-memory option disabled. Note that Xi Graphics is currently working to resolve this problem, and the problem does not exist for all cards supported by their X server.
The GIMP uses a tile-based memory management system so that extremely large images can be worked on without exhausting physical memory. Even so, work like this benefits tremendously from additional system memory. I recommend you have at least 16MB of system memory to do simple web page graphics. If you intend to get into print media you'll be working on much larger images, with X/Y dimensions of 2000x2000 or more. In these cases you need at least 64MB of memory and probably more.
CPU speed is also important for doing high-end graphics work. You can use the GIMP on any Linux-based hardware platform, but you may get frustrated waiting for some pixel operations to complete on older systems. For example, operations like blurring, mosaics or adding sparkles to regions of images can be very CPU intensive. I used a 486/66DX2 (i.e., a speed doubled 486-33MHz) system with the original release of the GIMP well over a year ago. The new version benefits a great deal from the added power of the Cyrix P166 (133MHz) system I currently use. The equation for computer graphics is simple: faster CPU + more memory = reduced frustration.
The GIMP does not at the time of this writing have direct support for scanners, tablets or pen devices. Work is currently underway on a generic scanner interface (called SANE) which includes a plug-in for use with the GIMP. This plug-in is not part of the base distribution at this time. I expect that scanner support will be much more extensive for the GIMP by the time this article reaches the newsstand.
Support for Wacom tablets is also in the works. A number of contributors have the Wacom ArtZ working with XFree86, and a couple of individual projects were started to integrate the tablets with the GIMP using the X Input Extension. Recently (in June 1997), these projects began to merge. Again, by the time this article reaches the newsstand, this support should be much more extensive. It is interesting to note that Wacom is a commercial supporter of the XFree86 project. At the time of this writing based on information from their web sites, neither the MetroLink nor Xi Graphics X servers appear to support Wacom tablets.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Android is Linux -- why no better inter-operation
1 hour 40 min ago
- Connecting Android device to desktop Linux via USB
2 hours 8 min ago
- Find new cell phone and tablet pc
3 hours 6 min ago
4 hours 35 min ago
- Automatically updating Guest Additions
5 hours 44 min ago
- I like your topic on android
6 hours 30 min ago
- Reply to comment | Linux Journal
6 hours 51 min ago
- This is the easiest tutorial
13 hours 6 min ago
- Ahh, the Koolaid.
18 hours 44 min ago
- git-annex assistant
1 day 44 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?