quesa-develop — Mailing list for Quesa development

Re: Ideas on the future of Quesa.

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

Roger Holmes <rog...@mi...> wrote:

>Ok so I was trying to gather your comments on virtual functions and you
>seem to be dead set against them, but so was I at first. If you are
>still
>against them after reading this I will drop the idea. 0xDEADD0D0.
>
>But first inheritance. The instance data of a Quesa sub class is ideally
>held in memory just after the base class's data. That way we can
>allocate
>just one block of data for all the instance data of a leaf class and
>all its
>base classes in one go, and we do not have to follow a chain of pointers
>to find a particular sub class's instance data. This has shown a great
>performance boost for processing and rendering of complex documents.
>Of course we could do this with structs, by defining a first data member
>to be the base class's instance data, but we do want to keep the data
>private to a class and not have it messed about with by derived classes,
>so to have a struct/class inherit all the data members from its base
>class
>privately is the only way to do this properly. Of course this also
>inherits
>the methods but if we don't want this then we just don't define any
>methods.

If you can speed up access to instance data without compromising 
extensibility, that would be great.

>Virtual methods. The other big speed up I made in Quesa was by
>implementing in C the closest thing I could to a C++ VTable. I could
>bring this code forward into cvs Quesa but the thought of allowing the
>C++ compiler to do it for me is appealing as it is simper, less prone to
>error and more readable. Where there is now a hash table look up for
>a method we would instead use a virtual method. This would not of
>course affect the API, just as the API does not expose the existing
>functionality. There is of course the problem of extensibility. It might
>be possible to have an extension class which would get called for
>extension classes and would then vector off in the existing way.
>However, apart from renderers, how many of us have actually
>extended Quesa, I have but I would be very happy to modify my
>extension into clean C++ classes linked into Quesa instead of the
>horrid mess of meta handlers and multiple functions which
>were necessary with the closed source library QD3D.
>
>So have I talked you around?

I'm still concerned about extensibility.  I've written lots of custom 
elements and have plans for custom renderers.  With the current 
setup, it is theoretically possible for a plugin renderer to derive 
from the built-in IR, using Q3XObjectClass_GetMethod to get an IR 
function pointer.  If the IR methods were C++ methods, they would 
have a different function signature.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Ideas on the future of Quesa.

[Jose' C. <cru...@ce...>]

Il giorno 30/nov/04, alle 17:35, Roger Holmes ha scritto:


> However, apart from renderers, how many of us have actually
> extended Quesa, I have but I would be very happy to modify my
> extension into clean C++ classes linked into Quesa instead of the
> horrid mess of meta handlers and multiple functions which
> were necessary with the closed source library QD3D.
>


mostly agreed whith the missing part, but for virtual functions I've to 
disagree
the exposed functions (those with signature) should be implemented via 
custom vtable, and we should also leave the hash table in place to 
extend existing classes with non anticipated pluggable methods

why?
one are the canonical plug-ins (renderers, file formats (custom 
attributes are in another league))
second is the possibility to extend the current objects much as the 
3dmf writer does

of course internally we can code it as virtual functions, but there's 
no point then because we have to call them via the custom vtable

or you can found a better way to do this...


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Ideas on the future of Quesa.

[Lane R. <la...@if...>]

on Tue, Nov 30, 2004 Roger Holmes may have said:

>> One of the major problems on the games we see on the games we port is
>> that CW/gcc do a terrible job of keeping simple C++ objects like a
>> vector tuple in registers - so overloading "+" to give you a vector
>> addition for "x + y" will often generate truly dire code compared to
>> adding the fields yourself.
>
>But the code is so much more readable, computers are getting faster
>all the time and compilers are becoming more efficient. Microspot
>could not maintain big chunks of 3DWorld without operator overloading.
>A single line of code would have to become a dozen statements with
>temporary variables, awkwardly named procedure calls with & operators
>spread about all over the place. As you say, 'everyone feels differently
>about what's good and what's bad about C++'. How do you other
>guys think about operator overloading for vectors, points and matrices=3F

Having worked on a lot of code, operator overloading is one of my biggest
complaints. Beyond speed (Quesa isn't a speed deamon, requiring 100% of
the CPU on a 2.6Ghz machine to render 75 fps in Bugdom!) I find such code
much harder to maintain. It is probably true that for the original
programmer it's easier; but when someone knew comes in it simply hides
too much very important information.

>could not maintain big chunks of 3DWorld without operator overloading.
>A single line of code would have to become a dozen statements with
>temporary variables, awkwardly named procedure calls with & operators
>spread about all over the place

Why=3F Any operation that you would want to overload should be able to
become an inlined function call just as easily. The actual operation code
remains nearly identical. (at least in my experience.)

=46rom someone who's still trying to get the latest builds to work in my
products, I'd rather see easily read/understood/maintainable code. The
more programmers who can read the code and =5Freally=5F understand what's
happening the more contributions to that code base you will get.

My experience says that OS projects benefit more from source that is well
documented and easy to figure out than source that "does things the right
way" (no matter which way that is!) The more templates, overridden
operators and virtual doubly inherited functions you have the more time
it will take a new coder to figure out the source in order to work on it
and the less likely that coder will be to contribute. Just my experience
from several open source projects.

Of course, if the main programmers on a project are not happy with the
way the source is being worked on the project is certainly dead; so ... :)

Before I forget, Thanks Dair ... without your work two of my products
would not have even been possible :)


Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Since the Internet has no walls or fences, who needs Windows or Gates=3F

Re: Ideas on the future of Quesa.

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

Thank you Dair, a very BIG thank you. I hope we can manage without you.


> - Don't lose abstraction unless you really need it. I'm quite pleased
> with the way the internals turned out, in that we kept a very OOish
> style internally (where each .c file exposes some opaque types and
> functions to work on those types; so geometry code doesn't see any
> details of cameras, etc).

