"Linux Gazette...making Linux just a little more fun!"

   
Welcome to the Graphics Muse
Set your browser as wide as you'd like now.  I've fixed the Muse to expand to fill the aviailable space!
© 1998 by mjh 
 

Button Bar muse: 
  1. v; to become absorbed in thought 
  2. n; [ fr. Any of the nine sister goddesses of learning and the arts in Greek Mythology ]: a source of inspiration 
 Welcome to the Graphics Muse! Why a "muse"? Well, except for the sisters aspect, the above definitions are pretty much the way I'd describe my own interest in computer graphics: it keeps me deep in thought and it is a daily source of inspiration. 
[Graphics Mews][WebWonderings][Musings] [Resources]
 
This column is dedicated to the use, creation, distribution, and discussion of computer graphics tools for Linux systems.
 
Not much to say this month.  I've been very busy working on some things for Linux Journal and a few other projects.  I did manager to get the reviews done that I had promised last month.  Well, 2 out of 3 of them.  That's better than I usually do.

      In this months column I'll be covering the following:


 
Graphics Mews
      Disclaimer: Before I get too far into this I should note that any of the news items I post in this section are just that - news. Either I happened to run across them via some mailing list I was on, via some Usenet newsgroup, or via email from someone. I'm not necessarily endorsing these products (some of which may be commercial), I'm just letting you know I'd heard about them in the past month.
 
indent

XFPovray 1.3

Robert Mallozzi announces a new version (1.3) of his XForms interface to the ray tracer POV-Ray.  If you have ever used POV-Ray from the command line, you might find this program useful.  Check 

   http://cspar.uah.edu/~mallozzir/ 

Source code is available in tgz, bzip2, and rpm formats. 

Robert S. Mallozzi 
University of Alabama 
http://cspar.uah.edu/~mallozzir/

 indent

XMRM 2.0 (Alpha release)

The Institute of Computer Graphics at Vienna University of Technology, Austria, announce the release of XMRM 2.0alpha 

XMRM (multi resolution morphing for X) is an image morphing program written for XWindows. A special feature of this program, which is not found in other morphing packages, is the ability to control the morphing speed of details in relation to the morphing speed of big features. 

Check out the XMRM homepage: 
http://www.cg.tuwien.ac.at/research/ca/mrm/ 

For a few animated GIFs visit the Online manual: 
http://www.cg.tuwien.ac.at/~xmrm/ 

For download got to: 
ftp://ftp.cg.tuwien.ac.at/pub/linux/xmrm/ 

Greetings, The XMRM-Team <xmrm@cg.tuwien.ac.at> 
 

FREETYPE 1.0 The FREE TrueType Font Engine

Copyright (C) 1996-1998 The FreeType Development Team 

The FreeType engine is a free and portable TrueType font rendering engine, available in  ANSI C and Pascal source  code.  It has been developed to  provide TrueType support  to a great variety  of platforms and environments. 
 
Notice that  FreeType is a library.   It is not a font server for your  preferred environment, even though it  has been designed to  be the  basis of  many  high-level libraries,  tools and font servers. 

It's  a clean-room  implementation that  is not  derived  from the original  TrueType engine developed  by Apple  and Microsoft,  though it matches it  regarding rendering  quality.  To our  knowledge, it's the only royalty-free complete TrueType engine available. 

For more information, please visit the Freetype web site at: 
http://www.physiol.med.tu-muenchen.de  
/~robert/freetype.html 
 

 That's it.  Not much in the way of announcments this month.  I had a few more, but lost them pasting them into my XPostitPlus program.  That's the first time it's crashed in that manner - where I lost the data.  Bummer.
 

Did You Know?

...there is a OpenGL widget for GTK?  Take a look at ftp://ftp.gimp.org/pub/gtk/contrib/glgtk-demo.971104.tgz.

Q and A

Q:   How do you use anti-aliasing with POV-Ray?  Do higher values cause more anti-aliasing?

A:   Ron Parker responded on the IRTC-L discussion list:  Whenever POV-Ray detects a sufficient change, the threshold, in colour from one pixel to it's neighbour, it will calculate the in-between color pixels by shooting multiple rays into the scene, rather than just one, to determine the colour.  The higher the "+A" number is (from 0 to 1), the more rays will be shot into the scene, and the smaller a difference in colour from one pixel to the next will be needed to cause the anti-aliasing to be brought into effect.  Anti-aliasing is triggered when the threshold between two pixels is reached. The number of rays is controlled by +R, and the "spread" is controlled by +J.  Setting +A0.1 will trigger on smaller color differences than +A0.3, so it actually anti-aliases more than higher values of +A.  All this is the description for +AM=1.  Adaptive supersampling (+AM=2) works somewhat differently.

