glam-devel Mailing List for The GLAM OpenGL User Interface Toolkit

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

David Longley wrote:
> I'm not quite sure how GL_COMPILE_AND_EXECUTE works such 
> that it slows down the render process--perhaps it compiles as it is 
> executing.

Whoever made the statement that GL_COMPILE_AND_EXECUTE slows down the 
render process probably meant to say "It slows down the first execution 
of the call, thus if you are constantly compiling/executing in the same 
thread... application performance will suffer."

This is because (in bad driver implementations) it doubles the work the 
graphics card has to do:

1. All of the geometry calculations
2. Writes across the AGP bus and display list management (costly 
graphics card state changes)

Whats worse is that the two steps above have to be in sync with each 
other for large lists... which limits throughput to the speed at which 
the AGP bus can keep up... which is much slower than what the graphics 
card is capable of.

The NVidia drivers have performance problems with 
GL_COMPILE_AND_EXECUTE, as do most drivers. The only guaranteed way to 
control performance is to compile and execute seperately (and as Dave 
said, that is what we do in glam, glamrock and CSD).

So if you see GL_COMPILE_AND_EXECUTE anywhere in glam code, it is wrong 
and needs to be changed.

I couldn't find any instances of GL_COMPILE_AND_EXECUTE in glam or glamrock?

-- manu

-- 
Manu Sporny
Director of Product Development
xRhino, Inc.
1700 Kraft Drive, Suite 2408
Blacksburg, Virginia, USA 24060
Telephone: (540) 961-4469
Email    : ms...@xr...
Web      : http://www.xrhino.com/

Chetan,

We don't ever call GL_COMPILE_AND_EXECUTE for that very reason.  We do compile 
the lists on render when necessary, but we use GL_COMPILE only.  We call the 
lists thereafter.  I'm not quite sure how GL_COMPILE_AND_EXECUTE works such 
that it slows down the render process--perhaps it compiles as it is 
executing.

An extra subroutine isn't necessary as when the lists are compiled really 
doesn't matter, just that they aren't being executed concurrently with their 
compilation (I believe).

In any case, we used to use GL_C_AND_E but found that it slowed things down 
and after we switched over to just GL_C and then calling the list things sped 
up.

The code looks like this:

> void render()
> {
>     if(!mDisplayListId)
>     {
>         mDisplayListId = glGenLists(1);
>         glNewList(mDisplayListId,
> GL_COMPILE);//<-----------------------------
>         .......
>         glEndList();
>     }
>     
>     glCallList(mDisplayListId);
> }

-Dave

On Monday 01 December 2003 02:07 pm, Chetan Dandekar wrote:
> Dear All,
>
> On a opengl discussion board, I recently found a post saying
> GL_COMPILE_AND_EXECUTE
> slows down the rendering.
>
> What we genereally do (in glam and my application) is:
>
> void render()
> {
>     if(!mDisplayListId)
>     {
>         mDisplayListId = glGenLists(1);
>         glNewList(mDisplayListId,
> GL_COMPILE_AND_EXECUTE);//<-----------------------------
>         .......
>         glEndList();
>     }
>     else
>         glCallList(mDisplayListId);
> }
>
> If the above post is correct, we should make some changes, like having a
> separate subroutine
> for just compiling the display lists (using GL_COMPILE), and only
> calling them in the
> render() function.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> glam-devel mailing list
> gla...@li...
> https://lists.sourceforge.net/lists/listinfo/glam-devel

Dear All,

On a opengl discussion board, I recently found a post saying 
GL_COMPILE_AND_EXECUTE
slows down the rendering.

What we genereally do (in glam and my application) is:

void render()
{
    if(!mDisplayListId)
    {
        mDisplayListId = glGenLists(1);
        glNewList(mDisplayListId, 
GL_COMPILE_AND_EXECUTE);//<-----------------------------
        .......
        glEndList();       
    }
    else
        glCallList(mDisplayListId);
}

If the above post is correct, we should make some changes, like having a 
separate subroutine
for just compiling the display lists (using GL_COMPILE), and only 
calling them in the 
render() function.

Inside this function, when a list item is created,
Its text size should be set to be same as that of the menu.

Currently, it is not set, so it takes the default text size (from 
GmOptions),
which sometimes does not match with the menu text size.

- Chetan

Chetan,

Good catch .. I think :).  I'm pretty sure that that code wasn't left out on 
purpose.  I threw it in for the next release.

-Dave