The reason for my proposal to use C++ in Quesa is that we can use
the 'private' keyword to keep the internal details of a class private
whilst allowing us to have it in the e3xxx.h file and subclass from it,
which gives us better efficiency.

If that is as far as we can agree to go then that is fine with me, but
I think there are other benefits of C++ which we could usefully use.
I am not advocating the gratuitous use of C++'s more exotic features,
just where there are real benefits in terms of either efficiency or
readability.

> - Keep the plug-in renderer idea. This is one of the nicest things 
> about
> QD3D/Quesa IMO, the idea that the organisation side of things is
> completely separate from the rendering side.

Absolutely.

> - Think about changing data structures. The public QD3D types have
> several limitations; vectors/colours are triples rather than quads (so
> not so amenable for AltiVec processing),

Yes, now the G3 is almost history we should be thinking seriously about
an AltiVec version of Quesa. 3DVector type should have a 0.0 as its 
fourth
element and 3DPoint should have 1.0 as the fourth element. Should
colours have the alpha as the fourth element?


>  and the structures don't have size fields in them.

> One of the problems with the QD3D API is that, like a C++ API, it's not
> good for backwards compatibility. Not saying that MS has all the
> answers, but the Win32 style of having a size field at the start of 
> each
> structure at least gives you the option of adding new fields without
> breaking older apps (although nowadays the Carbon approach of opaque
> types and generic accessor functions is probably better).

So are we talking about accessor functions for 3DPoint etc? That seems a
bit over the top to me. Quesa's object are already opaque. I know we do
tend to store the Q3xxxdata structures in them but that is up to us to 
change
if we need to change the internal representation we can do so easily. I 
don't
understand this, could someone explain?

> - Look at GL/D3D. The way data (texture and geometry) is submitted to
> cards has changed quite a bit since the RAVE time frame, and the key to
> getting good performance nowadays is to minimise the interaction the 
> CPU
> has with the data and submit data in as large a batch as possible.

> Ideally you just want to have the data in memory somewhere, give the
> card a pointer to it, and let it handle the transfer itself (with a VBO
> style lock/unlock to synchronise access).
>
> - Look at some other scene graphs. We kept ourselves focused on just
> doing QD3D initially, which I think was a good plan (as it meant things
> didn't go off in a hundred different directions), but there are other
> libraries out there which have good ideas.
>
> Wouldn't hurt to take a look at some of them, as exposing something 
> like
> shading languages will need to be done in a similar way (no point in
> inventing our own shading language, but we should have something that
> lets you plug in either ARB or D3D shaders).

I know very little about these aspects of Quesa so will leave it to 
others to comment.

> - Keep the history. Even if you move on to using subversion at some
> point, I would recommend keeping as much of the CVS history as 
> possible.

Yes.

>
> We don't go all the way back to 1999, which is something I always
> regretted, but I think it's useful to be able always get back to older
> versions. If some planned development doesn't work out, that means you
> can then rewind N months and easily start again.
>
> - Keep the licence. Switching from the LGPL to BSD solved a lot of
> problems for me at work, and allowed me to use the math sections of
> Quesa in our D3D->GL translation library. The GPL licences wouldn't
> have.

Yes.

>
> - Think about a CoreFoundation approach. Something that's worked well
> for Apple is to have a CoreFoundation library which provides basic
> primitives (strings, sets, etc) and then have other libraries built on
> top.
>
> Something similar could help popularise the library and make it easier
> for people to dip into. E.g., regular requests on the mac-opengl and
> mac-games-dev lists are requests for file format readers and 3D math
> code. So:
>
> - 3D math library. All the standard operations, intersections, etc; you
> could see this growing into more general purpose fields like collision
> detection, visibility tests, or physics.
>
> - 3D file format parser (harness that would register N plug-ins for
> doing IO, the plug-ins parse their data and return it back via 
> callbacks
> with some type info.
>
> Means that people could link to the file format library, and get called
> back as objects are parsed out of the file; the object description
> allows them to build their own data structure out of it. Quesa would
> also link to the file format library, and have a set of callbacks that
> build Quesa objects out of the data.
>
> I know we moved the Viewer library into Quesa so we could have a single
> shared library for users, but think of these more like the plug-in
> renderers.
>
> I.e., a well defined interface between them and the rest of Quesa, and
> build them (and perhaps even the plug-in renderers) as static libraries
> that then get linked into the Quesa shared library.
>
> For this to work the interface would need to be 100% independent; i.e.,
> you would need to be able to say "I just want to use the math library"
> and know exactly what headers/.lib files were needed for your app (and
> the math library couldn't call anything in Quesa; it would have to sit
> under everything - perhaps need a CF-style library to hold truly common
> bits below these utility libraries).

For the future, will try to bear them in mind.

>
> - Split up the source files. Some of them (math, camera, etc) are
> getting too large and could benefit from what happened to E3Geometry.c.
>
> I.e., have an E3Camera.c for the common stuff; then put the individual
> camera types into their own E3CameraFoo.c files. If you're thinking
> about C++ this would be a good first step, as it means you then have 
> one
> C++ object per source file and keep everything well separated.

Or maybe a few very simple objects.

>
> - Don't go crazy. :-) One of the problems with C++ IMO is that it's 
> very
> easy to create systems that are just unmaintainable. Everyone feels
> differently about what's good and what's bad about C++, but I've seen
> plenty of projects that just got out of control when they started 
> taking
> a "C++ purist" view of things rather than the pragmatic view.

I agree entirely.

>
> The STL is definitely a useful source for all the standard data types
> (lists, vectors, hash tables, etc), but I would be wary of going
> overboard with stuff like operator overloading.
>
> One of the major problems on the games we see on the games we port is
> that CW/gcc do a terrible job of keeping simple C++ objects like a
> vector tuple in registers - so overloading "+" to give you a vector
> addition for "x + y" will often generate truly dire code compared to
> adding the fields yourself.

But the code is so much more readable, computers are getting faster
all the time and compilers are becoming more efficient. Microspot
could not maintain big chunks of 3DWorld without operator overloading.
A single line of code would have to become a dozen statements with
temporary variables, awkwardly named procedure calls with & operators
spread about all over the place. As you say, 'everyone feels differently
about what's good and what's bad about C++'. How do you other
guys think about operator overloading for vectors, points and matrices?

> Similarly for exceptions - I've yet to see a project where they helped,
> but have seen several where they were the beginning of the end. :-)

I am very happy to keep exceptions either out of Quesa or entirely
contained within it. We (Microspot) have wrappers for all of the
Quesa routines which throw exceptions on an error. That way we
can use the function result for what its intended for - the result of
the calculation and not for an incidental fact that there was not an
error. I would soon tire of writing code with every line being an
if statement testing for errors, but I guess that's what the rest of
you have been happy with for the last few years.

> But I'm sure you guys have your own ideas, so feel free to take the
> project in whatever way makes sense for you.

Thanks.

> I've had a lot of fun working on Quesa, and definitely learned a lot
> about what works and what doesn't (both 3D and otherwise).
>
> I'll stay on the list for a day or so, but will be unsubscribing later
> this week - my email will be dair AT refnum.com for the forseeable
> future, so feel free to drop me a line if you want my 2 pence on
> anything. :-)
>
> But for now, have fun - and good luck!