For more information, see section 6.2.5.4 of the POV documentation.

Ron Parker * parkerr@mail.fwi.com * http://www2.fwi.com/~parkerr

Q: I took an image to a printer today who requested that I bring back the image when I have increased the resolution from 72 pixels/inch to 300 pixels /inch. I cant locate how to do this with the GIMP. Any pointers?

A:   You can scale the image, but that will decrease the quality of the image. The best way to deal with images you plan to print is to plan to create them using the correct resolution.  For example, if you want an 8.5" by 11" image at 300pixels/inch:

So you need to start with an image window that is 2550x3300 and work from there.  Keep in mind - doing this sort of image manipulation (with such large image sizes) is better suited to:
  1. faster CPU's.
  2. tons of memory
  3. lots of disk space
As to "can I convert from 72 to 300 pixels from my original image": yes, use the scale option (image->scale) and set the correct size.  But remember - scaling up will reduce image quality, especially going from 72dpi to 300dpi.
 

Reader Mail

An unnamed reader sent the following information: 'Muse:  I really need to update the LGH and UGU pages.  Anyway, if any of my readers tries these scripts, let me know what you think of them.  I don't have any multiprocessor boxes, although I do have a network.  I just don't have time right now to experiment with these scripts.

Syd Logan, Senior Software Engineer @ NetManage, Inc., writes:

'Muse:  Thanks for the note.  While working for Xi Graphics I had read the XIE specification and wondered why it hadn't been used much.  Perhaps it's like X Input - it just needed a market to drive its use.  Well, the exposure Linux will give X Windows may be that driving force.  We'll have to wait and see.

Thomas Vaughan writes:

'Muse:  No free support, but Xi Graphics has recently announced ViRGE 3D support in their commercial Accelerated X server. 'Muse:  I don't really like the idea of GGI, partly because I don't think sticking the graphics driver in the kernel is a good idea but also because I don't want to see the desktop interface splintered into seperate camps.  X is just really coming into its own on the desktop and I'd like to see it continue. 'Muse:  I got a similar request from Anand Rangarajan: 'Muse:  Well, I thought it was about time I did a little survey of the various graphics card vendors.  See the X Server Update article below.

Marc S. Jensen writes to the GIMP User mailing list:

'Muse:  Assuming your scanner is the only deviced attached to your scsi card:
ln -s /dev/sga /dev/scanner

and you're all set.  If you have more than one device connected to the scsi bus (re: cable) then you'll need to figure out which one of the /dev/sg[x] devices maps to your scanner.  Then link that one to /dev/scanner.

Joel Becker also wrote to the GIMP User mailing list:

'Muse:  Can't answer about the tablet, but I just happened to install a scanner recently.  I bought a Adaptec 2940 SCSI card and a UMAX 1200S scanner.  The Adaptec dropped right in on my Pentium 200MMX board with no hardware config necessary.  The RH 4.2 distribution I use already had the necessary scsi module prebuilt in /lib/modules (the module name is aic7xxx.o).  I ran insmod aic7xxx and up it came.

The scanner I chose from the list of scanners I reviewed last year for my Graphics Muse column in the Linux Gazette.  I first tried a 610s, but it only worked in greyscale modes.  So I exchanged it for the more expensive (about $250) 1200s.  Works quite well with the Umax drivers.  Image quality is excellent.  I've been scanning hardware (twisted pair and thinnet cables), and my hand once, and the scans were quite good although very dark.  I just brightened them up with xv and the GIMP and all was well.

However, I haven't tried the scanner and drivers in conjunction with SANE.

Marco Iannacone wrote:

'Muse:  No problem. 'Muse:  Possibly, but that would only make a difference in screen updates.  The majority of the GIMP's processing is done before it updates the screen. 'Muse:  Define "slower"?  Slower loading the same file?  Slower in computing a new brightness or contrast?  Slower how?

What he might be talking about is the use of tiles, which may appear to update slowly, wherease in Photoshop they may all appear almost at once (I've never used Photoshop, so I don't know if this is true or not).  So before I can answer "is GIMP slower than Photoshop" I need to know by what means you've been measuring the two.

'Muse:  You may not have installed the proper image libraries.  Download the libgr package and install it, then try again.  You may want to build the GIMP from the sources, after you install the libraries in the libgr package.  Or, if you installed GIMP from one of the distributions (Red Hat, Debian, etc) you may want to verify you installed all the graphics libraries that came with that distribution too.

Tero Auvinen wrote:

