go to www.geomview.org home page
 
Home

Overview
FAQ
Documentation

Download

Mailing List

Geomview For Windows?

Support
Users
Development

Bug Reporting
Contributing
Contact Us

Sponsors

 

Site Search

 

Advanced
Search

 
About the software@geom archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Closed REQ 5246]: X-geomview 1.5.0 visual support


  • To: software@geom
  • Subject: Re: [Closed REQ 5246]: X-geomview 1.5.0 visual support
  • From: "Tim Rowley" <trowley>
  • Date: Fri, 24 Feb 95 10:21:54 CST

> I tested the changes with mgexample.  It looks like geomview does
> it's own x11 setup, so that would still need to be changed to get
> geomview working.

Yes, the 1.5.0 release has separate checks for appropriate
visuals.  We've now folded them into a single function located in
src/lib/mg/x11/mgx11visual.c.  It checks for 24 bit TrueColor, 16
bit TrueColor, 8 bit PseudoColor, and 1 bit visuals, in that
order.

Your patches used XImages and XPutPixel instead of doing it by
hand.  While your method is more portable, I think the slowdown
would be considerable.  I took the approach of creating
mgx11render16.c, which is the 24 bit code modified to work on 16
bit chunks.  This won't handle 8 bit TrueColor visuals, but I
think these are rare -- I've only seen them on servers that also
support 8 bit PsuedoColor visuals.

Unfortunately, this solution creates yet another maintenance
headache.  The files mgbufrender24.c, mgx11render16.c,
mgx11render8.c, and mgx11render1.c all have slightly differing
versions a set of ~10 functions.  Every time a bug is fixed in
one, we have to remember to fix it in the rest.  I'm trying to
come with a elegant way of folding them together without
sacrificing speed.

We're pleased with the quality of the 16 bit rendering.  On a
486-66/Mach32 with 565 pixel weighting, Geomview runs smoothly
and shows only slight banding when using smooth shading.  If you
want to experiment with this version, you can obtain a Linux
binary from "ftp://ftp.geom.umn.edu/priv/trowley/gvx.gz".  This
is a compressed drop-in replacement for the gvx in
$GEOM/bin/$MACHTYPE/gvx.  It was compiled from the development
source tree, so it's not fully optimized and may have unexpected
features (ie. bugs).

>   Are there any plans to convert geomview to C++.  Seems like
> geomview is naturally suited to an OO approach.  If so, would you
> start with Fresco, some other existing widget hierarchy, or start
> from scratch?

I'm not aware of any plans to rewrite Geomview at this point.  If
it were to be rewritten, I would guess that the language chosen
would not be C++, as many people here believe that C++ is not
truly object oriented.  Many of them think that Objective-C is a
better solution to this problem.  When the geomview project began
back in 1991, C++ compilers weren't widely available or stable.
I believe that back then there wasn't even a draft standard for
the language out.  Even today, the ANSI committee is still
sitting around sticking pins through a Bjarne Stroustrup doll.

I don't know much about Fresco besides that it came out with
X11R6 and needs gcc 2.6 or later to compile.  Developing with it
would be inconvenient, as the Geometry Center currently runs a
mix of R4, R5, and R6 (R4 on Irix4, R5 on Irix5/SunOS/HP, and R6
on Linux).  If you're referring to the user interface, tk/tcl has
become popular at the center because of the easy learning curve,
speedy development, and a simple interface to C.  It also has the
advantage of being portable to MS Windows and Mac when Sun
releases their ports.  We've experimented with tk/tcl on Windows
NT and have been quite pleased.  A new user interface could be
added without much difficulty, as most of geomview is the OOGL
libs and common code.

- Tim


-- 
Tim Rowley  --  trowley at geom.umn.edu  --  "Do or do not, there is no try."


 
Home | Overview | FAQ | Documentation | Support | Download | Mailing List
Windows? | Development | Bug Reporting | Contributing | Contact Us | Sponsors
 
site hosted by
SourceForge Logo