Thanks, we will try.




On Monday, November 29, 2004, at 10:42  pm, Jose' Cruanyes wrote:

> Given that the external API doesn't change...

Of course, but the API is large there may be parts of it which nobody 
actually uses.

> I've to second James on this, and my proposal is:
>
> + C++,
> 	I think averybody agree
> + few STL and few exceptions,
> 	containers, iterators and functors when it makes sense, not to 
> templatize everyting,
> 	exceptions inside Quesa

So I think this boils down to using these when they are in a standard 
library, and not define any of our own.
That sounds a sensible approach. Of course we can still discuss 
breaking this rule if everyone agrees in
a particular instance, but none of us will do so without approval from 
the others. Nearly every use of STL
will need to be wrapped in a try{}catch(...) as a minimum.


> + inheritance
> 	yes the class hierarchy is best described by inheritance, BUT no 
> virtuals functions to implement the API, instead I'll make an array of 
> function pointers in the class with a slot for every kind of api 
> function ( a shortcut to the metahandler) and a hashtable  to plugin 
> methods
>
> so
> instance.tablePtr = &class.functionArray[];
> instance.hashtablePtr = &class.hashtable;
>
> the functionArray is initialized by the class constructor, so it's 
> overriden while the class object is constructed
>
> creating the virtual methods with a custom method table, allows the 
> creation with plug-ins via the plug-in metahandler
>
> this way allows us also a mild transition. create the C++ base classes 
> and derive the others via the metahandler, when things works, begin 
> changing the implementation of derived classes in C++.

This is certainly the first thing to do, and is my main reason for 
proposing it. As for
virtual functions see below.


On Monday, November 29, 2004, at 06:53  pm, James W. Walker wrote:

>> But as a straw pole are we in favor of a real C++ implementation 
>> using inheritance, virtual methods but with no exceptions to replace 
>> the current C based E3 files. Yes or No.
>
> If I had to say just Yes or No on that, I guess I'd have to say No. I 
> think it might be better to use exceptions (and constructors and 
> destructors) than to use inheritance and virtual methods.  As I said 
> in another message, you can't really use STL without using exceptions 
> to some degree.
>
> I'd like to hear more about how you envision using inheritance and 
> virtual methods.  It's not clear to me how we could use inheritance 
> for the Quesa object hierarchy without losing the ability to extend it 
> with plugins, but maybe that's not what you had in mind.


Ok so I was trying to gather your comments on virtual functions and you
seem to be dead set against them, but so was I at first. If you are 
still
against them after reading this I will drop the idea. 0xDEADD0D0.

But first inheritance. The instance data of a Quesa sub class is ideally
held in memory just after the base class's data. That way we can 
allocate
just one block of data for all the instance data of a leaf class and 
all its
base classes in one go, and we do not have to follow a chain of pointers
to find a particular sub class's instance data. This has shown a great
performance boost for processing and rendering of complex documents.
Of course we could do this with structs, by defining a first data member
to be the base class's instance data, but we do want to keep the data
private to a class and not have it messed about with by derived classes,
so to have a struct/class inherit all the data members from its base 
class
privately is the only way to do this properly. Of course this also 
inherits
the methods but if we don't want this then we just don't define any 
methods.

Virtual methods. The other big speed up I made in Quesa was by
implementing in C the closest thing I could to a C++ VTable. I could
bring this code forward into cvs Quesa but the thought of allowing the
C++ compiler to do it for me is appealing as it is simper, less prone to
error and more readable. Where there is now a hash table look up for
a method we would instead use a virtual method. This would not of
course affect the API, just as the API does not expose the existing
functionality. There is of course the problem of extensibility. It might
be possible to have an extension class which would get called for
extension classes and would then vector off in the existing way.
However, apart from renderers, how many of us have actually
extended Quesa, I have but I would be very happy to modify my
extension into clean C++ classes linked into Quesa instead of the
horrid mess of meta handlers and multiple functions which
were necessary with the closed source library QD3D.

So have I talked you around?

Roger.

[ quesa-Bugs-1027379 ] Windows CW project has incorrect access paths

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

Bugs item #1027379, was opened at 2004-09-13 10:27
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027379&group_id=45158

Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Lane Roathe (raving)
>Assigned to: James W. Walker (jwwalker)
Summary: Windows CW project has incorrect access paths

Initial Comment:
The CW project for Quesa Windows has incorrect access
paths;