'Muse:  If the link from Larry's page (the BMRT home page) is not working I'm not certain where this package can be found.  Try the Renderman Repository: http://rmr.spinne.com/. 'Muse:  No, there wasn't a third part.  I wanted to do one but I'm not that experienced with it and I had too many other things come up.  I've never had a chance to go back and revisit it. 'Muse:  No modellers are available for Linux which export RIB primitives.  All of the ones I know of export polygons only. 'Muse:  You couldn't pay me to run MS on anything.  But that's just me. 'Muse:  I think he's got some big boxes, SGI's and Sun's probably.  I'm sure Pixar feeds him well.  On Linux he may be using AC3D (as do I).  It's a pretty good modeller, but still exports everything as polygons only.  It does import 3DS and Lightwave files, though.  That's quite useful for using the canned models from the various model sites and CDs that are available.  AC3D - http://www.comp.lancs.ac.uk/computing/users/andy/ac3dlinux.html.

Marsel Osipov writes:

'Muse:  We can never have too many modellers.
 



XeoMenu 1.1

One of the problems with pages based around standard HTML constructs is the inability to easily modify navigation aides.  A navigation aid can be a set of text links, a set of images with individual links or it can be an image map using hot spots for links.  These tools allow readers of a page to move around a Web site easily.  Properly done, they can remove the linearity (the hierarchical structure) of a Web site and allow the reader to move freely between pages.

Adding an text links is fairly easy to do and updating them simply requires editing the HTML.  But text links lack pizazz.  Images used as text links are better, but aside from using JavaScript to do image rollovers, the images are fairly static.  They lack the feel of a real user interface.  Image maps are no better and, in fact, don't even allow rollover changes as easily making them even more static than individual images used as links.

Fortunately, issues such as this is part of why Java exists.  Java allows for more programmatic interfaces.  These interfaces can take on the more familiar menu-based interfaces that readers will be accustomed to.  Although it can be argued that such interfaces are not any better than static image maps, for the sake of this article we'll assume that menuing systems are a good thing.

XeoMenu is a simple Java program from Patrick Chan at Xeo (www.xeo.com) that overlays a menuing system over an image in a Web page.  The program is run as an applet and is used by embedding it within HTML source code.  Readers can retrieve a copy from http://java.sun.com:81/share/classes/menu/source/source.html.  Java source code is included, along with an example HTML file, sample images, a users manual (a sort of man page in HTML) and the compiled Java byte code.  There is also a second version of the code, called horizMenu, that permits menus to be layed out horizontally instead of vertically.  Since I can't seem to get Java working on my Red Hat 4.2 system (neither through the javac compiler nor through my version of Vibe - something about my CLASSPATH is not set up right I think), I won't be able to provide information on compiling the source in this article.  If I do get javac and/or Vibe working, I'll start talking about how to compile Java programs.  If anyone has a write up of what I need to do to get my stock RH 4.2 version of the Java compilers working, please drop me a line.

To use XeoMenu you need to first create an image that contains two parts:  The menu as it is displayed without the mouse over the image and the image as it would look if the mouse were over different parts of the original.  For our example, we'll use the following image:

The image is divided into 2 halves.  The left half is the image as it displays without the mouse over it.  The image is actually going to be subdivided into a top (Linux) and bottom (Gazette) section.  The right side, then, shows how each section will be displayed when the mouse is over that section.  For example, if the mouse is over the word Linux in the image then the blue Linux text will be displayed.  By default, the red colors (the left half of the image) is displayed.

Now, in order not to annoy readers without Java support, you need to move to the next section of this article, which will show how the Java application is used and what it looks like when it runs.  You will need a Java compatible browser to view this part of the article.



Summary

This was just a simple example.  XeoMenu itself comes with a more sophisticated example, but there is no real explanation (ie documentation) of what is going on in the code.  Hopefully, between that example, the user manual, and this article you'll be able to do something useful with XeoMenu.  The main applet page for  Java.sun.com shows an example of the horizontal version of XeoMenu running and it's quite slick.  Although the interface uses a fairly large number of optional parameters and the format for menu descriptions is less than ideal, it is still a useful tool that takes only a little getting used to in order to make a very usable menu-based interface for your Web pages.


 
Musings
 
 
 
 