On Thursday 20 November 2003 10:37 am, Chetan Dandekar wrote:
> void GmContainer::render2d(GmTypes::RenderOptionType renderOptions)
> {
>    GmInteractiveWidget::render2d(renderOptions);
>
>    vector<GmDrawable*>::iterator i;
>    for(i = mComponents.begin(); i != mComponents.end(); i++)
>       (*i)->render(renderOptions);
> }
>
> void GmContainer::render2dSelect(GmTypes::RenderOptionType renderOptions)
> {
>   // GmInteractiveWidget::render2dSelect(renderOptions); should be here
>
>   vector<GmDrawable*>::iterator i;
>    for(i = mComponents.begin(); i != mComponents.end(); i++)
>       (*i)->render(renderOptions);
> }
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> glam-devel mailing list
> gla...@li...
> https://lists.sourceforge.net/lists/listinfo/glam-devel

void GmContainer::render2d(GmTypes::RenderOptionType renderOptions)
{
   GmInteractiveWidget::render2d(renderOptions);

   vector<GmDrawable*>::iterator i;
   for(i = mComponents.begin(); i != mComponents.end(); i++)
      (*i)->render(renderOptions);
}

void GmContainer::render2dSelect(GmTypes::RenderOptionType renderOptions)
{
  // GmInteractiveWidget::render2dSelect(renderOptions); should be here
 
  vector<GmDrawable*>::iterator i;
   for(i = mComponents.begin(); i != mComponents.end(); i++)
      (*i)->render(renderOptions);
}

Hi,

The text gets rendered much above the layer in which it should actually 
get rendered,
If it's solvable in the next release, before I/ITSEC, I'll not do it 
indirectly,
by setting the depth the deeper than the desired value.

- Chetan

Hi There!

Manu, Thanks for your reply.


Manu Sporny wrote:

> To put it in perspective, that amount of documentation would require 
> an extra day of development per developer, per release... which would 
> mean that we spend 4 developer days making sure that you don't spend 
> 1/2 a developer day debugging a mis-communication. Its more efficient 
> this way, even though inevitably there will be snags such as this 
> along the way.
>
Yes. I understand. This way is  obviously better, if we are going to 
lose 4 developer days to save my 1/2 day. But, I just wanted to make 
sure that I am not missing anything, i.e. such detailed documentation is 
being created and not reaching my self :-)

>
> This is because panels are not interactive objects and there is no 
> reason for a panel to recieve events. If you do want this 
> functionality, subclass from GmPanel and overload the render2dSelect() 
> method.

I think the Panels should be interactive - mainly for dragging them around.



- Chetan

Hi Chetan... some answers to your questions

Chetan Dandekar wrote:
> As requested in the last mail, I really need the 
 > detailed information / log-file about changes, fixes
 > and additions

You can access all of the change log files for each package by reading 
the following file(s):

/usr/share/doc/<package_name>/changelog.Debian

We describe all the major changes in there... and we release each of 
these files in the package contents for every release that we perform.

> In the new release a 2D layout manager gets added by 
 > default, which  shuts off depth/z value information. If I knew
> this particular change, I would not have wasted so much time.

I'm sorry you spent so much time tracking that problem down. We do our 
best to document all the changes. However, between releases upwards of 
50-500 changes such as the one that you describe are implemented and we 
cannot document at that level of granularity and meet all the deadlines 
imposed on us.

To put it in perspective, that amount of documentation would require an 
extra day of development per developer, per release... which would mean 
that we spend 4 developer days making sure that you don't spend 1/2 a 
developer day debugging a mis-communication. Its more efficient this 
way, even though inevitably there will be snags such as this along the way.

Besides, you would spend half your day just reading the changelog if we 
were to implement full-disclosure changelogs... and nobody wants that :)

> In GmPanel::render2dSelect(GmTypes::RenderOptionType renderOptions), 
> GmPanel's name is not pushed on
> the name stack, so even if a GmPanel is picked, its name is absent from 
> the namestack and it can not be sent an event.

This is because panels are not interactive objects and there is no 
reason for a panel to recieve events. If you do want this functionality, 
subclass from GmPanel and overload the render2dSelect() method.

-- manu

-- 
Manu Sporny
Director of Product Development
xRhino, Inc.
1700 Kraft Drive, Suite 2408
Blacksburg, Virginia, USA 24060
Telephone: (540) 961-4469
Email    : ms...@xr...
Web      : http://www.xrhino.com/

Dear All,

As requested in the last mail, I really need the detailed information / 
log-file about changes, fixes and additions, whenever
a new glam/glamrock/sugar/glmath version is released. Today, I wasted my 
half day, because I did not have this
information. I had to search through the source code, try different 
things, to find out about these things:

1)Change:
 
I am using classes MvNavigator and MvMarker derived from, GmPanel (in 
turn from GmContentPane). The derived classes make
use of depth and z values. Earlier, GmContentPane did not have a default 
layout manager, so the 3D stuff worked fine.
In the new release a 2D layout manager gets added by default, which 
shuts off depth/z value information. If I knew
this particular change, I would not have wasted so much time.

