quesa-develop — Mailing list for Quesa development

Re: Licence change

[James W. W. <ja...@wr...>]

I'm really surprised that nobody else has commented on this thread. 
Maybe I'm making a mountain out of a molehill, but to me it's an 
embarrassment to talk about regents when Quesa is clearly not 
affiliated with any university.  It looks as if we didn't bother to 
read our own license.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Licence change

[James W. W. <os...@jw...>]

On Apr 27, 2004, at 1:06 AM, Dair Grant wrote:

> Originally it was, as the template for the licence uses "Regents of the
> University of California" as the 'owner' field.
>
> However without qualification it just means "member of a governing
> board", i.e., us. It does tend to be used mostly by Universities
> nowadays, as they do like to hang on to obscure terms, but doesn't have
> to.

OK, but the template at 
<http://www.opensource.org/licenses/bsd-license.php> does not use the 
word "regents".
--
<http://www.jwwalker.com/>

Re: Licence change

[Dair G. <da...@re...>]

James W. Walker wrote:

>One little detail:  Who are the "regents" mentioned in the license?=20
>I assume that's the Berkeley regents.  I think maybe it could be left=20
>unsaid that they won't be held responsible for Quesa. :-)

Originally it was, as the template for the licence uses "Regents of the
University of California" as the 'owner' field.

However without qualification it just means "member of a governing
board", i.e., us. It does tend to be used mostly by Universities
nowadays, as they do like to hang on to obscure terms, but doesn't have
to.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Licence change

[James W. W. <ja...@wr...>]

Dair Grant <da...@re...> wrote:

>Quesa is now available under a BSD licence, which is available at:
>
>   Documentation/reference/licence.html
>
>This has been discussed off- and on-list for a while amongst the
>steering group, and we all feel it will be for the benefit of the
>project.


One little detail:  Who are the "regents" mentioned in the license? 
I assume that's the Berkeley regents.  I think maybe it could be left 
unsaid that they won't be held responsible for Quesa. :-)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Licence change

[Dair G. <da...@re...>]

Hi,

I turned off mail notification to quesa-cvs while doing the check-in, as
it involved touching almost every file, however the license change for
Quesa is now complete.

Quesa is now available under a BSD licence, which is available at:

  Documentation/reference/licence.html

This has been discussed off- and on-list for a while amongst the
steering group, and we all feel it will be for the benefit of the
project.


The reason for the change is purely an aspect of the LGPL which I missed
at the time of choosing it. Namely that if you linked statically, in
theory your users need to be able to make a change to the library and
re-link your app, and so you end up having to (in theory) distribute the
object code for your app to make this possible.

In practice this problem was entirely theoretical, as it would never
have been a problem for people to link Quesa statically. But the licence
now reflects this, and ensures you can use Quesa in whatever form
(static, dynamic, the whole thing or just a couple of functions) makes
sense for you.


The downside for the project is that you're no longer compelled to
return your changes to the library.

I don't think this will be a significant problem, as any significant
modifications will end up being submitted anyway simply to reduce the
work of merging.


-dair (I've fixed up all of our references, and will update SourceForge,
but if you happen across any links that say LGPL please let me know so
we can update them)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: transparency & specularity

[Dair G. <da...@re...>]

James W. Walker wrote:

>I think you're right.  Apparently Quesa doesn't really have any =20
>provision for specular highlights on transparent material.  I found a =20
>hint about how to do it: =20
><http://www.opengl.org/resources/faq/technical/=20
>transparency.htm#blen0030>

Yes, this is the best you can do with a GL renderer I think: just been
an oversight that we didn't keep track of that state before (and I think
the times it has looked "working" were purely down to stale state being
in effect, as Frank said).


>You're right.  In the code I just checked in, the extra specular=20
>rendering is only done on triangles that were submitted with Phong=20
>rendering (and fill style =3D=3D filled.)

I've amended this slightly, so that we keep a separate flag indicating
if we ever see a triangle with the flag set (and so only do the second
pass if something was flagged as needing it).


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

[ quesa-Feature Requests-895117 ] Support custom sorting for transparent surfaces