{Compiler}Win32-x86 Support/Includes
{Compiler}Win32-x86 Support/Libraries
{Compiler}Win32-x86 Support/Libraries/Win32SDK

This should be:

{Compiler}Win32-x86 Support

as everyone's support folder can differ (greatly). For
example, if you update the DirectX SDK you will no
longer have ddraw.h in the includes folder, instead it
will be in DXSDK/Includes.


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

>Comment By: James W. Walker (jwwalker)
Date: 2004-11-29 18:04

Message:
Logged In: YES 
user_id=433183

Fixed.

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

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

Re: Ideas on the future of Quesa - Thanks to Dair

[Jose' C. <cru...@ce...>]

Il giorno 29/nov/04, alle 19:53, James W. Walker ha scritto:

> Peter Michelsen <Pet...@mi...> wrote:
>
>> But as a straw pole are we in favor of a real C++ implementation 
>> using inheritance, virtual methods but with no exceptions to replace 
>> the current C based E3 files. Yes or No.
>
> If I had to say just Yes or No on that, I guess I'd have to say No. I 
> think it might be better to use exceptions (and constructors and 
> destructors) than to use inheritance and virtual methods.  As I said 
> in another message, you can't really use STL without using exceptions 
> to some degree.
>
> I'd like to hear more about how you envision using inheritance and 
> virtual methods.  It's not clear to me how we could use inheritance 
> for the Quesa object hierarchy without losing the ability to extend it 
> with plugins, but maybe that's not what you had in mind.
> -- 

Given that the external API doesn't change...

I've to second James on this, and my proposal is:

+ C++,
	I think averybody agree
+ few STL and few exceptions,
	containers, iterators and functors when it makes sense, not to 
templatize everyting,
	exceptions inside Quesa
+ inheritance
	yes the class hierarchy is best described by inheritance, BUT no 
virtuals functions to implement the API, instead I'll make an array of 
function pointers in the class with a slot for every kind of api 
function ( a shortcut to the metahandler) and a hashtable  to plugin 
methods

so
instance.tablePtr = &class.functionArray[];
instance.hashtablePtr = &class.hashtable;

the functionArray is initialized by the class constructor, so it's 
overriden while the class object is constructed

creating the virtual methods with a custom method table, allows the 
creation with plug-ins via the plug-in metahandler

this way allows us also a mild transition. create the C++ base classes 
and derive the others via the metahandler, when things works, begin 
changing the implementation of derived classes in C++.


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Ideas on the future of Quesa.

[Jose' C. <cru...@ce...>]

Il giorno 29/nov/04, alle 13:21, Dair Grant ha scritto:


> So, I think the time has come for me to move on from Quesa - and to
> leave it in the capable hands of the other developers.

Dair It has been a great pleasure work with you,
Looking forward to meet you some time by person (I'm 45 mins away from=20=

Bergamo, that is 19=80 away from London (ryan air), if you want a=20
Spaghetti meal, just email me) (invitation extended to anyone else in=20
the list)


> But here we are, 5 years on, with shipping apps built on top of it: so=20=

> I
> think that has to be a success. :-)

I think so..

> - Don't lose abstraction unless you really need it. I'm quite pleased
> with the way the internals turned out, in that we kept a very OOish
> style internally (where each .c file exposes some opaque types and
> functions to work on those types; so geometry code doesn't see any
> details of cameras, etc).

yes it has been a good work on your part

>
> - Keep the plug-in renderer idea. This is one of the nicest things=20
> about
> QD3D/Quesa IMO, the idea that the organisation side of things is
> completely separate from the rendering side.

Absolutely


> - Keep the history. Even if you move on to using subversion at some
> point, I would recommend keeping as much of the CVS history as=20
> possible.
>
> We don't go all the way back to 1999, which is something I always
> regretted, but I think it's useful to be able always get back to older
> versions. If some planned development doesn't work out, that means you
> can then rewind N months and easily start again.

Absolutely... I've every single public mail about quesa archived since=20=

your original announce

>
> - Keep the licence. Switching from the LGPL to BSD solved a lot of
> problems for me at work, and allowed me to use the math sections of
> Quesa in our D3D->GL translation library. The GPL licences wouldn't
> have.
>
> - Think about a CoreFoundation approach. Something that's worked well
> for Apple is to have a CoreFoundation library which provides basic
> primitives (strings, sets, etc) and then have other libraries built on
> top.

>
> - 3D math library. All the standard operations, intersections, etc; =
you
> could see this growing into more general purpose fields like collision
> detection, visibility tests, or physics.

Absolutely

>
> - 3D file format parser (harness that would register N plug-ins for
> doing IO, the plug-ins parse their data and return it back via=20
> callbacks
> with some type info.
>
> Means that people could link to the file format library, and get =
called
> back as objects are parsed out of the file; the object description
> allows them to build their own data structure out of it. Quesa would
> also link to the file format library, and have a set of callbacks that
> build Quesa objects out of the data.

I think it's simpler to build quesa objects and let's others extract=20
from there that declare a bunch of call backs

>
> I know we moved the Viewer library into Quesa so we could have a =
single
> shared library for users, but think of these more like the plug-in
> renderers.
>
> I.e., a well defined interface between them and the rest of Quesa, and
> build them (and perhaps even the plug-in renderers) as static =
libraries
> that then get linked into the Quesa shared library.
>
> For this to work the interface would need to be 100% independent; =
i.e.,
> you would need to be able to say "I just want to use the math library"
> and know exactly what headers/.lib files were needed for your app (and
> the math library couldn't call anything in Quesa; it would have to sit
> under everything - perhaps need a CF-style library to hold truly =
common
> bits below these utility libraries).

yes it's a clean approach


> - Don't go crazy. :-) One of the problems with C++ IMO is that it's=20
> very
> easy to create systems that are just unmaintainable. Everyone feels
> differently about what's good and what's bad about C++, but I've seen
> plenty of projects that just got out of control when they started=20
> taking
> a "C++ purist" view of things rather than the pragmatic view.
>
> The STL is definitely a useful source for all the standard data types
> (lists, vectors, hash tables, etc), but I would be wary of going
> overboard with stuff like operator overloading.

Absolutely I'll always vote for C+-


> But for now, have fun - and good luck!
>
>
> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real=20
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

[ quesa-Bugs-902975 ] Use shared texture namespace

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

Bugs item #902975, was opened at 2004-02-23 13:01
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902975&group_id=45158

Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use shared texture namespace

Initial Comment:
The OpenGL renderer should create contexts with a shared texture 
namspace, to allow them to share texture objects.

May need a bit of thought to make sure the are updated correctly 
when the texture objects are updated, but it might be a useful 
optimisation memory- wise.


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

>Comment By: James W. Walker (jwwalker)
Date: 2004-11-29 13:11

Message:
Logged In: YES 
user_id=433183

I have checked in changes to implement texture sharing on Mac OS X 
and Windows.  It should not be too hard to extended it to X11 and Cocoa 
too, but I do not have the expertise to do that.

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

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

Re: Ideas on the future of Quesa - Thanks to Dair

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

Peter Michelsen <Pet...@mi...> wrote:

>But as a straw pole are we in favor of a real C++ implementation 
>using inheritance, virtual methods but with no exceptions to replace 
>the current C based E3 files. Yes or No.

If I had to say just Yes or No on that, I guess I'd have to say No. 
I think it might be better to use exceptions (and constructors and 
destructors) than to use inheritance and virtual methods.  As I said 
in another message, you can't really use STL without using exceptions 
to some degree.

I'd like to hear more about how you envision using inheritance and 
virtual methods.  It's not clear to me how we could use inheritance 
for the Quesa object hierarchy without losing the ability to extend 
it with plugins, but maybe that's not what you had in mind.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Ideas on the future of Quesa.

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

Do we still want to claim to support BeOS?  We never really did, 
right?  At least, the Be functions in GLDrawContext.c are just stubs.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Ideas on the future of Quesa.

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

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

>It's always easier to work on this kind of project if you have a product
>that actually uses it, but without that motivation you're fighting a
>losing battle against a)projects that bring in your salary and b)your
>non-work life.
>
>
>So, I think the time has come for me to move on from Quesa - and to
>leave it in the capable hands of the other developers.