Also. since this change is going to remain in future versions, I have to 
either do a wierd thing (deleting the 2d layout
manager soon after it gets created by default) or creating a class 
'like' GmPanel, duplicating much of the code.


2)Bug:

In GmPanel::render2dSelect(GmTypes::RenderOptionType renderOptions), 
 GmPanel's name is not pushed on
the name stack, so even if a GmPanel is picked, its name is absent from 
the namestack and it can not be sent an event.

- Chetan

Hi There!

In the new versions, if the text justification  for GrPushButton is set 
different
from JTH_CENTER, and JTV_MIDDLE, the justification values are set properly.
However, the text is rendered in the Center and Middle of the button 
irrespective
of the set justification values.

(This problem was not there in glam 0.10-1 and glamrock 0.7-2)

- Chetan

Thanks for providing GmDrawable :: get/setGLPosition(float &x, float &y, 
float &z)!
I noticed that setPosition(float &x, float &y, float &z) is missing.

- Chetan

Chetan,

> *A function to disable tooltip
> and
> *Functions, which will set/get 'actual' text string of the GmLabel,
> since the displayed string is sometimes different.("..." factor!)

Whenever you get the string from a label, it should return the actual
string, not the abbreviated one.

> PS: I noticed new packages on purgatory, I guess you guys must
> be sending an email about the new features/changes soon.

Yeah, I'm guessing that email will go out later today.

-Dave

----- Original Message ----- 
From: "Chetan Dandekar" <che...@as...>
To: "glam-devel" <gla...@li...>
Sent: Wednesday, November 12, 2003 11:46 AM
Subject: [glam-devel] need 2 additions in GmLabel


> Hi,
>
> *A function to disable tooltip
> and
> *Functions, which will set/get 'actual' text string of the GmLabel,
> since the displayed string is sometimes different.("..." factor!)
>
> - Chetan
>
> PS: I noticed new packages on purgatory, I guess you guys must
> be sending an email about the new features/changes soon.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> glam-devel mailing list
> gla...@li...
> https://lists.sourceforge.net/lists/listinfo/glam-devel
>

Hi,

*A function to disable tooltip
and
*Functions, which will set/get 'actual' text string of the GmLabel,
since the displayed string is sometimes different.("..." factor!)

- Chetan

PS: I noticed new packages on purgatory, I guess you guys must
be sending an email about the new features/changes soon.

Hi,

This is with reference to my previous mail about rendering/parsing error 
in Sugar.
Attached is a much simpler version of the previous SVG I sent.


- Chetan

Dear All,

I was wondering about the need to use glutIdleFunc callback.

I know, there are atleats two uses:

1) If a glut window is dragged around, and if it doesn't have 
glutIdleFunc callback,
it doesn't get redrawn until its released.

2) For frame-based animation.

I had seen  #1 to be true earlier, but it is not true on my machine here.
Even w/o glutIdleFunc callback, it redraws the window while dragging around.

About #2, animation can be achieved by using a timer instead of 
glutIdleFunc.
Infact, time-based animation is more controlled and preferable than 
frame-based
animation.

Are there any other uses of glutIdleFunc? I want to know this because,
we suspect glutIdleFunc to be the cause of a problem we are having here,
(program not refreshing the window, due to lack of enough CPU time)
and want to get rid of it, if its not useful currently and in future.

- Chetan

Hi,

I think, we should have a copy constructor and/or overloaded operator "="
for glam classes. It will be very handy, if one needs to create a copy 
of an instance
of a glam class or a class derived from glam.

- Chetan

I found out that, one of the bottlenecks for my application is rendering 
of many SVGs.
I feel, the performance will improve if something like layoutInGLVolume 
can be
implmented in Sugar.

For example,

instead of executing,
/glPushMatrix();
glTranslatef(...);
Scalef(...);
sugSvgRenderer->render();
glPopMartrix();
/in every render call,

execute,
/sugSvgRenderer->layoutInGLVolume/Area(...);
/once
and then just
/sugSvgRenderer->render();
/in each render call

................same way in which we handle glam widget geometries.

- Chetan

If the attached svg is rendered using Sugar ( e.g. using the test 
program sugView)
a horizontal line runs from -infinity to + infinity. Any clues about 
this problem
and how to avoid this problem.

- Chetan

Hi,

I remember, there was some rendering error with 'Texture" font type
(Stray lines around a character). Using "Solid" font type is an obvious 
way to
get rid of that problem. Is there any other way, (which will allow using
"Texture" font type w/o the error)?

- Chetan

Chetan Dandekar wrote:

> for setting 'layer' or the minX value of the child widget,

I mean "for setting 'layer' or the minZ value

- Chetan

Hi,

YES, I am not interested in setting depth of the child widgets. BUT,
for setting 'layer' or the minX value of the child widget, there should be,
some non-zero mGLDepth for the parent.

