Menu
▾
▴
gnuplot-beta
|
From: V. <gae...@en...> - 2005-05-12 00:22:51
|
http://www.eleves.ens.fr/home/varoquau/gnuplot/ Here is the first draft of the povray terminal driver. It is fully 2D, wright now. A lot of work remains to be done but I am going away for two weeks; Among the big piece of work to do is the font handling and enhanced text bit. I have added RGb color support a few days ago have have ever since lost color. On the web page, there are also demo examples that have both the povray terminal driver and the png one, for comparision. My "pov-webifye is probably bugged, and that explaines the must bizarres bugs. Have a look at it, enjoy, tell me how to improve it or finish it... I continue working on it only in two weeks times. -- Ga=EBl PS it is currently quite late in France and I am falling asleep in front of my computer, so please excuse this very poorly written post. |
|
From: V. <gae...@no...> - 2005-08-18 18:33:21
|
I had a look a compiling the povray terminal driver and it does not
compile on my box (debian sarge, or ubuntu hoary). I think this is
because I have freeglut, and not openglut. Talking to some people who
know more about glut than I do (not that hard), it seems that freeglut
is more common (and it will be much easier to find on windows, for
instance).
However... If I understand the problem correctly free/open glut is
required rather than plain glut because plain glut cannot start a
separate thread. Starting a separate process and pipping instructions to
it could be a possible workaround (like what has been done for X11), but
it seems ugly. I am right on these points ?
On the other hand, compiling gnuplot with opengl requires to link it
with free/open/" " glut. If the libraries are not statically linked in
opengl will not work. What I am not sure about is how a dynamically
linked gnuplot binary will behave if the opengl library it relies on is
not on the system ? Can it work at all. If not that would be a great
impediment on a wide distribution of gnuplot opengl : it would require
to build your own version of gnuplot, or to install a separate gnuplot.
What if we have a gnuplot_glut binary, and that gnuplot accepts to
"set term opengl" and to start this gnuplot_opengl binary only if it can
work ? That would remove the library dependancy problem.
In the light of this reasoning (maybe totally flawed, as I cannot
claim that I understand those problems) it seems to me that we could
stick with standard glut and avoid problems.
--
Ga=EBl
|
|
From: Robert H. <en...@no...> - 2005-08-18 20:10:38
|
Have you confused the povray terminal and the opengl terminal?
I thought the povray terminal just dumped a povray file that you could
later render in povray?
Anyway the issue with the glut library is as follows:
The "standard" glut, i.e. the one distributed by SGI and in common usage
on many platforms, is written under the assumption that your program
registers a number of event handlers and then pass control over to glut.
This is a limitation that makes it hard to add glut based opengl on to
existing programs, or programs where another toolkit is used for another
part of the interface.
freeglut (and I thought openglut) work around this problem by allowing you
to do a single pass through the glut event loop and then regain
control. This makes it very easy to do glut based opengl in existing
applications.
When I wrote the opengl terminal driver I used freeglut, which is the
default glut on Debian, without even realising I was doing anything
non-standard.
The choice is:
a) create a gnuplot_opengl (similar to the X11
terminal)
b) require an "enhanced" glut
c) Use raw OpenGL (without any glut)
d) multi-threaded
Personally I am in favour of the second option. Freeglut is
standard/available in Debian, Ubuntu, and (as I understand
it) Fedora/Red-hat.
Rob
--
______ _____ ______ _______ ______ _______
|_____/ | | |_____] |______ |_____/ |
| \_ |_____| |_____] |______ | \_ |
_ _ _______ ______ _______
|_____| |_____| |_____/ |
| | | | | \_ |
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
|
From: V. <gae...@no...> - 2005-08-18 20:28:55
|
On Thu, Aug 18, 2005 at 09:09:11PM +0100, Robert Hart wrote:
> Have you confused the povray terminal and the opengl terminal?
A, yes, in the title, though, not in my head. :->
> I thought the povray terminal just dumped a povray file that you could
> later render in povray?
Yes, sorry for the confusion.
> When I wrote the opengl terminal driver I used freeglut, which is the
> default glut on Debian, without even realising I was doing anything
> non-standard.
Hum, weird then that I can't compile it. I'll look at that after my
holidays.
> The choice is:=20
> a) create a gnuplot_opengl (similar to the X11
> terminal)
> b) require an "enhanced" glut
> c) Use raw OpenGL (without any glut)
> d) multi-threaded
> Personally I am in favour of the second option. Freeglut is
> standard/available in Debian, Ubuntu, and (as I understand
> it) Fedora/Red-hat.
How about my objection about library dependancies, if it makes any
sense ?
--
Ga=EBl
|
|
From: Robert H. <en...@no...> - 2005-08-19 09:36:31
|
On Thu, 2005-08-18 at 22:28 +0200, Ga=EBl Varoquaux wrote: > How about my objection about library dependancies, if it makes any > sense ? I understand your objection, and I have tried to think of simple ways to make it work with the more standard glut. Although it would be nice to run out of the box with whatever glut happens to be installed, I think the extra complexity of having to deal with writing a whole separate program and piping the terminal information back and forth, would seriously outweigh the advantages of the slightly wider audience. I think the availability/portability of freeglut is sufficient that a large portion of people who want to try it will be able to, and until it actually does something that the x11 interface doesn't it wont be a major loss for anybody who can't. --=20 Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Robert H. <en...@no...> - 2005-08-19 09:42:54
|
On Thu, 2005-08-18 at 13:48 -0700, Ethan Merritt wrote: > On Thursday 18 August 2005 01:28 pm, Ga=EBl Varoquaux wrote: > >=20 > > > Personally I am in favour of the second option. Freeglut is > > > standard/available in Debian, Ubuntu, and (as I understand > > > it) Fedora/Red-hat. > >=20 > > How about my objection about library dependancies, if it makes any > > sense ? >=20 > I don't think there is a 100% solution to this problem. > Sadly, freeglut and other glut implementations are not perfectly > compatible. If you try transferring a binary linked against, > say X.org glut, to a machine that has nVidia drivers and glut libs > you are likely to crash the application, X11 itself, and possibly > the whole machine. [As I have learned the hard way]. hmm. I can't say I've had any problems myself. I'm not sure how many of the opengl apps I have use glut, but certainly things like upgrading from Xfree86 to X.org haven't caused me any issues. Anything that crashes X11 is a bug in the server. Rob --=20 Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-19 15:56:47
|
On Friday 19 August 2005 02:42 am, Robert Hart wrote: > On Thu, 2005-08-18 at 13:48 -0700, Ethan Merritt wrote: > > > > I don't think there is a 100% solution to this problem. > > Sadly, freeglut and other glut implementations are not perfectly > > compatible. If you try transferring a binary linked against, > > say X.org glut, to a machine that has nVidia drivers and glut libs > > you are likely to crash the application, X11 itself, and possibly > > the whole machine. [As I have learned the hard way]. > > hmm. I can't say I've had any problems myself. I'm not sure how many of > the opengl apps I have use glut, but certainly things like upgrading > from Xfree86 to X.org haven't caused me any issues. > > Anything that crashes X11 is a bug in the server. Normally that is true, but when the program (X11 in this case) writes directly into hardware and system memory, as the DRI extension does, then no. If you (the glut library) send incompatible commands, you may corrupt the system/hardware itself. The poor guy in the middle (the X server) is an innocent/unwilling accomplice who does not have perfect knowledge of what you sent or what effect it will have on the hardware. Besides which, "your X-server has a bug" is not a very helpful explanation to people who just want to run the program. The header files for the various glut implementations are not compatible. Is it any wonder that binaries built from those headers are not compatible? I very much fear that an OpenGL driver will remain a compile-it-yourself option under linux. My work involves a lot of computer graphics and 3D interactive visualization tools. Non-portability of OpenGL code is a continuing headache, and hits many of the standard libraries and toolkits we use (or would like to use). -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Robert H. <en...@no...> - 2005-08-19 21:21:12
|
On Fri, 2005-08-19 at 08:56 -0700, Ethan Merritt wrote: > Normally that is true, but when the program (X11 in this case) > writes directly into hardware and system memory, as the DRI extension > does, then no. If you (the glut library) send incompatible commands, > you may corrupt the system/hardware itself. The poor guy in the middle > (the X server) is an innocent/unwilling accomplice who does not have > perfect knowledge of what you sent or what effect it will have on the > hardware. Fair enough. I'm not doubting what you say, I was just wondering if there was something more going on. As I understood it, GLUT, is just a set of utility functions built on top of openGL and X11 (or whatever) and doesn't in itself do any direct messing with anything. But I don't really have much experience in this matter. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: V. <gae...@no...> - 2005-08-28 14:15:58
|
On Fri, Aug 19, 2005 at 08:56:32AM -0700, Ethan Merritt wrote:
> I very much fear that an OpenGL driver will remain a compile-it-yoursel=
f
> option under linux.=20
Quite possibly, but I must point out Blender works very well and
isn't "compile-it yourself".
That said, I can't add much to the discussion as I don't know
anything about the problem.
--
Ga=EBl
|
|
From: Petr M. <mi...@ph...> - 2005-05-27 09:30:22
|
> http://www.eleves.ens.fr/home/varoquau/gnuplot/ > > Have a look at it, enjoy, tell me how to improve it or finish it... I > continue working on it only in two weeks times. Looks interesting. Please add support for 'set palette maxcolors". --- PM |
|
From: KITA T. <t-...@cc...> - 2005-05-29 15:12:26
|
From: Ga=EBl Varoquaux <gae...@en...> Subject: Povray terminal driver Date: Thu, 12 May 2005 02:22:32 +0200 > http://www.eleves.ens.fr/home/varoquau/gnuplot/ > = > Here is the first draft of the povray terminal driver. It is fully = 2D, > wright now. A lot of work remains to be done but I am going away for = two > weeks; Among the big piece of work to do is the font handling and > enhanced text bit. I have added RGb color support a few days ago have= > have ever since lost color. # Long time since I put the povrml patch. # Spring is the busiest season for university teachers in Japan. It is a good starting point for me and for the project to fit the 3D terminals to the gnuplot core, I believe. # Thank you for leaving my name in the code, though my code does not se= ems to # be of much help to you. To all who joined the discussion started from my patch posted 2 month a= go: Thank you very much. I read all the comments posted but I have no time to understand and to think how to reply to each referring the codes so far. I would like to continue revise my dirty patch considering all of your comments and suggestions. I also expect a new 3D terminal API/framework in the gnuplot core. Excuse me for the impolite response like this, but maybe better than no= thing. # The OpenGL terminal seems another interesting one, though I have not = yet # tried to build it. -- = KITA Toshihiro http://t-kita.net/ PGP-Key: http://t-kita.net/pubkey.asc fingerprint : CBFF 6A61 5990 10F5 B4B6 D2E8 279A 7063 CF8B 6339 |