X Server Update

   I've been doing this column now for over a year and writing for Linux Journal on and off for another year.   In that time I haven't really addressed one of the more obvious topics related to doing graphics on Linux - the X server.  Part of the reason for that is that I don't have the resources to test a bunch of different server configurations.  If I got paid to do this it would be a different story, but this column is born from whatever time and system resources I can spare each month. 

   Still, I get requests fairly often asking for information about what 3D video cards are supported under Linux and which ones support various hardware extensions such as the X Input Extension.  Most of the questions specifically ask "which are supported under XFree86".  But some readers ask about support in general, either free or commercial. 

   Well, I thought it was time I sent a query to the various vendors and find out where things stand.  The email I sent was fairly generic.  It read as follows: 
 

Do you have any information which I may use in my column related to your current or planned support for 3D hardware acceleration (specifically related to OpenGL/Mesa, but not necessarily so)?  What about support for alternative input devices via the X Input Extension.  The GIMP, and its X toolkit Gtk, both make use of X Input if available and I expect many other tools will do so as well in the near future.

This query was sent out around the 12th of this month to Xi Graphics, Metro Link, SuSE, and the XFree86 project.  I received responses from all 4, however Metro Link did not receive my query immediately and so their response came in too late for this article.  I will cover Metro Link's response next month.   Please note that this article is intended to list which servers support what features/devices and is not intended to explain how to use those features. 

The responses have been edited to remove what appeared to be editorial comments, where recognizable.  I will refrain from editorializing on these responses in this article as well. 

   The first reply was nearly immediate and came from Dirk H Hohndel at SuSE.  He sent two emails, one as the Vice President of The XFree86 Project, Inc. and one as the Lead Developer, S.u.S.E. GmbH.  Dirk wears both hats, and therefore his comments are considered official responses, one from each organization.  Both responses were direct and to the point.  First his XFree86 response: 
 

Well, XSuSE and XFree86 are mostly identical. As far as legally possible, all work done on XSuSE is integrated into the next XFree86 version. XFree86 in itself focuses on the X Window System and 2D support for the different cards. While they are not actively pursuing 3D support, they  are in contact with several groups working in that area. 

I do not speak for Metro Link, but I can tell you that Metro Link and XFree86 are in very positive cooperation on the 2D side of servers.  Metro Link donated lots of code to XFree86 recently, and Metro Link and XFree86 are working together on many aspects of the design of our future X servers. 
 
Because Dirk's response came quickly, and because responses from the other vendors provided more detailed information, I thought I should offere XFree86 a chance to expand their reply.  When asked to comment on architectural details and XFree86's relationship to the commercial vendors, Dirk responded: 
 
Why would I bore you or anyone else with architectural details that no one really cares about. 
 
He followed up his XFree86 reply with a response from SuSE: 
 
SuSE is working on hardware 3D support, but there is no release date for that, yet. 

The 2D drivers from SuSE are intended to be integrated into XFree86-4.0, but we are currently running into some legal problems with that for one of them (3DLabs GLINT), as some of the docs are under NDA and we have not been able to get the permission to release sources, yet. We are working on it, though.  All the other drivers from SuSE have already been included into XFree86-3.3.2

The other replies came from Xi Graphics.  Both Thomas Roell, President of Xi Graphics and technical architect for their servers, and Jeremy Chatfield responded. 

Thomas wrote: 
 

Our next generation X-Server will support additional new input devices for the XInputExtension. The extension itself is supported since Accelerated-X 4.1. Planned devices are mainly CAD oriented input systems, like Tablets, Touchscreens and Space-Balls.  As for Hardware 3D, you can bet that the next generation will have that.

Jeremy Chatfield followed up with the following (edited partially for length): 
 

Accelerated-X 4.1 supports the XInputExtension, using a small and fixed list of devices, with very limited device management.  Future releases will support a wider range of devices. 

We've been evolving Accelerated-X ever since 1994, to take advantage of 3D hardware acceleration.  Examples of the technology introductions and the reason for needing them for 3D support:

  • Memory allocation and buffer management.  3D uses a lot of memory.  Standard malloc() (as of 1994, when we started this work) did not permit programs to decrease in size, tended to thrash memory when freeing and sometimes when allocating, and exhibited other behaviors that were not suitable to long running processes with a mix of temporary and long term storage in a wide variety of data sizes.  We do things like lazy buffer allocation, only allocating stencil buffers when needed, and so on.  This improves speed and reduces system impact, seen in total Server size, and paging demand.
 