e.g.

Using setRelativeGeometry, we set Child.mPosition as (0.0, 0.0, 0.5)
i.e. the 'layer' at 0.5z relative to the parent.
Now when the layoutInGLVolume(..) is called for the parent, parent calls
Child.layoutInGLVolume(..) using its (parent's) updated mGLPosition and 
mGLWidth,
mGLHeight and mGLDepth.

Inside the child, child's x, y and 'layer' i.e. z are calculated based 
on parent's minX, minY, minZ
AND mGLWidth/Height/Depth, sent in using layoutInGLVolume().
/
void GmDrawable::layoutInGLVolume(float minX, float minY, float minZ,
                                  float width, float height, float depth)
{
   // (minX, minY, minZ) Parent container x, y and z base position
   float dX, dY, dZ; // Drawable's x, y and z base position

   mPosition.getXYZ(dX, dY, dZ);

   mGLPosition.setXYZ(minX + (width * dX),
                      minY + (height * dY),
                      minZ + (depth * dZ));
   mGLWidth = width * mWidth;
   mGLHeight = height * mHeight;
   mGLDepth = depth * mDepth;

   setDisplayListValid(false);
}
/
So, If Parent.mDepth = 0.0, by default, Parent.mGLDepth will also be 0.0 
unless mDepth is set to 1.0.
If Parent.mGLDepth = 0.0, 'depth' in the above code will be 0.0, and z 
value for the child will be incorrect.

- Chetan

David Longley wrote:

>Chetan,
>
>If you have 3 child widgets inside a container, set their layers, not their 
>depth.  2d widgets don't have depth, but they are placed on different layers.
>
>Just think of it like this -- a 2d widget is drawn on a plane (layer) ... but 
>a plane is in 3d space.  You tell the widget which plane to draw on... you 
>don't make it take up more than 1 plane.
>
>-Dave
>
>On Thursday 06 November 2003 03:35 pm, Chetan Dandekar wrote:
>  
>
>>The 'layer' is ultimately the z value.
>>I have 3 children ( I mean children widgets :-P) inside a container,
>>I set their relative geometries such that they get spread out, over a depth
>>(range of z values determined by the mGLDepth of the parent.)
>>
>>Now, by default mDepth of the parent is 0.0. So, unless I explicitly set
>>its mDepth = 1.0, its mGLDepth will also remain 0.0. But in case, of mWidth
>>mHeight, they are 1.0 by default.  mDepth should be 1.0 by default in the
>>same way.
>>
>>- Chetan
>>
>>Dave Longley wrote:
>>    
>>
>>>Chetan,
>>>
>>>Setting depth should have nothing to do with overlapping children.  The
>>>layer that the children are rendered in does.  We just don't handle
>>>layering properly yet.
>>>
>>>-Dave
>>>
>>>----- Original Message -----
>>>      
>>>
>>From: "Chetan Dandekar" <che...@as...>
>>
>>    
>>
>>>To: "glam-devel" <gla...@li...>
>>>Sent: Wednesday, November 05, 2003 5:41 PM
>>>Subject: Re: [glam-devel] small but imp. correction in GmDrawable
>>>constructor
>>>
>>>      
>>>
>>>>Well, what we call 2d in glam in not only 2d! It also includes 3d
>>>>orthographic projection.
>>>>This is useful when the children widgets need to overlap each other and
>>>>still function
>>>>correctly, independent of the rendering order.
>>>>
>>>>I am using overlapping childrens. So, for that I have to explicitly set
>>>>mDepth as 1.0 whereas
>>>>mWidth and mHeight are 1.0 by default, which is not consistent.
>>>>
>>>>- Chetan
>>>>
>>>>David Longley wrote:
>>>>        
>>>>
>>>>>Chetan,
>>>>>
>>>>>Depth is set correctly.  In a 2d application (default), widgets have no
>>>>>          
>>>>>
>>>depth.
>>>
>>>      
>>>
>>>>>-Dave
>>>>>          
>>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: SF.net Giveback Program.
>>>>Does SourceForge.net help you be more productive?  Does it
>>>>help you create better code?   SHARE THE LOVE, and help us help
>>>>YOU!  Click Here: http://sourceforge.net/donate/
>>>>_______________________________________________
>>>>glam-devel mailing list
>>>>gla...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/glam-devel
>>>>        
>>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: SF.net Giveback Program.
>>>Does SourceForge.net help you be more productive?  Does it
>>>help you create better code?   SHARE THE LOVE, and help us help
>>>YOU!  Click Here: http://sourceforge.net/donate/
>>>_______________________________________________
>>>glam-devel mailing list
>>>gla...@li...
>>>https://lists.sourceforge.net/lists/listinfo/glam-devel
>>>      
>>>
>
>
>  
>