Understandable.  Thanks for all your work on Quesa.

Now that Quesa on SourceForge has 6 full-fledged project admins,  is 
there still a Steering Committee that separates me and Roger Holmes 
from the other admins?

...
>Similarly for exceptions - I've yet to see a project where they helped,
>but have seen several where they were the beginning of the end. :-)

You can't really use STL without using exceptions, since STL classes 
throw exceptions.  Of course you can go overboard with anything.  I 
do want us to continue having a C public API, so no exceptions can be 
allowed to escape from Quesa.

-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Ideas on the future of Quesa - Thanks to Dair

[Peter M. <Pet...@mi...>]

Firstly, I would like to say a big thank-you to Dair for all the work 
he has put into Quesa. Sheer volume and quality of the code is 
staggering. So from all at Microspot Thank-you.

Secondly, we are currently reading through the suggestion from both 
Dair and other people about what to do next.

But as a straw pole are we in favor of a real C++ implementation using 
inheritance, virtual methods but with no exceptions to replace the 
current C based E3 files. Yes or No.

Peter Michelsen.

Re: Ideas on the future of Quesa.

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

Jose' Cruanyes wrote:

>>> that's just using inlines or reworking the internals to make the=20
>>> Quesa classes real C++ classes with inheritance and the like?
>>
>> When working on texture sharing code recently (not yet checked in) I=20
>> had to deal with dynamic arrays, and wished that I could just use=20
>> std::vector.
>
>not that I'm contrary, the reasons for the decision taken 5 years ago=20
>(not general support for STL in compilers) had been superseded,

This is definitely true - when we started (1999), STL implementations
still had plenty of annoying differences between platforms.

That's still true for some cases, but all of the common container stuff
(vector, list, map, etc) is now pretty portable (apart from
vendor-specific extensions obviously :-).


This mail has been a long time coming, but Peter's mail gave me the
nudge I needed to make a decision.

So, as I'm sure everyone has seen, for most of this year I've not really
had any time free for Quesa. Things are just too busy at work, and we
don't have any projects there that use Quesa.

It's always easier to work on this kind of project if you have a product
that actually uses it, but without that motivation you're fighting a
losing battle against a)projects that bring in your salary and b)your
non-work life.


So, I think the time has come for me to move on from Quesa - and to
leave it in the capable hands of the other developers.

I'm glad that people have found the project useful, and to be honest if
you'd asked me before we started if this project would still be going 5
years later I'd have said our chances weren't high.

But here we are, 5 years on, with shipping apps built on top of it: so I
think that has to be a success. :-)


Where we go from here is up to you guys - if you want to replace the
internals with C++ objects, go for it.

The kind of things I think are useful are:

- Bring the general side up to the final state of QD3D. Which bits are
important depends on what you use in your apps, but I think the two most
significant things are probably the remaining IO bits and visibility
culling.

- Bring the rendering side up to the current state of GL/D3D. That means
texture combines, render-to-texture, using VBOs for geometry data,
vertex and pixel shaders, etc.

Unfortunately the nature of GL means that a lot of those are exposed
through extensions that may/may not be present; but setting a base
supported OS and having some feature querying system to check what's
available would let features turn on/off as they're present.

- Don't lose abstraction unless you really need it. I'm quite pleased
with the way the internals turned out, in that we kept a very OOish
style internally (where each .c file exposes some opaque types and
functions to work on those types; so geometry code doesn't see any
details of cameras, etc).