[SourceForge.net <no...@so...>]

Feature Requests item #895117, was opened at 2004-02-11 20:13
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=895117&group_id=45158

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Frank Condello (pox)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: Support custom sorting for transparent surfaces

Initial Comment:
The transparent surface renderer broke when the new view 
transform API was added. Vertices outside the frustum can become 
undefined, leading to infinite point errors and jumbled geometry. 
This may also adversely affect the sorting algorithm.

Some other issues that may or may not be related involve an 
errant lighting state. Transparent objects may inherit the 
illumination style of other objects in the scene rather than use their 
own, and faceted geometry (interpolation style none) always 
appears with null shading.

----------------------------------------------------------------------

>Comment By: Dair Grant (grantd)
Date: 2004-04-26 20:45

Message:
Logged In: YES 
user_id=439944

After trying various techniques, I haven't really been able to improve the 
appearance of this scene. There's a discussion of the "best you can do" 
for painters-algorithm style rendering at:

<http://groups.google.com/groups?
&selm=5qmkhg%24mhh%241%40java.imsa.edu>

One thing mentioned there is to perform a cheap test on x/y extents first 
before looking at overlaps in z. We now do this, and it improves the test 
boxes slightly - but not enough to classify them as resolved.

I've attached some sample models to this bug, which might be useful for 
further debugging - from these you can see that at least some of the 
boxes have an inconsistent orientation (some faces are CW, some are 
CCW) which accounts for some of the flicker.

Probably the only way to resolve this arbitrarily is to allow for a custom 
sorting callback, so that an application which can't use the default 
approach can supply its own callback to resolve overlaps and produce a 
determinant ordering.

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-02-19 20:45

Message:
Logged In: YES 
user_id=439944

It looks like this isn't related to the transform changes: as far as I can 
see, things are sorted as well in frustum space as they were in world 
coordinates (i.e., attached model also renders with flicker under 1.6d18).

