Re: [Freeglut-developer] The order in which we do things ...

[Nigel Stewart and Fiona Smith <nigels@ni...>]

>>I've updated RFE 814984 with a version of glut_geometry.c
>>that includes solid and wire sphere in a similar manner
>>to cone and cylinder.  
> 
> It might be edifying to see the old freeglut geometry in the same context.

https://sourceforge.net/tracker/index.php?func=detail&aid=814984&group_id=1032&atid=351032

I've added screenshots of FreeGLUT 2.0.0, GLUT and the updated FreeGLUT shapes
to the RFE 814984 on soureforge.  The good news is that the sphere and cone
match GLUT closely, but the torus needs attention --- it appears the faces
of the torus in FreeGLUT are in the opposite winding order.

> I'd say go ahead and commit.

Yes, go ahead an commit, I'll attend to the torus shortly.

Nigel

RE: [Freeglut-developer] Linux Menus

[Fay John F Contr AAC/WMG <john.fay@eg...>]

Windows registry!?!?!  Bleah!!!

That is a REAL can of worms and I have NO desire to get involved in it.

For the moment, let's fix the colors to match GLUT colors.  We can figure
out our next step later ... after we have fixed all the real bugs.

John F. Fay
john.fay@...



-----Original Message-----
From: Nigel Stewart and Fiona Smith [mailto:nigels@...]
Sent: Monday, October 06, 2003 6:38 PM
To: freeglut-developer@...
Subject: Re: [Freeglut-developer] Linux Menus



> I don't know what is involved in dealing with FREEGLUT.INI on MS-WINDOWS.
> Is it a text file?  Can we treat it as a config-file like familiar
> ~/.*rc files?  Or should I just write the ~/.*rc code and not worry
> about the MS-WINDOWS side?

	I think it would be more appropriate for the
	Windows registry to be used rather than INI
	files.  I would say do the .*rc file, and
	defer the Windows solution.

	As it turns out, the system-wide colors are
	available in the registry:
	HKEY_CURRENT_USER\Control Panel\Colors
		Menu		"192 192 192"
		MenuText	"0 0 0"

	Alternatively, via GetSysColor:
	DWORD GetSysColor(int nIndex);

		COLOR_MENU
		COLOR_MENUTEXT

	So matching the system colour scheme is
	no major challenge on Windows systems.
	(An no real need to config FreeGLUT
	 menu colour scheme if system scheme
	 is easily available)

Nigel
	




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Freeglut-developer mailing list
Freeglut-developer@...
https://lists.sourceforge.net/lists/listinfo/freeglut-developer

RE: [Freeglut-developer] More mouse wheel API

[Fay John F Contr AAC/WMG <john.fay@eg...>]

As one of the more active "freeglut" developers, I support Steve's decision.

John F. Fay
john.fay@...



-----Original Message-----
From: Steve Baker [mailto:sjbaker1@...]
Sent: Monday, October 06, 2003 10:16 PM
To: freeglut-developer@...
Subject: Re: [Freeglut-developer] More mouse wheel API

<snip>

It's a waste of time continually arguing back and forth - I've listened
to both sides of the debate - and I'm now going to put it to rest.

So as official owner of the freeglut project, I'm going to use my powers
as 'benevolent dictator' to end the debate here and now by decreeing that
I won't accept a mouse wheel extension to freeglut unless the API has the
following form:

   void glutMouseWheelFunc ( function ) ;

   void function ( int wheel, int direction, int x, int y ) ;

...where 'function' is called once per click for digital mouse
wheels.

If analog mouse wheels ever become commonplace, we'll add a way to
tell freeglut how much analog motion is to be considered a 'click'
and a new callback for: glutMouseAnalogWheelFunc.

It's a decision: Counter-arguments to /dev/null please.

<snip>

Re: [Freeglut-developer] More mouse wheel API

[Richard Rauch <sforge@ol...>]

On Tue, Oct 07, 2003 at 10:45:39AM +1000, Nigel Stewart and Fiona Smith wrote:
> >>	So a tick of 0.000001 and 0.01 should be both treated
> >>	as one step in the positive direction?
> >
> >Yes.
> 
> 	I completely disagree.  This would be completely
> 	useless for stepping through a list of items,
> 	for example.  (0.0000001 could simply be
> 	analog "drift")

(1e-7 what?  Meters?  Miles?  AU?  Lightyears?  Furlongs?)

But, I have to wonder if you are forgetting what I've said.

The "distance" parameter exists to inform the application of the
physical *characteristics* of the wheel.  Not the status.  It is
assumed that you are still getting ticks of fixed delta-size for
a given wheel, and each tick results in a distinct callback
invocation.