It's sometimes necessary to break that for efficiency, but that really
is the exceptional case rather than the default. Given that computers
always get faster, and code always gets more complex, you can almost
never have too much abstraction. ;-)

- Keep the plug-in renderer idea. This is one of the nicest things about
QD3D/Quesa IMO, the idea that the organisation side of things is
completely separate from the rendering side.

The overhead of doing this is pretty minimal (call through a function
pointer), but it means you have a clean separation between Quesa and its
renderers.

- Think about changing data structures. The public QD3D types have
several limitations; vectors/colours are triples rather than quads (so
not so amenable for AltiVec processing), and the structures don't have
size fields in them.

One of the problems with the QD3D API is that, like a C++ API, it's not
good for backwards compatibility. Not saying that MS has all the
answers, but the Win32 style of having a size field at the start of each
structure at least gives you the option of adding new fields without
breaking older apps (although nowadays the Carbon approach of opaque
types and generic accessor functions is probably better).

- Look at GL/D3D. The way data (texture and geometry) is submitted to
cards has changed quite a bit since the RAVE time frame, and the key to
getting good performance nowadays is to minimise the interaction the CPU
has with the data and submit data in as large a batch as possible.

Ideally you just want to have the data in memory somewhere, give the
card a pointer to it, and let it handle the transfer itself (with a VBO
style lock/unlock to synchronise access).

- Look at some other scene graphs. We kept ourselves focused on just
doing QD3D initially, which I think was a good plan (as it meant things
didn't go off in a hundred different directions), but there are other
libraries out there which have good ideas.

Wouldn't hurt to take a look at some of them, as exposing something like
shading languages will need to be done in a similar way (no point in
inventing our own shading language, but we should have something that
lets you plug in either ARB or D3D shaders).

- Keep the history. Even if you move on to using subversion at some
point, I would recommend keeping as much of the CVS history as possible.

We don't go all the way back to 1999, which is something I always
regretted, but I think it's useful to be able always get back to older
versions. If some planned development doesn't work out, that means you
can then rewind N months and easily start again.

- Keep the licence. Switching from the LGPL to BSD solved a lot of
problems for me at work, and allowed me to use the math sections of
Quesa in our D3D->GL translation library. The GPL licences wouldn't
have.

- Think about a CoreFoundation approach. Something that's worked well
for Apple is to have a CoreFoundation library which provides basic
primitives (strings, sets, etc) and then have other libraries built on
top.

Something similar could help popularise the library and make it easier
for people to dip into. E.g., regular requests on the mac-opengl and
mac-games-dev lists are requests for file format readers and 3D math
code. So:

- 3D math library. All the standard operations, intersections, etc; you
could see this growing into more general purpose fields like collision
detection, visibility tests, or physics.
 =20
- 3D file format parser (harness that would register N plug-ins for
doing IO, the plug-ins parse their data and return it back via callbacks
with some type info.

Means that people could link to the file format library, and get called
back as objects are parsed out of the file; the object description
allows them to build their own data structure out of it. Quesa would
also link to the file format library, and have a set of callbacks that
build Quesa objects out of the data.

I know we moved the Viewer library into Quesa so we could have a single
shared library for users, but think of these more like the plug-in
renderers.

I.e., a well defined interface between them and the rest of Quesa, and
build them (and perhaps even the plug-in renderers) as static libraries
that then get linked into the Quesa shared library.

=46or this to work the interface would need to be 100% independent; i.e.,
you would need to be able to say "I just want to use the math library"
and know exactly what headers/.lib files were needed for your app (and
the math library couldn't call anything in Quesa; it would have to sit
under everything - perhaps need a CF-style library to hold truly common
bits below these utility libraries).

- Split up the source files. Some of them (math, camera, etc) are
getting too large and could benefit from what happened to E3Geometry.c.

I.e., have an E3Camera.c for the common stuff; then put the individual
camera types into their own E3CameraFoo.c files. If you're thinking
about C++ this would be a good first step, as it means you then have one
C++ object per source file and keep everything well separated.

- Don't go crazy. :-) One of the problems with C++ IMO is that it's very
easy to create systems that are just unmaintainable. Everyone feels
differently about what's good and what's bad about C++, but I've seen
plenty of projects that just got out of control when they started taking
a "C++ purist" view of things rather than the pragmatic view.

The STL is definitely a useful source for all the standard data types
(lists, vectors, hash tables, etc), but I would be wary of going
overboard with stuff like operator overloading.

One of the major problems on the games we see on the games we port is
that CW/gcc do a terrible job of keeping simple C++ objects like a
vector tuple in registers - so overloading "+" to give you a vector
addition for "x + y" will often generate truly dire code compared to
adding the fields yourself.

Similarly for exceptions - I've yet to see a project where they helped,
but have seen several where they were the beginning of the end. :-)


But I'm sure you guys have your own ideas, so feel free to take the
project in whatever way makes sense for you.

I've had a lot of fun working on Quesa, and definitely learned a lot
about what works and what doesn't (both 3D and otherwise).

I'll stay on the list for a day or so, but will be unsubscribing later
this week - my email will be dair AT refnum.com for the forseeable
future, so feel free to drop me a line if you want my 2 pence on
anything. :-)

But for now, have fun - and good luck!


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

Re: SetPixelFormat failing

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

"Lane Roathe" <la...@if...> wrote (in September):

>Recently I found that a SetPixelFormat call in Quesa was failing;
>specifically the line
>
>     if (!SetPixelFormat(theContext->theDC, pixelFormat, &pixelFormatDesc))
>
>in "./Renderers/Common/GLDrawContext.c"
>
>
>Nothing had changed, except I updated my video drivers. This has probably
>been the cause of almost all of my non-solvable OpenGL issues with Bugdom
>and Nanosaur with a lot of customers who purchased one of these games
>(ie, lots of refunds).
>
>Anyone have any ideas on why this would fail? It's when it's creating a
>new GL context, and the pixel format's "cColorBits" are zero (meaning, I
>would assume, the default).
>
>Anyway, the fix I found was to remove the error checking on this line;
>when removed everything works just fine.
>
>Thoughts on a "proper" solution welcome.