It looks like the problem is in the sorting choices made when triangles 
overlap in z: that overlap can be in world coordinates or frustum 
coordinates, but removing the current selection choice gives us a much 
more stable selection (for this case, but that won't be a fix).

I can't see any problems with sorting in frustum coordinates when the 
vertices are outside the frustum - those vertices will be clipped later on, 
but being outside the frustum won't affect the sort.

The lighting flicker appears to be due to the triangle order jumping 
around from frame to frame - if you still see any illumination problems 
when this bug is closed, can you log them as separate bugs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=895117&group_id=45158

Re: optimizing method dispatch

[Dair G. <da...@re...>]

James W. Walker wrote:

>At least for multibox, the most frequently used methods were=20
>kQ3XMethodTypeObjectSubmitRender, kQ3XMethodTypeObjectDispose,=20
>kQ3XMethodType_GroupGetNextPositionOfType, and=20
>kQ3XMethodTypeGeomGetPublicData.

I suspect the list of "hot" methods will vary depending on what's being
done at any one time. It might be worth trying to keep a little cache of
3-5 methods (say), with appropriate stats to update them periodically
and be able to dump out how effective it tends to be.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: optimizing method dispatch

[James W. W. <os...@jw...>]

On Apr 26, 2004, at 4:43 AM, Roger Holmes wrote:

> I have no done everything yet so I would be interested to know which 
> methods you found were important. I could then do any I have not 
> already done.

At least for multibox, the most frequently used methods were 
kQ3XMethodTypeObjectSubmitRender, kQ3XMethodTypeObjectDispose, 
kQ3XMethodType_GroupGetNextPositionOfType, and 
kQ3XMethodTypeGeomGetPublicData.
--
<http://www.jwwalker.com/>

Re: optimizing method dispatch

[Roger H. <rog...@mi...>]

On Sunday, April 25, 2004, at 12:13  am, James W. Walker wrote:

> How much of an improvement are you seeing?

It is difficult for me to separate that optimisation from the others I 
have done. My e-mails back in
September talk of gains from 11% less time up to double the speed in 
GeomTest, and that was not
the end of the work I did. One of the changes is now checked in and I 
am awaiting approval for
the others. The most important methods seems to be creation and 
deletion of objects, even when
the object is still referenced, scanning down the class structure to 
the root object data (dispose
is a method of root) takes a lot of time in the cvs version. Allocating 
all the instance data for each
level of an objects parent classes was another thing I improved from 
the cvs - I now just do one
allocation and all the data lives in the one block of RAM. This may 
also give less problems with
cache misses as all the data is in consecutive locations. This of 
course also save time when the
object gets deleted and helps with memory fragmentation. The downside 
is that the structs have
to be moved from the E3xxxx.c to the E3xxxx.h files, though of course 
they are still not in the SDK's
Q3xxxx.h files.


>
> I tried a simple approach of storing a few of the most heavily-used 
> methods in the E3ClassInfo record.  This change improved the multibox 
> frame rate by 6% or so, and the changes are confined to E3ClassTree.c.

With the method tables, my implementation has to start at root and 
works towards the leaf classes. I have no done
everything yet so I would be interested to know which methods you found 
were important. I could then do any I
have not already done.

Roger.

Re: optimizing method dispatch

[James W. W. <os...@jw...>]

On Apr 20, 2004, at 5:09 AM, Roger Holmes wrote:

> Dair has excellent hearing. That will be good, I will try to do you 
> another
> instalment, the one which optimises the dispatching inside 
> Q3ObjectDispose
> which is the main culprit.
>
> The only thing I think which is a bit of a negative is that the struct 
> of the instance
> data has to available to classes which inherit from it. I currently 
> put it into the
> E3.... .h file which I am afraid Dair will object to. If so, could we 
> put it in a file
> specifically for the task, E3...Instance.h or something?

How much of an improvement are you seeing?

I tried a simple approach of storing a few of the most heavily-used 
methods in the E3ClassInfo record.  This change improved the multibox 
frame rate by 6% or so, and the changes are confined to E3ClassTree.c.
--
<http://www.jwwalker.com/>

[ quesa-Bugs-940109 ] Will not render on 2nd monitor of 2 monitor system (WinXP)

[SourceForge.net <no...@so...>]

Bugs item #940109, was opened at 2004-04-22 15:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=940109&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Will not render on 2nd monitor of 2 monitor system (WinXP)

Initial Comment:
On a WindowsXP system with desktop spread over 2 
monitors, GeomTest.exe fails to render if dragged over 
onto the second monitor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=940109&group_id=45158

Re: View stack state

[Roger H. <rog...@mi...>]

Dair has excellent hearing. That will be good, I will try to do you 
another
instalment, the one which optimises the dispatching inside 
Q3ObjectDispose
which is the main culprit.

The only thing I think which is a bit of a negative is that the struct 
of the instance
data has to available to classes which inherit from it. I currently put 
it into the
E3.... .h file which I am afraid Dair will object to. If so, could we 
put it in a file
specifically for the task, E3...Instance.h or something?

Roger.


On Monday, April 19, 2004, at 09:57  pm, Dair Grant wrote:

>
>> By the way, profiling the multibox test with Shark shows that the most
>> time spent in a single function is about 10% in E3HashTable_Find,
>> called by E3ClassTree_GetMethod.  I wonder if it possible to improve
>> our method dispatch?
>
> I can hear Roger nodding his head from here... :-)
>
> This is actually part of one of his set of optimisations, which I've
> been meaning to take a look at for far too long now. It sounds like 
> this
> is becoming more of a priority though, so Roger I will have another
> attempt to look at it this week.

Re: View stack state

[Dair G. <da...@re...>]

James W. Walker wrote:

>With these changes, the multibox frame rate approximately doubles.   In=20
>other situations, you may see no significant change.

Excellent! I suspect this will be very useful for any scene that has a
lot of groups: it sounds like we were spending as much time walking
through the scene as we were actually drawing.


>By the way, profiling the multibox test with Shark shows that the most=20
>time spent in a single function is about 10% in E3HashTable_Find,=20
>called by E3ClassTree_GetMethod.  I wonder if it possible to improve=20
>our method dispatch?

I can hear Roger nodding his head from here... :-)