-Top of next column-
More Musings...  
  • VRWave 0.9

    • --
    • Coprocessor locking.  When using the host processor, graphics engine and 3D engine, all writing in the same memory areas, and when using both system memory (via AGP) and graphics board memory, fast and correct mutex locking is essential.  [Without locking] this will cause problems when all three processors (or more) attempt to handle the same memory.  We have continued to refine our mutex locking for several years, though this is not visible in any product other than multihead, at present. 
    • Asynchronous I/O  When X Servers with high levels of hardware acceleration are handling buffered drawing requests, keyboard and mouse input is put into the end of the queue.  This results in sluggish response, and in mouse and keyboard data being handled in bursts.  Mouse acceleration can be triggered inappropriately, so mouse motion becomes very hard to control, and sequential single button clicks can be misinterpreted as double clicks.  We introduced the "Velvet Mouse" mechanism to permit input even while the Server was in heavy rendering, as will be typical of 3D dynamic applications. 
    • Overlays.  Many 3D applications on workstations rely on the presence of overlays.  [Overlays] also benefit from the memory management and other architectural changes in Accelerated-X.
    Xi Graphics recently announce support for ViRGE 3D (see the February 1998 Graphics Muse). 

    Beyond these two vendors, there is also 3D hardware support available for Mesa for the following video hardware: 

    • 3Dfx Voodoo - Cards based on the 3Dfx Voodoo chipset (such as Diamond Monster 3D and Orchid - Righteous 3D) are supported under Linux and Windows 95. Look here for the latest info. This is the best supported 3-D hardware for Linux at this time. 
    • 3Dfx Voodoo Rush (rendering into window) - Supported under Windows. Linux support is underway. 
    • GLINT-based boards - Look here for the latest info. 
    • Cirrus Mondello - No longer supported- download Mesa 1.2.8 if you're interested in this driver. 
    This information was taken directly from the Mesa Web pages.  I ignored any cards for which Linux was not mentioned except the Cirrus Mondello.  I don't know if it's for Linux or Windows.  Also, I don't know exactly how Mesa makes use of this hardware without actually being part of the X server.  You will have to investigate the Mesa pages and its links for more information in that area. 

    So, now you should know as much as I do with respect to 3D and X Input support from XFree86/SuSE and Xi Graphics.  In summary, most of the 3D work seems to be planned and under development, but no word on when the support (at least for wide spread 3D support) will be available.  Neither XFree86/SuSE nor Xi specifically mentioned any 3D boards being supported, although Xi did have the announcement for the ViRGE 3D last month.  Xi stated they support the X Input Extension in their Accelerated-X 4.1 release.  Although XFree86 didn't mention it, I know that X Input is supported in their product as well.  Don't forget:  I'll be covering Metro Link's responses to my query next month. 

    I should mention again that I have worked for Xi Graphics in the past, and in fact worked with both Thomas and Jeremy at Dell computer and with Jeremy at Information Foundation (a USL source code licensee back around 1993 or so).  I have made every attempt to remove all editorial comments, both my own and any from the respondents, from this article.

    Contact Information

    XFree86: S.u.S.E.: Dirk reports:  In both cases we try to keep the web pages up to date and XFree86 has a FAQ online that contains workarounds for known bugs.

    Xi Graphics:

    Jeremy added:  We keep the web site up to date.
     
     
     
    Resources
    The following links are just starting points for finding more information about computer graphics and multimedia in general for Linux systems. If you have some application specific information for me, I'll add them to my other pages or you can contact the maintainer of some other web site. I'll consider adding other general references here, but application or site specific information needs to go into one of the following general references and not listed here.
     
    Linux Graphics mini-Howto 
    Unix Graphics Utilities 
    Linux Multimedia Page 

    Some of the Mailing Lists and Newsgroups I keep an eye on and where I get much of the information in this column: 

    The Gimp User and Gimp Developer Mailing Lists. 
    The IRTC-L discussion list 
    comp.graphics.rendering.raytracing 
    comp.graphics.rendering.renderman 
    comp.graphics.api.opengl 
    comp.os.linux.announce 

    Future Directions

    Next month:   Unknown.  I've got some prior obligations (paying ones, that is) that I absolutely must get done.  And soon.

    Let me know what you'd like to hear about!

    © 1998 Michael J. Hammel

    Previous ``Graphics Muse'' Columns

    Graphics Muse #1, November 1996
    Graphics Muse #2, December 1996
    Graphics Muse #3, January 1997
    Graphics Muse #4, February 1997
    Graphics Muse #5, March 1997
    Graphics Muse #6, April 1997
    Graphics Muse #7, May 1997
    Graphics Muse #8, June 1997
    Graphics Muse #9, July 1997
    Graphics Muse #10, August 1997
    Graphics Muse #11, October 1997
    Graphics Muse #12, December 1997
    Graphics Muse #13, February 1998

    Copyright © 1998, Michael J. Hammel
    Published in Issue 26 of Linux Gazette, March 1998

    [ TABLE OF CONTENTS ] [ FRONT PAGE ] Back Next