I was getting a SetPixelFormat error in Geom Test when I changed from 
the interactive to the wireframe renderer.  I noticed that the IR had 
requested 16 depth bits, whereas WF requested 32 bits.  When I 
changed things so that both asked for 32 bits, the error went away. 
Perhaps once you have chosen a particular depth buffer size for a 
window, you aren't allowed to change?

Also, I've seen a MS document saying that you can get SetPixelFormat 
errors if you don't have the WS_CLIPCHILDREN and WS_CLIPSIBLINGS 
window styles on a window use for OpenGL.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

[ quesa-Bugs-1005268 ] Resizing contexts should not force a rebuild

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

Bugs item #1005268, was opened at 2004-08-07 14:13
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1005268&group_id=45158

Category: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
Summary: Resizing contexts should not force a rebuild

Initial Comment:
Currently, Quesa will forcefully rebuild a GL context when it is 
resized. This leads to a UI hang while Quesa reloads all active 
textures, and can adversely affect application with freely sizable 
windows/panes even with just a few textures loaded.

The problem however is two-fold...

Quesa must first handle resizes within the library, by providing a 
GLDrawContext_UpdateSize function in GLDrawContext.c. All 
renderers must catch resize flags 
(kQ3XDrawContextValidationWindowSize and 
kQ3XDrawContextValidationPane) in their StartFrame function and 
call GLDrawContext_UpdateSize instead of forcing a context 
rebuild.

Once the library can handle context resizing, some applications 
may require modification to take advantage of this functionality. 
The Qut framework for example, creates a new context when a 
window is resized, but it should really let Quesa handle that 
internally.

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

>Comment By: James W. Walker (jwwalker)
Date: 2004-11-27 18:08

Message:
Logged In: YES 
user_id=433183

This is now fixed on Mac and Windows.  (I wish SourceForge offered a 
resolution of "fixed on some platforms.")

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

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

Re: Ideas on the future of Quesa.