This is actually part of one of his set of optimisations, which I've
been meaning to take a look at for far too long now. It sounds like this
is becoming more of a priority though, so Roger I will have another
attempt to look at it this week.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: View stack state

[James W. W. <os...@jw...>]

OK, I have checked in my changes to do less updating of the GL state by 
the view stack.  I have also modified the renderers to reduce calls to 
glEnableClientState and glDisableClientState.

With these changes, the multibox frame rate approximately doubles.   In 
other situations, you may see no significant change.

By the way, profiling the multibox test with Shark shows that the most 
time spent in a single function is about 10% in E3HashTable_Find, 
called by E3ClassTree_GetMethod.  I wonder if it possible to improve 
our method dispatch?
--
<http://www.jwwalker.com/>

Re: View stack state

[James W. W. <os...@jw...>]

On Apr 18, 2004, at 1:48 PM, Dair Grant wrote:

> James W. Walker wrote:
>
>> It appears that the stackState->stackState member of the view stack
>> frame always has the value kQ3ViewStateAll, which means that all
>> sorts of OpenGL state gets reset every time you pop the stack.  Was
>> there some unfinished plan to make this behave more sensibly?
>
> Hmm, yes, you're right - looks like that never got finished off.
>
> The idea was to be able to keep track of what's changed at each level 
> of
> the stack, so that when we pop the stack we're able to update only 
> those
> bits of state which actually changed in the corresponding push.
>
> But at the moment we start it off as kQ3ViewStateAll, and never keep
> track of things as they're added: so end up with clearing everything on
> each pop.
>
> Do you want to fix it up to work properly, or log a bug so that we know
> it could be improved?

I'll see if I can fix it.  If I don't get it done soon, I'll file a bug.
--
<http://www.jwwalker.com/>

Re: Another small optimization: aglMacro

[James W. W. <os...@jw...>]

On Apr 18, 2004, at 1:48 PM, Dair Grant wrote:

>> However some Quesa internal functions would need an extra
>> parameter.
>
> Plus we'd need extra local variables, if I understand the setup
> correctly, i.e., we'd have to have a local agl_ctx in each routine that
> made a GL call which was initialised to the context in the instance
> data?

No, not really.  For example, to make the change in IRUpdate.c, I added 
the following to the top of the file:

#if QUESA_OS_MACINTOSH
	#define		agl_ctx		((AGLContext)instanceData->glContext)

	#if TARGET_RT_MAC_MACHO
		#include <AGL/aglMacro.h>
	#else
		#include <aglMacro.h>
	#endif
#endif

It so happens that everywhere you need the context, you have an 
instanceData variable by which one can access the GL context.  In some 
other source files, I defined agl_ctx as ((AGLContext)glContext) 
instead.

> A 6% change isn't normally something to ignore, but I'd be curious to
> see if you get any impact in other tests?
>
> The multibox test I'd expect to spend most of its time updating the 
> view
> stack: i.e., showing the cost of per-object processing within Quesa
> rather than rendering time (and a lot of that is probably the bogus 
> view
> state stack updates on pop).
>
> Normally this only really helps for immediate mode drawing, where 
> you're
> doing N-thousand glVertex calls or whatever: as Frank says that's the
> case for the transparent path, but shouldn't happen normally.
>
> So I'm kind of surprised you did get anything out of it actually. :-)
>
>
> -dair (I wonder if the place we're saving the time is in IRUpdate.c: we
> probably make more GL state calls in there than we do GL drawing calls,
> and I bet most of them are happening because of the excessive view 
> state
> stack updates)

There's enough variation in frame rate that it's possible that what I 
thought was an improvement was actually experimental error.  I'll hold 
off on this, and take another look after the view state stack stuff has 
been addressed.
--
<http://www.jwwalker.com/>

Re: Another small optimization: aglMacro

[Dair G. <da...@re...>]

=46rank C wrote:

>Can't hurt either way though, and IIRC, the transparent pass and some
>other special cases are drawn in immediate mode so it could help quite
>a bit for certain scenes.