So, if your wheel has a tick-size of .001 (mm?), then that's what
is passed to the callback.  Likewise if it's 1e-7 (however improbable
that may be if we are talking 1e-7 millimeters).  My logitech would
report +/- 3.3 if I calibrated it, while my MS trackball's wheel
would report +/- 4.4.  (In actuality, I might not bother calibrating
and just live with both at a default 4.0mm for both.)


Except that it's inflexible when you start to run out of 1-bits,
the MS scalar of ~120 for the current wheel-tick is probably pretty
safe.  (Actually, I suspect that they are doing fixed-point scaling.)


Anyway, I didn't say that tick-counting was a good idea.  It obviously
fails should the tick resolution improve dramatically.  There is
nothing that you can do about that if you just have the sign of
the tick.  (Hm.  "The Sign of the Tick".  Sounds like the title
for a TV cartoon with a big blue guy...)

What I am saying is that if all you do is count ticks, you are no
worse off for being told how big those ticks are.


> 	When I feel my mouse wheel step, I expect my
> 	FreeGLUT callback to receive a step.  Simple.

So do I.

The question is, how big of a step?

If you are concerned that the wheel may change to be 3x, 10x, or
120x as fine, then you need to decide what to do with these much
smaller ticks.  And you need to know how big these ticks will be.

I am concerned about this.  Not because I am certain that it will
matter, but because I am certain that if such wheels come about,
a simplistic assumption of universal tick sizes will break.  In
an application, that's easily fixed.  In an API, it's something
that you keep and regret.


Here's another pysical anecdote: My MS trackball's wheel gives
about 6 ticks for a full-length stroke of my finger.  My Logitech
mouse's wheel gives about 8.

That's close enough that tick-counting works without distorting too
much.  But it is for me sufficient evidence that the tick resolution
varies in a meaningful, real-world sense.  If you're using a tick
to scroll up and down a short list, it doesn't matter that much.
If you're using a tick to move a LONG distance, the lower-resolution
mouse is producing appreciably fewer ticks, though you can still get
away with ignoring the difference.



What I propose permits tick-counting for those who are willing to
risk it (the choice is yours, as it should be).  It also helps you
if you're willing to risk the effort to deal with smoother wheels.

I have not seen an objection that I comprehend---or else if I do
comprehend them, then I do not think that they are valid.


> 	I think discovering this difference in
> 	opinion is key to why our wires have been
> 	so crossed over this.

Okay, here's my stab at it:

I think that you are assuming that wheels will either be exactly as they
are today (...which is to say, physically varying substantially, but
also substantially similar), or there will be a sudden break when they
go off the deep end in resolution.  I think that you are assuming that
there will never be any middle-ground.

I do not assume that.  We already have a ~4/3rds resolution wheel,
relative to the original(?) IntelliMouse, and it's in use by at least
some mice from at least two companies (Logitech and AOpen).  There
are cheap parts already available for mouse makers to produce higher
resolution digital wheels (any mouse with a ball has such, as do
many/all trackballs), and they are available in quantities approximately
matching the number of mice being made.

And I would not ignore the fact that MS (a) made the first mouse-wheel
(so far as I know) and (b) has an API ready for rather higher-resolution
digital (at least) wheels.

I don't *know* what will happen, but I'm looking at the possibiilty
of having (and possibly never leaving) a middle-ground.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [Freeglut-developer] Question: multithread support

[Steve Baker <sjbaker1@ai...>]

Runzhen Huang wrote:

> Since I have read one article 
> saying freeglut should be OK for multiple threads although GLUT is not 
> thread-safe, I post this problem for help.

I don't know where you read that - but it's certainly not true.

Neither GLUT nor freeglut were ever designed to be thread-safe.

You might be able to 'get away with it' - but it's not something we've
ever decided to put effort into supporting.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@...>    WorkEmail: <sjbaker@...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Freeglut-developer] Question: multithread support

[Runzhen Huang <rzhuang@uc...>]

Hi,
freeglut is a wonderful UI library for graphics guys!! :) I am using two 
threads in my program, one for user interaction and the other for 
rendering. Since the rendering might take long time, user should be able 
to interrupt and restart the rendering with new parameters input by user.

I am using freeglut and glui. But there are problems for multiple 
threads: in the drawing callback function, I create a thread to render 
images. But the images don't appear when glutSwapBuffers(). Whenever 
glutPostRedisplay(), the program crashes. Since I have read one article 
saying freeglut should be OK for multiple threads although GLUT is not 
thread-safe, I post this problem for help.

My drawing callback funtion likes the following:

void myGLUTDisplay() {
     MyThread render; //claim a thread object
     render.start(); //run the thread
     render.wait(); //wait the thread "render" to be finished
}