[Jose' C. <cru...@ce...>]

Il giorno 27/nov/04, alle 15:57, James W. Walker ha scritto:

>> that's just using inlines or reworking the internals to make the 
>> Quesa classes real C++ classes with inheritance and the like?
>
> When working on texture sharing code recently (not yet checked in) I 
> had to deal with dynamic arrays, and wished that I could just use 
> std::vector.

not that I'm contrary, the reasons for the decision taken 5 years ago 
(not general support for STL in compilers) had been superseded,

in my hidden-line renderer for Quesa (not still released because 
license problems) I use many STL features (vectors, hashes, functors 
ecc)

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Ideas on the future of Quesa.

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

On Nov 26, 2004, at 10:22 PM, Jose' Cruanyes wrote:

>> . The second option is a little more radical but highly desirable in 
>> changing E3 routines to C++ format.
>
> that's just using inlines or reworking the internals to make the Quesa 
> classes real C++ classes with inheritance and the like?

When working on texture sharing code recently (not yet checked in) I 
had to deal with dynamic arrays, and wished that I could just use 
std::vector.
--
<http://www.jwwalker.com/>

[ quesa-Bugs-1005268 ] Resizing contexts should not force a rebuild

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

Bugs item #1005268, was opened at 2004-08-07 14:13
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1005268&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
>Assigned to: James W. Walker (jwwalker)
Summary: Resizing contexts should not force a rebuild

Initial Comment:
Currently, Quesa will forcefully rebuild a GL context when it is 
resized. This leads to a UI hang while Quesa reloads all active 
textures, and can adversely affect application with freely sizable 
windows/panes even with just a few textures loaded.

The problem however is two-fold...

Quesa must first handle resizes within the library, by providing a 
GLDrawContext_UpdateSize function in GLDrawContext.c. All 
renderers must catch resize flags 
(kQ3XDrawContextValidationWindowSize and 
kQ3XDrawContextValidationPane) in their StartFrame function and 
call GLDrawContext_UpdateSize instead of forcing a context 
rebuild.

Once the library can handle context resizing, some applications 
may require modification to take advantage of this functionality. 
The Qut framework for example, creates a new context when a 
window is resized, but it should really let Quesa handle that 
internally.

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

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

Re: Ideas on the future of Quesa.

[Jose' C. <cru...@ce...>]

Il giorno 26/nov/04, alle 18:48, Peter Michelsen ha scritto:

> Dear all on the Quesa list,
>
> I thought I would open a discussion on the future of Quesa. This was 
> brought about by the fact that we have finished our current projects 
> and we ( thats Roger Holmes and I ) are looking to the future.
>
> I have started work on an implementation of QuickDraw3D ViewHints in 
> Quesa, which would hopefully mean that I could understand the 
> read/write structure in Quesa.  Then take this understanding on to 
> work on the 3DS support currently present in Quesa but does not 
> currently work for us.

The read-write structure in Quesa is not so complex as it can seem, 
implementing ViewHints could be a job of few days. anyway I'm here

for 3DS support I've a half baked implementation of it using lib3DS,


>
> Firstly we would want to do this in an open source friendly way and 
> give back to Quesa as much as possible. Currently the list has been 
> kinda quiet, so now might be a good time to move to version 1.20, 
> leaving 1.19 as stable and available version on Sourceforge. Then we 
> can check-in changes as we make them as we go and not in one big go at 
> the end. The time scale for this changes would end around March 2005.
>

absolutely, I was thinking about proposing a new release just yesterday


> . The second option is a little more radical but highly desirable in 
> changing E3 routines to C++ format.

that's just using inlines or reworking the internals to make the Quesa 
classes real C++ classes with inheritance and the like?

> So the question, are you happy for us to start discussing these 
> changes on the Quesa list?
> If so I will give a detailed plan of both options next week.

I'm waiting...


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Ideas on the future of Quesa.

[Peter M. <Pet...@mi...>]

Dear all on the Quesa list,

I thought I would open a discussion on the future of Quesa. This was 
brought about by the fact that we have finished our current projects 
and we ( thats Roger Holmes and I ) are looking to the future.

I have started work on an implementation of QuickDraw3D ViewHints in 
Quesa, which would hopefully mean that I could understand the 
read/write structure in Quesa.  Then take this understanding on to work 
on the 3DS support currently present in Quesa but does not currently 
work for us.

Now, I have run into a little trouble in that I find it hard to debug 
with the current way in which the data is displayed in instanced data 
and the way in which objects methods are stored.

This maybe to do with the fact that all our programs are currently in 
C++, or that I am a little slow, but I would like to change Quesa's 
design to be more efficient and
simpler.

Firstly we would want to do this in an open source friendly way and 
give back to Quesa as much as possible. Currently the list has been 
kinda quiet, so now might be a good time to move to version 1.20, 
leaving 1.19 as stable and available version on Sourceforge. Then we 
can check-in changes as we make them as we go and not in one big go at 
the end. The time scale for this changes would end around March 2005.

So, what are these changes?

After some discussion we believe there are two options that we think 
are desirable. The first option is fairly standard optimizations and 
has been discussed on and off the Quesa list with Dair Grant, who was 
interest in the changes but due to work commitments can not make them 
himself. The second option is a little more radical but highly 
desirable in changing E3 routines to C++ format.

Either way, we have the development time at our disposal to do one of 
these changes. These changes will help with the speed of Quesa most 
notably in drawing large files with lots of different groups. Plus we 
want to give these speed ups back to the Quesa group.

So the question, are you happy for us to start discussing these changes 
on the Quesa list?
If so I will give a detailed plan of both options next week.

Cheers,
Peter Michelsen.

Re: Texture sharing

[Peter M. <Pet...@mi...>]

I can give it a go if you like.

We have a few different monitor set-ups to test with and anything to 
make textures faster is good in my books.

Peter.


On 17 Nov 2004, at 03:07, James W. Walker wrote:

> I've written some code to handle bug 902975, "Use shared texture 
> namespace".  When rendering the same scene in multiple views, it gives 
> a big speedup on both Mac (>= 10.2) and Windows.  I'll probably wait a 
> few days before checking it in, to see if any bugs shake out. Would 
> anybody with a multi-video-card test machine care to try it out?
> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Texture sharing

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

I've written some code to handle bug 902975, "Use shared texture 
namespace".  When rendering the same scene in multiple views, it 
gives a big speedup on both Mac (>= 10.2) and Windows.  I'll probably 
wait a few days before checking it in, to see if any bugs shake out. 
Would anybody with a multi-video-card test machine care to try it out?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Should there be one renderer for each view?

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

On Monday, November 15, 2004, at 09:05  pm, James W. Walker wrote:

> I don't see how that could work in Quesa as is, since the IR stores 
> the GL context pointer in its instance data.  It's going to lose the 
> GL context for A or B.

So have one renderer per window, you might want to use a different 
renderer anyway. 3D World / Microspot Interiors / Microspot  Modeller 
supports multiple documents with multiple windows on each document with 
any mix of interactive / Microspot / third party renderers which the 
user selects and it all hangs together quite well. If it isn't broken, 
don't fix it.

Re: Should there be one renderer for each view?

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

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

>Could we just keep a proxy GL context around at all time? That seems to
>be the approach they're talking about in QA1031 - something like:
>
>   - texture manager creates a fake gl context on demand
>   - texture manager creates/updates gl textures for qd3d textures
>   - renderer creates contexts that are shared with the TM context
>   - texture manager disposes of fake gl context on shutdown


I can imagine how this might work on the Mac, since you can create a 
GL context without specifying a drawable for it.  But on Windows, you 
have to pass in an HDC when you create the context, and I would 
expect that if the HDC is destroyed, the context becomes unusable.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Should there be one renderer for each view?

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

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

>James W. Walker wrote:
>
>>I wasn't asking about multiple renderers on one view, but rather
>>multiple views on one renderer.
>
>Ah, OK. I don't think that will have been a restriction before, although
>I suspect things wouldn't have worked if two views were submitted to at
>the same time.
>
>I.e., if two views both share a renderer then this will work:
>
>     start rendering  to view A
>     submight objects to view A
>     finish rendering to view A
>
>     start rendering  to view B
>     submight objects to view B
>     finish rendering to view B


I don't see how that could work in Quesa as is, since the IR stores 
the GL context pointer in its instance data.  It's going to lose the 
GL context for A or B.


>>I don't actually want to do that. I've been thinking about possible
>>solutions to bug 902975, "Use shared texture namespace".  If I could
>>assume that there is a one to one correspondence between views and
>>renderer, it would make the problem a little simpler.
>
>Could we just keep a proxy GL context around at all time? That seems to
>be the approach they're talking about in QA1031 - something like:
>
>   - texture manager creates a fake gl context on demand
>   - texture manager creates/updates gl textures for qd3d textures
>   - renderer creates contexts that are shared with the TM context
>   - texture manager disposes of fake gl context on shutdown
>
>Problem is the texture manager object needs to existing independently of
>the renderers - not sure what the best way to handle that is, perhaps
>when the renderer library is loaded/unloaded so that it's always around
>even as individual renderers come and go.

One problem is that one GL context cannot share with all others, 
e.g., a pixmap context can't share with a window context, and if two 
windows are on monitors handled by different video cards, then I 
don't think they can share with each other.  So there would have to 
be multiple texture caches.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>