Transparency is the only thing that gets drawn as individual triangles
at the moment: points and lines also get drawn in immediate mode, but
they could be buffered up as per triangles if required.


-dair (possibly so could transparent triangles: provided glDrawElements
was guaranteed to draw in order, so we'd know that our sorting would be
honoured)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Another small optimization: aglMacro

[Dair G. <da...@re...>]

James W. Walker wrote:

>On the OpenGL list, it has been mentioned that one can get a small=20
>performance boost by using the macro interfaces to OpenGL.

I've always shied away from using this technique personally, as it
really is pretty ugly... :-)


>However some Quesa internal functions would need an extra=20
>parameter.

Plus we'd need extra local variables, if I understand the setup
correctly, i.e., we'd have to have a local agl_ctx in each routine that
made a GL call which was initialised to the context in the instance
data?


>I expect that in most cases the gain would be small, maybe 1%.=20
>However the "multibox" test went up from 4.7 FPS to 5.0 FPS with this
>change.  This would not affect platforms other than Mac.  Any
>comments, or objections to my checking it in?

A 6% change isn't normally something to ignore, but I'd be curious to
see if you get any impact in other tests?

The multibox test I'd expect to spend most of its time updating the view
stack: i.e., showing the cost of per-object processing within Quesa
rather than rendering time (and a lot of that is probably the bogus view
state stack updates on pop).

Normally this only really helps for immediate mode drawing, where you're
doing N-thousand glVertex calls or whatever: as Frank says that's the
case for the transparent path, but shouldn't happen normally.

So I'm kind of surprised you did get anything out of it actually. :-)=20


-dair (I wonder if the place we're saving the time is in IRUpdate.c: we
probably make more GL state calls in there than we do GL drawing calls,
and I bet most of them are happening because of the excessive view state
stack updates)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: View stack state

[Dair G. <da...@re...>]

James W. Walker wrote:

>It appears that the stackState->stackState member of the view stack=20
>frame always has the value kQ3ViewStateAll, which means that all=20
>sorts of OpenGL state gets reset every time you pop the stack.  Was=20
>there some unfinished plan to make this behave more sensibly?

Hmm, yes, you're right - looks like that never got finished off.

The idea was to be able to keep track of what's changed at each level of
the stack, so that when we pop the stack we're able to update only those
bits of state which actually changed in the corresponding push.

But at the moment we start it off as kQ3ViewStateAll, and never keep
track of things as they're added: so end up with clearing everything on
each pop.

Do you want to fix it up to work properly, or log a bug so that we know
it could be improved?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Another small optimization: aglMacro

[Frank C <li...@si...>]

On 17-Apr-04, at 3:28 AM, James W. Walker wrote:

> On the OpenGL list, it has been mentioned that one can get a small 
> performance boost by using the macro interfaces to OpenGL.  Basically, 
> this means that instead of relying on a current context, you pass the 
> OpenGL context to each OpenGL call.  Macro definitions hide the extra 
> parameters, so that the individual calls to OpenGL do not look any 
> different.  However some Quesa internal functions would need an extra 
> parameter.  I expect that in most cases the gain would be small, maybe 
> 1%.  However the "multibox" test went up from 4.7 FPS to 5.0 FPS with 
> this change.  This would not affect platforms other than Mac.  Any 
> comments, or objections to my checking it in?

Using the macros can boost immediate mode rendering by a fair amount 
but they have much less of an effect when using vertex arrays since 
function call overhead is already small in those cases. Can't hurt 
either way though, and IIRC, the transparent pass and some other 
special cases are drawn in immediate mode so it could help quite a bit 
for certain scenes.

Frank.

Another small optimization: aglMacro

[James W. W. <os...@jw...>]

On the OpenGL list, it has been mentioned that one can get a small 
performance boost by using the macro interfaces to OpenGL.  Basically, 
this means that instead of relying on a current context, you pass the 
OpenGL context to each OpenGL call.  Macro definitions hide the extra 
parameters, so that the individual calls to OpenGL do not look any 
different.  However some Quesa internal functions would need an extra 
parameter.  I expect that in most cases the gain would be small, maybe 
1%.  However the "multibox" test went up from 4.7 FPS to 5.0 FPS with 
this change.  This would not affect platforms other than Mac.  Any 
comments, or objections to my checking it in?
--
<http://www.jwwalker.com/>