The code of the thread "render" is following:

void MyThread::run() {
     glutSetWindow(main_window); //main_window is the identifier
     glViewport(...);
     glMatrixMode(GL_PROJECTION);
     ...... // setup projection matrix
     //clear frame buffer
     glClearColor(...);
     glClear(...);
     glMatrixMode(GL_MODELVIEW); //setup model matrix
     ....
     glutWireTorus(...); //render torus
     glutSwapBuffers();
}

I don't get clear documents about multiple threading using freeglut. If 
any advice, I will really appreciate.

Thanks,

Runzhen

Re: [Freeglut-developer] More mouse wheel API

[Steve Baker <sjbaker1@ai...>]

Nigel Stewart and Fiona Smith wrote:

>     So a tick of 0.000001 and 0.01 should be both treated
>     as one step in the positive direction?

If that's the way it's going to work - then that's what every
application program on the planet will have to do.  Programmers
and end users will want the wheel to scroll by one line of text
for every click *despite* all the crap that freeglut is putting in
the way...so they'll do exactly this.

I think this approach of passing pseudo-distances (which won't be correct)
is VERY, VERY, DUMB.

I want to see one call per click...if analog wheels come along - we'll
add an analog wheel function and the application can read either clicks
or distance.

It's a waste of time continually arguing back and forth - I've listened
to both sides of the debate - and I'm now going to put it to rest.

So as official owner of the freeglut project, I'm going to use my powers
as 'benevolent dictator' to end the debate here and now by decreeing that
I won't accept a mouse wheel extension to freeglut unless the API has the
following form:

   void glutMouseWheelFunc ( function ) ;

   void function ( int wheel, int direction, int x, int y ) ;

...where 'function' is called once per click for digital mouse
wheels.

If analog mouse wheels ever become commonplace, we'll add a way to
tell freeglut how much analog motion is to be considered a 'click'
and a new callback for: glutMouseAnalogWheelFunc.

It's a decision: Counter-arguments to /dev/null please.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@...>    WorkEmail: <sjbaker@...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Freeglut-developer] More mouse wheel API

[Nigel Stewart and Fiona Smith <nigels@ni...>]

>>	So a tick of 0.000001 and 0.01 should be both treated
>>	as one step in the positive direction?
> 
> Yes.

	I completely disagree.  This would be completely
	useless for stepping through a list of items,
	for example.  (0.0000001 could simply be
	analog "drift")

	When I feel my mouse wheel step, I expect my
	FreeGLUT callback to receive a step.  Simple.

	I think discovering this difference in
	opinion is key to why our wires have been
	so crossed over this.

Re: [Freeglut-developer] More mouse wheel API

[Richard Rauch <sforge@ol...>]

On Tue, Oct 07, 2003 at 10:13:29AM +1000, Nigel Stewart and Fiona Smith wrote:
> >Bingo.
 [...]
> 	So a tick of 0.000001 and 0.01 should be both treated
> 	as one step in the positive direction?

Yes.

The only difference between raw ticks and this is a scalar multiple.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

Re: [Freeglut-developer] More mouse wheel API

[Nigel Stewart and Fiona Smith <nigels@ni...>]

>>>if (tick < 0)
>>>  do_negative_scroll ();
>>>else
>>>  do positive_scroll ();
>>
>>	The problem with this is that the sensitivity of
>>	mouse wheel stepping will depend on the resolution
>>	of the individual mouse, rather than matching
>>	the system concept of a forward or backward step.
>>	This approach will not work well for a truely
>>	analog mouse wheel.
> 
> Bingo.
> 
> That's why {tick} is a double-precision floating point value
> indicating the estimated millimeters of a tick.
> 
> The point is, some people were lamenting the "extra work" that
> pure tick-counters have to do.  In fact, it is no different.

	So a tick of 0.000001 and 0.01 should be both treated
	as one step in the positive direction?

Re: [Freeglut-developer] More mouse wheel API

[Richard Rauch <sforge@ol...>]

On Tue, Oct 07, 2003 at 09:04:48AM +1000, Nigel Stewart and Fiona Smith wrote:
> 
> > if (tick < 0)
> >   do_negative_scroll ();
> > else
> >   do positive_scroll ();
> 
> 	The problem with this is that the sensitivity of
> 	mouse wheel stepping will depend on the resolution
> 	of the individual mouse, rather than matching
> 	the system concept of a forward or backward step.
> 	This approach will not work well for a truely
> 	analog mouse wheel.

Bingo.

That's why {tick} is a double-precision floating point value
indicating the estimated millimeters of a tick.

The point is, some people were lamenting the "extra work" that
pure tick-counters have to do.  In fact, it is no different.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/