Re: OPENGL and 2.23.04

From: Rene Brun (Rene.Brun@cern.ch)
Date: Fri Oct 22 1999 - 14:39:07 MEST


Hi Stefano,

Stefano Bettelli wrote:
> 
> This is a list of remarks which I accumulated in the last two weeks.
> 
> -> A few words on OPENGL support in version 2.23.04:
> 
>         1) The GL.C macro never comes with the standard distribution;
>         I had it once from a roottalk post and I never changed it, but I
>         think it should be provided along with the distribution,
>         maybe with a different name (GL.C.example) and some documentation
>         lines into it. I never found a note in the installation notes
>         which spoke about this script.

Thanks for reporting this missing file in the Linux6.0 distribution.
I have now fixed the problem.
The GL.C file missing (to be copied into $ROOTSYS/macros/GL.C is:

{
   gSystem.Load("/usr/X11R6/lib/libXmu.so");
   gSystem.Load("$OPENGL/lib/libMesaGL.so");
   gSystem.Load("$OPENGL/lib/libMesaGLU.so");
   gSystem.Load("$ROOTSYS/lib/libRGL.so");
}

> 
>         2) The installation notes don't explain very well how to setup
>         ROOT for a compilation with OPENGL. Keep in mind that most Linux
>         boxes use the Mesa library which puts its libraries and header
>         files in standard places; therefore the correct sequence is:
>                 > cd $ROOTSYS
>                 > mkdir opengl
>                 > cd opengl
>                 > ln -s /usr/include include
>                 > ln -s /usr/lib lib
>         insted of: (stated in AA_INSTALL)
>                 > cd $ROOTSYS
>                 > ln -s <pathname>/Mesa-2.2 opengl (Mesa 2.2 or higher)

Here, I disagree. The procedure as described in AA_INSTALL is correct.
Your Mesa directory should contain an include directory.

> 
>         3) I have found that in the new release, if a pad is not editable,
>         then you cannot use OPENGL functions (I mean you can open the
>         view window, but you can't rotate, zoom, go to wireframe mode ...).
>         Moreover, it is the current pad (i.e. the pad with the current
>         focus) which must be not editable, and not the pad from which the
>         OPENGL view originates. If, after having spawned the view, you click
>         onto a non-editable pad, you lock the view. This is very annoying
>         if you have, say, two pads, one with pictures and one with buttons.
>         If the action graphic_pad->x3d("OPENGL") is issued by pushing a
>         button in the former pad (which AFAIK must be not-editable), then,
>         whatever pad you cd in the action, after the view is spawned the
>         control goes back to the button pad and the view is locked.
>         Luckily for me I use a script with a global TTimer, so I can
>         circumvent the problem, but I think it is not that good to lock
>         also the OPENGL view for non-editable pads.

I will investigate this problem, thanks for mentionning the problem.
> 
> -> The compilation stage goes smooth after Fons suggested to patch
>         2.23.04's $ROOTSYS/src/Make-macros line:
>         "$(SOFLAGS)" libX3d.$(SOEXT) $@ "$(X3DO)" into
>         "$(SOFLAGS)" libX3d.$(SOEXT) $@ "$(X3DO) $(X3DDO)"
>         so I think you can add change RedHat 6.0 into RedHat 6.0/6.1
>         in the availability page. The only thing which I can't get
>         working is "true type fonts" which didn't work from the very
>         beginning of my ROOT experience.
> 

This was already fixed.

> -> About the benckmark I provided: I made some investigation about my hard
>         disk (FUJITSU MPC3102AT E, ATA DISK) and I found that the benchmark
>         could be far from truth (so, maybe better if you remove it).
>         -> the disk should be 10.2 Gb but it is recognized as 9.6 Gb
>         -> the driver reports 0Kb for cache, although the specs say 256Kb.
>            but I found a post in a newsgroup stating that these disk
>            actually lie about their cache (the cache is there, but they
>            state it has zero size).
>         -> benchmarking disk-writes with "hdparm -tT" I found a transfer
>            rate of 6-7Mb/s; after playing with hdparm parameters I could
>            achieve 10-11Mb/s and the ROOTMARKS went up from 133 to >150.
>            specs anyway say that the disk transfer rate should be 12-19Mb/s !!!

OK, I will remove your benchmark. After all, that is where benchmarks
are useful !
You must have a serious problem with your Compaq Deskpro EP
A Pentium III 450Mhz system with 64 Mb of memory. Even the CPU
performance
looks very bad (much inferior to my Pentium II 400 Mhz)

Rene Brun



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:41 MET