View stack state

[James W. W. <ja...@wr...>]

It appears that the stackState->stackState member of the view stack 
frame always has the value kQ3ViewStateAll, which means that all 
sorts of OpenGL state gets reset every time you pop the stack.  Was 
there some unfinished plan to make this behave more sensibly?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Quesa - offscreen draw context panes

[Dair G. <da...@re...>]

James W. Walker wrote:

>That's a possibility.  I suppose Quesa should at least post a warning=20
>if the OpenGL viewport limit is being exceeded.

Hi guys,

Sorry - I missed these messages go past, as they've been sent to
quesa-cvs rather than quesa-develop? I have a rule to flag things in
quesa-cvs as read automatically (as it's normally just cvs notifications
that go in there: that list doesn't get archived either BTW, so it can't
be searched).

If there's an enum we can query to figure out what the limits are
(perhaps GL_MAX_VIEWPORT_DIMS?), posting a warning sounds like a good
idea to me.


>>> Or will I have to wait for the OpenGL guys to fix their bug?
>>
>> I filed an enhancement request in Apple's bug database requesting a=20
>> bigger viewport limit in the OpenGL software renderer.  Why don't you=20
>> do that too?  More bug reports might raise the priority.
>
>Maybe, or would it be better to file it with the OpenGL people=20
>directly. Apple tend to fob us off suggesting its open source and
>if we want it fixed we should fix it ourselves.

Although there's a couple of open source implementations of OpenGL (Mesa
is GPL, and I believe SGI have put out a "reference implementation"
under their own licence as well), Apple's implementation is separate.

If filing a bug doesn't do anything, perhaps we should think about
handling this in Quesa itself?

This wouldn't need to happen at the renderer level, as a renderer could
return some "these are the max coords I can render to" values and the
library could then do the tiling on top using multiple passes?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Optimisation

[Dair G. <da...@re...>]

Roger Holmes wrote:

>Oops, I meant viewMode not viewState throughout my original e-mail.
>They both get set at the same time and I clicked (and copied) the
>wrong one in the source before pasting multiple times into the e-mail.

Ah, OK, I understand now. I knew I must be missing something... :-)


>The test of instanceData->pickDecomposeCount =3D=3D 0 gets put into the
>picking routines, as does the call to E3View_PickStack_SaveObject.

OK, got it.


>and call, but I rejected this as I was not ABSOLUTELY sure that
>pickDecomposeCount could not change in the submit method itself.

At the moment it won't, but it's probably better not to require that: I
suppose it's possible that we may want to allow it at some point in the
future, so it'd be good not to rule it out if we don't have to.


>No, a lot more than that. The switch, several tests, the call to
>E3ClassTree_GetClassByType and for me it seems a lot cleaner way of
>coding it, though there is nothing wrong with the original, its just
>that things have got tacked on afterwards.

Yes, it really comes down to which way is most likely to grow: are we
more likely to add new submit methods (picking, rendering, etc) than
ways (retained vs immediate) of submitting.

At the time it was written we were still adding the methods, so having 2
routines with a switch that could be extended felt simpler than N
routines with no switch.


>When I step through it whilst debugging, I keep thinking "Oh, get on
>with it, why is there so much overhead before actually doing the real
>work?". The fact that it shows up in 'Shark' is a good reason too!

If it shows up as significant in a profiler then it makes sense to
improve it: it will mean adding a new submit method is a bit more
involved, but not terribly so (and like you say, both sides are fairly
stable now).

I guess my main objection to more routines is that E3View.c is big
enough as it is - but at some point we should probably try breaking the
bigger objects down into some kind of sub-categories:

  View/
    E3View.c
    E3View_Submit.c
    E3View_State.c
  Math/
    E3Math.c
    E3Math_Matrix.c
    E3Math_Vector.c
=20
The divison will be pretty arbitrary, but even splitting it in 3 say
would be handy.

So, go ahead - feel free to check this in.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/