From owner-ogl-sample@oss.sgi.com Mon Mar 18 07:42:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFg0G31738 for ogl-sample-outgoing; Mon, 18 Mar 2002 07:42:00 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFfu931734 for ; Mon, 18 Mar 2002 07:41:57 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id QAA12163 for ; Mon, 18 Mar 2002 16:42:50 +0100 (MET) Received: from techno.informatik.uni-stuttgart.de (magallon@techno.informatik.uni-stuttgart.de [129.69.218.24]) by wwwvis.informatik.uni-stuttgart.de (8.11.6/2.2) with SMTP id g2IFhMa00460 for ; Mon, 18 Mar 2002 16:43:22 +0100 Received: by techno.informatik.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 18 Mar 2002 16:43:22 +0100 Date: Mon, 18 Mar 2002 16:43:22 +0100 From: "Marcelo E. Magallon" To: ogl-sample@oss.sgi.com Subject: [ogl-sample] doc/registry/specs/enum.spec, bug Message-ID: <20020318154322.GA16998@informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: Linux techno 2.4.17 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Hi, a little bug in doc/registry/specs/enum.spec: Index: enum.spec =================================================================== RCS file: /cvs/projects/ogl-sample/main/doc/registry/specs/enum.spec,v retrieving revision 1.7 diff -u -r1.7 enum.spec --- enum.spec 2002/03/14 23:36:17 1.7 +++ enum.spec 2002/03/18 15:41:21 @@ -1422,9 +1422,9 @@ SHININESS = 0x1601 AMBIENT_AND_DIFFUSE = 0x1602 COLOR_INDEXES = 0x1603 - use LightProperty AMBIENT - use LightProperty DIFFUSE - use LightProperty SPECULAR + use LightParameter AMBIENT + use LightParameter DIFFUSE + use LightParameter SPECULAR ############################################################################### LightProperty is not defined anywhere. -- Marcelo From owner-ogl-sample@oss.sgi.com Mon Mar 18 07:52:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFqvH32053 for ogl-sample-outgoing; Mon, 18 Mar 2002 07:52:57 -0800 Received: from marilyn1.kirchgruppe.de (marilyn.shop.intervox.de [193.101.184.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFqs932050 for ; Mon, 18 Mar 2002 07:52:54 -0800 Received: by marilyn1.kirchgruppe.de (8.11.6/8.11.6) id g2IFrTE24025 for ogl-sample@oss.sgi.com; Mon, 18 Mar 2002 16:53:29 +0100 (CET) Received: (from localhost) by marilyn1.kirchgruppe.de (MSCAN) id 3/marilyn1.kirchgruppe.de/smtp-gw/mscan; Mon Mar 18 16:53:29 2002 Message-ID: <3C960C6A.940836C3@BetaResearch.de> Date: Mon, 18 Mar 2002 16:48:58 +0100 From: Sven Panne X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] doc/registry/specs/enum.spec, bug References: <20020318154322.GA16998@informatik.uni-stuttgart.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com "Marcelo E. Magallon" wrote: > a little bug in doc/registry/specs/enum.spec: [...] http://haskell.org/HOpenGL/spec_bugs.html :-) Ciao, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de From owner-ogl-sample@oss.sgi.com Mon Mar 18 08:31:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IGVXu02414 for ogl-sample-outgoing; Mon, 18 Mar 2002 08:31:33 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IGVS902411 for ; Mon, 18 Mar 2002 08:31:28 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id RAA13851 for ; Mon, 18 Mar 2002 17:32:22 +0100 (MET) Received: from techno.informatik.uni-stuttgart.de (magallon@techno.informatik.uni-stuttgart.de [129.69.218.24]) by wwwvis.informatik.uni-stuttgart.de (8.11.6/2.2) with SMTP id g2IGWta04654 for ; Mon, 18 Mar 2002 17:32:55 +0100 Received: by techno.informatik.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 18 Mar 2002 17:32:54 +0100 Date: Mon, 18 Mar 2002 17:32:54 +0100 From: "Marcelo E. Magallon" To: ogl-sample@oss.sgi.com Subject: [ogl-sample] Question regarding ATI extensions Message-ID: <20020318163254.GA17413@informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: Linux techno 2.4.17 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Hi, while merging the new spec files I noticed some ATI extensions are commented out, for example: # ATI_vertex_array_object enum: # STATIC_ATI = 0x8760 # DYNAMIC_ATI = 0x8761 # PRESERVE_ATI = 0x8762 # DISCARD_ATI = 0x8763 # OBJECT_BUFFER_SIZE_ATI = 0x8764 # OBJECT_BUFFER_USAGE_ATI = 0x8765 # ARRAY_OBJECT_BUFFER_ATI = 0x8766 # ARRAY_OBJECT_OFFSET_ATI = 0x8767 in fact, I'm wondering why a lot of lines are commented out, for example: # VERSION_1_3 enum: (Promoted for OpenGL 1.3) # ARB_multitexture enum: # TEXTURE0 = 0x84C0 # TEXTURE0_ARB = 0x84C0 # TEXTURE1 = 0x84C1 # TEXTURE1_ARB = 0x84C1 # TEXTURE2 = 0x84C2 # TEXTURE2_ARB = 0x84C2 # TEXTURE3 = 0x84C3 # TEXTURE3_ARB = 0x84C3 [...] Did I misunderstand the meaning of the #? Thanks, -- Marcelo From owner-ogl-sample@oss.sgi.com Mon Mar 18 22:37:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J6bhT19588 for ogl-sample-outgoing; Mon, 18 Mar 2002 22:37:43 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J6be919585 for ; Mon, 18 Mar 2002 22:37:40 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id HAA01354 for ; Tue, 19 Mar 2002 07:38:35 +0100 (MET) Received: from ysabell.wh.vaih (gw-41.wh.uni-stuttgart.de [129.69.166.244]) by wwwvis.informatik.uni-stuttgart.de (8.11.6/2.2) with ESMTP id g2J6d7a18511 for ; Tue, 19 Mar 2002 07:39:07 +0100 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.35 #1 (Debian)) id 16nDH1-0000NQ-00 for ; Tue, 19 Mar 2002 07:39:07 +0100 Date: Tue, 19 Mar 2002 07:39:07 +0100 From: "Marcelo E. Magallon" To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] doc/registry/specs/enum.spec, bug Message-ID: <20020319063907.GB1209@ysabell.wh.vaih> References: <20020318154322.GA16998@informatik.uni-stuttgart.de> <3C960C6A.940836C3@BetaResearch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C960C6A.940836C3@BetaResearch.de> User-Agent: Mutt/1.3.27i X-Operating-System: Linux ysabell 2.4.18-xfs Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com >> Sven Panne writes: > > http://haskell.org/HOpenGL/spec_bugs.html > :-) I think some of those are fixed in the most recent CVS. At least a program of mine didn't complain so loudly (as it used to) when I used the new files. -- Marcelo From owner-ogl-sample@oss.sgi.com Tue Mar 19 01:08:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J98FQ22238 for ogl-sample-outgoing; Tue, 19 Mar 2002 01:08:15 -0800 Received: from marilyn1.kirchgruppe.de (marilyn.shop.intervox.de [193.101.184.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J98A922235 for ; Tue, 19 Mar 2002 01:08:10 -0800 Received: by marilyn1.kirchgruppe.de (8.11.6/8.11.6) id g2J98j226919 for ogl-sample@oss.sgi.com; Tue, 19 Mar 2002 10:08:45 +0100 (CET) Received: (from localhost) by marilyn1.kirchgruppe.de (MSCAN) id 3/marilyn1.kirchgruppe.de/smtp-gw/mscan; Tue Mar 19 10:08:45 2002 Message-ID: <3C96FF1D.689051E0@BetaResearch.de> Date: Tue, 19 Mar 2002 10:04:29 +0100 From: Sven Panne X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: [ogl-sample] Parameter semantics in .spec files Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com I'm a bit puzzled by the semantics of the .spec files: Given the 9 possible combinations of directions (in, out, in/out) and transfer types (value, reference, array), what do they mean exactly? E.g. what are the exact differences between param foo BarPointer in value param foo Bar in reference param foo Bar in array [] Looking into gl.spec and glu.spec, these seem to be arbitrarily mixed. Regarding "in/out": There is some confusion in the scripts and their comments whether it should read "in/out" or "inout", but neither of it is used in the .spec files, so this distinction is only academic and we could leave it out of the current discussion. Another point is the "retained" attribute, which probably means: "The location of this buffer is remembered across the current call" (vertex arrays, feedback buffers, etc.) and makes only sense for reference and array. Is this correct? So we are basically left with 2 (in,out) * 3 (value,reference,array) * 2 (optionally retained) = 12 possible combinations. A translation of these into e.g. DCE IDL or its close relative Microsoft IDL would be very helpful. Looking for enlightenment, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de From owner-ogl-sample@oss.sgi.com Thu Mar 21 01:06:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L96pu26938 for ogl-sample-outgoing; Thu, 21 Mar 2002 01:06:51 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L96i926934 for ; Thu, 21 Mar 2002 01:06:44 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2L9876G018354 for ; Thu, 21 Mar 2002 01:08:07 -0800 Received: from oddhack.engr.sgi.com (oddhack.engr.sgi.com [130.62.54.158]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id BAA97764 for ; Thu, 21 Mar 2002 01:06:52 -0800 (PST) Received: by oddhack.engr.sgi.com (Postfix, from userid 34316) id 5F223F998; Thu, 21 Mar 2002 01:06:51 -0800 (PST) Date: Thu, 21 Mar 2002 01:06:51 -0800 From: Jon Leech To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] doc/registry/specs/enum.spec, bug Message-ID: <20020321010651.A19046@oddhack.engr.sgi.com> References: <20020318154322.GA16998@informatik.uni-stuttgart.de> <3C960C6A.940836C3@BetaResearch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3C960C6A.940836C3@BetaResearch.de>; from Sven_Panne@BetaResearch.de on Mon, Mar 18, 2002 at 04:48:58PM +0100 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com On Mon, Mar 18, 2002 at 04:48:58PM +0100, Sven Panne wrote: > "Marcelo E. Magallon" wrote: > > a little bug in doc/registry/specs/enum.spec: [...] > > > http://haskell.org/HOpenGL/spec_bugs.html > A few general comments about the .spec files - there are actually two different versions in the SI tree, one used for generating the that corresponds exactly to what the SI source code implements. The other set of .spec files - the one you guys are talking about - is primarily for the extension registry and tries to be much more complete in extension coverage (although this is quite difficult because of the pace at which some vendors release extensions, often without telling me). gl.spec has occasional bugs that need fixing, and I'm taking a look at Sven's patches, but it's very close to correct for the main intended purpose - generating prototypes and function pointer types in glext.h. enum.spec really only has *one* purpose right now - keeping track of which enumerant ranges are assigned to which vendor. So it is mostly ordered numerically with range<->vendor mappings identified. Where known, individual enum usage within the assigned ranges is tagged - but that's really just intended as additional documentation. The stuff in enum.spec that is *not* commented out is the original (pre-ABI) contents of enum.spec, as used to generate the SI (e.g. core OpenGL 1.2) header files. enumext.spec, OTOH, is used to generate the enumerant portion of glext.h - so it only contains the things that are defined to be in glext.h (because they may not be in any particular vendor's gl.h): core 1.2+ enums, and all extension enums. It is certainly possible to restructure the spec files and generator scripts to do away with some of the replication, though it's hard to see how to collapse enum.spec and enumext.spec together short of just stuffing it all in a relational database :-) It would certailny be a lot of work that isn't justified for the purposes we're using the spec files for right now. I have some cycles free for maintaining the spec files now, first time in a long while, so I'll try to merge in those of Sven's patches that make sense over the next week or so. I hope that makes at least some sense. Jon Leech SGI From owner-ogl-sample@oss.sgi.com Thu Mar 21 01:09:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L99v426992 for ogl-sample-outgoing; Thu, 21 Mar 2002 01:09:57 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L99p926989 for ; Thu, 21 Mar 2002 01:09:51 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2L9BF6G018446 for ; Thu, 21 Mar 2002 01:11:15 -0800 Received: from oddhack.engr.sgi.com (oddhack.engr.sgi.com [130.62.54.158]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id BAA97910 for ; Thu, 21 Mar 2002 01:09:59 -0800 (PST) Received: by oddhack.engr.sgi.com (Postfix, from userid 34316) id 18CC7F998; Thu, 21 Mar 2002 01:09:59 -0800 (PST) Date: Thu, 21 Mar 2002 01:09:59 -0800 From: Jon Leech To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Question regarding ATI extensions Message-ID: <20020321010959.B19046@oddhack.engr.sgi.com> References: <20020318163254.GA17413@informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <20020318163254.GA17413@informatik.uni-stuttgart.de>; from marcelo.magallon@bigfoot.com on Mon, Mar 18, 2002 at 05:32:54PM +0100 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com On Mon, Mar 18, 2002 at 05:32:54PM +0100, Marcelo E. Magallon wrote: > while merging the new spec files I noticed some ATI extensions are > commented out, for example: > > # ATI_vertex_array_object enum: > # STATIC_ATI = 0x8760 > # DYNAMIC_ATI = 0x8761 > # PRESERVE_ATI = 0x8762 > # DISCARD_ATI = 0x8763 > # OBJECT_BUFFER_SIZE_ATI = 0x8764 > # OBJECT_BUFFER_USAGE_ATI = 0x8765 > # ARRAY_OBJECT_BUFFER_ATI = 0x8766 > # ARRAY_OBJECT_OFFSET_ATI = 0x8767 > > in fact, I'm wondering why a lot of lines are commented out, for > example: As mentioned in my previous email - the core 1.3+ and most extension enums are not currently supported in the SI codebase, so they are commented out in enum.spec and found in enumext.spec instead. It's not unreasonable to uncomment them in enum.spec, and they're not all commented out in a consistent manner - I've just never had any reason to think about it because enum.spec is not being used for input to any processing tool that we use, it's just a document. Jon Leech SGI From owner-ogl-sample@oss.sgi.com Thu Mar 21 01:31:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L9V3w27425 for ogl-sample-outgoing; Thu, 21 Mar 2002 01:31:03 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L9Ur927422 for ; Thu, 21 Mar 2002 01:30:53 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2LAWHBA019541 for ; Thu, 21 Mar 2002 02:32:17 -0800 Received: from oddhack.engr.sgi.com (oddhack.engr.sgi.com [130.62.54.158]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id BAA99752 for ; Thu, 21 Mar 2002 01:31:01 -0800 (PST) Received: by oddhack.engr.sgi.com (Postfix, from userid 34316) id D7623F998; Thu, 21 Mar 2002 01:31:00 -0800 (PST) Date: Thu, 21 Mar 2002 01:31:00 -0800 From: Jon Leech To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Parameter semantics in .spec files Message-ID: <20020321013100.C19046@oddhack.engr.sgi.com> References: <3C96FF1D.689051E0@BetaResearch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3C96FF1D.689051E0@BetaResearch.de>; from Sven_Panne@BetaResearch.de on Tue, Mar 19, 2002 at 10:04:29AM +0100 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com On Tue, Mar 19, 2002 at 10:04:29AM +0100, Sven Panne wrote: > I'm a bit puzzled by the semantics of the .spec files: Given the 9 > possible combinations of directions (in, out, in/out) and transfer > types (value, reference, array), what do they mean exactly? E.g. > what are the exact differences between > > param foo BarPointer in value In C-speak, roughly func(BarPointer foo) > param foo Bar in reference func(const Bar *foo) > param foo Bar in array [] func(const Bar foo[]) The generator scripts and spec files evolved over many years (judging from the comments, early work was actually done by Gary Tarolli about 10 years ago), and no formal grammar or well-defined semantics document exists - the generator scripts *are* the documentation. It is a sad opposite to the very well defined OpenGL API. In any event: the param tags are just a (somewhat) language neutral way to define parameter types. I know there were IDLs around over a decade ago, they just didn't get used for this purpose. I think (wasn't around at the time) that the spec files started out very simple and grew and grew. 'in' basically means 'not modified' (in a contemporary C-speak sense, this would usually be 'const', unless a simple scalar is being passed), 'out' means 'may be modified'. 'value' and 'reference' are pass-by-value and pass-by-reference (pointer) in C speak. 'array [size]' means 'array of specified size, passed by reference'. The [COMPSIZE(params)] terminology means that the expected size is some complex function of the specified input parameters. > Looking into gl.spec and glu.spec, these seem to be arbitrarily mixed. They are not arbitrary; they map precisely onto the signatures defined by the GL specification and the extension specifications whose entry points are being documented. But the OpenGL API and the conventions used even today in developing extension APIs came about back when K&R C was still predominant, so e.g. 'const' doesn't tend to show up much. This is unfixable at this point since changing it would break a huge amount of code. > Regarding "in/out": There is some confusion in the scripts and their > comments whether it should read "in/out" or "inout", but neither of it > is used in the .spec files, so this distinction is only academic and we > could leave it out of the current discussion. There is a lot of ugliness in the scripts; they have grown messily for over a decade (there were IrisGL .spec scripts preceding these, back into the late 80s), and are probably not nearly so general as they would like to depict themselves to be. There is also a lot of stuff in the scripts that looks like gratuitous bloat but is really there because, behind the scenes, the spec files are used in many ways besides generating header files (frex, on IRIX we have additional libspec tools for generating dispatch tables at multiple levels of client and X server). > Another point is the "retained" attribute, which probably means: "The > location of this buffer is remembered across the current call" (vertex > arrays, feedback buffers, etc.) and makes only sense for reference and > array. Is this correct? Yes. This mostly applies to GL client state, e.g. vertex arrays and related stuff. > So we are basically left with > > 2 (in,out) * 3 (value,reference,array) * 2 (optionally retained) = 12 > > possible combinations. A translation of these into e.g. DCE IDL or its > close relative Microsoft IDL would be very helpful. I don't know IDL, unfortunately. It is easy (assuming you can get the glext.h generator scripts working) to create a spec file entry with parameters of all those different types and see what comes out the back end, which might be some help. > Looking for enlightenment, I'm not sure anyone in the world completely understands this stuff - spec files get used for so many different purposes by so many different people on so many different platforms. The usages in the SI tree are just the tip of the iceberg. Sometimes I get gl.spec entries from vendors that contain stuff I haven't a hope of understanding, so you're not alone in wanting enlightenment :-) Jon Leech SGI From owner-ogl-sample@oss.sgi.com Thu Mar 21 01:41:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L9fZW31202 for ogl-sample-outgoing; Thu, 21 Mar 2002 01:41:35 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L9fW931199 for ; Thu, 21 Mar 2002 01:41:32 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id KAA05451 for ; Thu, 21 Mar 2002 10:42:26 +0100 (MET) Received: from ysabell.wh.vaih (gw-41.wh.uni-stuttgart.de [129.69.166.244]) by wwwvis.informatik.uni-stuttgart.de (8.11.6/2.2) with ESMTP id g2L9gwa10909 for ; Thu, 21 Mar 2002 10:42:58 +0100 Received: from marcelo by ysabell.wh.vaih with local (Exim 3.35 #1 (Debian)) id 16nz67-0001nq-00 for ; Thu, 21 Mar 2002 10:43:03 +0100 Date: Thu, 21 Mar 2002 10:43:03 +0100 From: "Marcelo E. Magallon" To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Question regarding ATI extensions Message-ID: <20020321094303.GB6892@ysabell.wh.vaih> References: <20020318163254.GA17413@informatik.uni-stuttgart.de> <20020321010959.B19046@oddhack.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020321010959.B19046@oddhack.engr.sgi.com> User-Agent: Mutt/1.3.27i X-Operating-System: Linux ysabell 2.4.18-xfs Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com >> Jon Leech writes: > As mentioned in my previous email - the core 1.3+ and most extension > enums are not currently supported in the SI codebase, so they are > commented out in enum.spec and found in enumext.spec instead. Yes, I'm sorry, I figured that out after sending my email and forgot to send a follow up. > I've just never had any reason to think about it because enum.spec is > not being used for input to any processing tool that we use, it's > just a document. Oh, thanks for the info. Marcelo From owner-ogl-sample@oss.sgi.com Fri Mar 22 00:18:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M8IBQ10900 for ogl-sample-outgoing; Fri, 22 Mar 2002 00:18:11 -0800 Received: from marilyn1.kirchgruppe.de (marilyn.shop.intervox.de [193.101.184.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M8I4q10897 for ; Fri, 22 Mar 2002 00:18:06 -0800 Received: by marilyn1.kirchgruppe.de (8.11.6/8.11.6) id g2M8JPU18380 for ogl-sample@oss.sgi.com; Fri, 22 Mar 2002 09:19:25 +0100 (CET) Received: (from localhost) by marilyn1.kirchgruppe.de (MSCAN) id 3/marilyn1.kirchgruppe.de/smtp-gw/mscan; Fri Mar 22 09:19:25 2002 Message-ID: <3C9AE80D.4CDF722C@BetaResearch.de> Date: Fri, 22 Mar 2002 09:15:09 +0100 From: Sven Panne X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] doc/registry/specs/enum.spec, bug References: <20020318154322.GA16998@informatik.uni-stuttgart.de> <3C960C6A.940836C3@BetaResearch.de> <20020321010651.A19046@oddhack.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Jon Leech wrote: > [...] The other set of .spec files [...] tries to be much more complete > in extension coverage (although this is quite difficult because of the > pace at which some vendors release extensions, often without telling me). Well, that's the main reason I wanted to rely on that set for my OpenGL binding: Let other people do the hard work of keeping everything up to date... ;-) > [...] enum.spec really only has *one* purpose right now - keeping track > of which enumerant ranges are assigned to which vendor. So it is mostly > ordered numerically with range<->vendor mappings identified. Where known, > individual enum usage within the assigned ranges is tagged - but that's > really just intended as additional documentation. I didn't know that. But for a documentation it is rather good and quite usable in terms of automatic processing. > [...] It is certainly possible to restructure the spec files and > generator scripts to do away with some of the replication, though it's > hard to see how to collapse enum.spec and enumext.spec together short of > just stuffing it all in a relational database :-) It would certailny be a > lot of work [...] I'm not sure if it is really that much work: What is missing for the enums is basically something like the 'version' resp. 'category' properties of functions (see gl.spec and friends). If that could be achieved in a backwards-compatible way it would help quite a lot. > [...] I hope that makes at least some sense. Yes, thanks a lot for the info. Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de From owner-ogl-sample@oss.sgi.com Fri Mar 22 01:10:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M9AhX12515 for ogl-sample-outgoing; Fri, 22 Mar 2002 01:10:43 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M9ASq12505 for ; Fri, 22 Mar 2002 01:10:28 -0800 Received: from marilyn1.kirchgruppe.de (marilyn.shop.intervox.de [193.101.184.4]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA02430 for ; Fri, 22 Mar 2002 01:12:59 -0800 (PST) mail_from (Sven_Panne@BetaResearch.de) Received: (from root@localhost) by marilyn1.kirchgruppe.de (8.11.6/8.11.6) id g2M920E26392 for ogl-sample@oss.sgi.com; Fri, 22 Mar 2002 10:02:00 +0100 (CET) Received: (from localhost) by marilyn1.kirchgruppe.de (MSCAN) id 3/marilyn1.kirchgruppe.de/smtp-gw/mscan; Fri Mar 22 10:02:00 2002 Message-ID: <3C9AF209.B2024842@BetaResearch.de> Date: Fri, 22 Mar 2002 09:57:45 +0100 From: Sven Panne X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Parameter semantics in .spec files References: <3C96FF1D.689051E0@BetaResearch.de> <20020321013100.C19046@oddhack.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Jon Leech wrote: > On Tue, Mar 19, 2002 at 10:04:29AM +0100, Sven Panne wrote: > > [...] > > param foo BarPointer in value > > In C-speak, roughly > > func(BarPointer foo) > > > param foo Bar in reference > > func(const Bar *foo) > > > param foo Bar in array [] > > func(const Bar foo[]) OK, perhaps the example was not really good, but I still can't grasp the intended differences between e.g. param foo BarPointer in value and param foo Bar out reference > > Looking into gl.spec and glu.spec, these seem to be arbitrarily mixed. > They are not arbitrary; they map precisely onto the signatures defined by > the GL specification and the extension specifications whose entry points > are being documented. They *are* quite arbitrary in the sense that the .spec files (could) contain much more info than plain C headers and that additional info is sometimes lost due to glitches in the .spec files. Take for example Build1DMipmaps. The Red Book tells me: int gluBuild1DMipmaps(GLenum target, GLint components, GLint width, GLenum format, GLenum type, void *data); int gluBuild2DMipmaps(GLenum target, GLint components, GLint width, GLint height, GLenum format, GLenum type, void *data); Constructs a series of mipmaps and calls glTexImage*D() to load the images. The parameters for target, components, width, height, format, type, and data are exactly the same as those for glTexImage1D() and glTexImage2D(). A value of 0 is returned if all the mipmaps are constructed successfully; otherwise, a GLU error code is returned. Looking into glu.spec and gl.spec, the argument types are not really the same: Build1DMipmaps(target, internalFormat, width, format, type, data); return Int32 param target TextureTarget in value param internalFormat Int32 in value param width SizeI in value param format PixelFormat in value param type PixelType in value param data void in reference TexImage1D(target, level, internalformat, width, border, format, type, pixels) return void param target TextureTarget in value param level CheckedInt32 in value param internalformat TextureComponentCount in value param width SizeI in value param border CheckedInt32 in value param format PixelFormat in value param type PixelType in value param pixels Void in array [COMPSIZE(format/type/width)] category drawing-control dlflags handcode glxflags client-handcode server-handcode version 1.0 glxropcode 109 glsflags pixel-null pixel-unpack glsopcode 0x00A0 wglflags client-handcode server-handcode offset 182 Granted, they map to the same C types, but other languages have a much richer type system than C (which is not *that* difficult :-) and an array could be something very different from a pointer to the elements. > [...] There is a lot of ugliness in the scripts; they have grown messily > for over a decade [...] No need for excuses: The .spec files are cool! If every API had such a detailed formal description, the world would be a better place... :-) Despite of my criticism, I like them, I'm only suggesting some minor improvements which would make them even more usable. IMHO it's a pity that e.g. Mesa uses its own variant of .spec files and declares the registry/SI stuff as a PITA... > [...] It is easy (assuming you can get the glext.h generator scripts > working) to create a spec file entry with parameters of all those > different types and see what comes out the back end, which might be some > help. I've already done this, but as already mentioned, some info is lost during this conversion because different .spec file constructs map to the same C construct (e.g. 'in array' and 'in reference', etc.). I was hoping to get some info marshaling like the following: 'Bar in value': The value of the given parameter is copied (marshaled in IDL terms) to OpenGL. 'Bar out value': A pointer to an (uninitialized) buffer of a size large enough to hold a Bar value is passed to OpenGL. The callee puts a value into this buffer and this can be read (unmarshaled) by the caller after the call. Note that (un)marshaling might be more than plain copying if the caller uses a different representation of values than the callee (which is probably the case for non-C OpenGL bindings), remote calls take place, etc. > [...] so you're not alone in wanting enlightenment :-) :-) To improve the situation a bit, I'm planning (after Easter?) to write down a few lines about the syntax and semantics of the two types of .spec files and put it up on my web site. There are very probably a lot of people using the .spec files who had to figure things out the hard way (like me), and some tiny bits of information could help a lot... Thanks for the information, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de From owner-ogl-sample@oss.sgi.com Fri Mar 22 01:40:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M9eKU13125 for ogl-sample-outgoing; Fri, 22 Mar 2002 01:40:20 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M9eAq13089 for ; Fri, 22 Mar 2002 01:40:10 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2MAokkw023532 for ; Fri, 22 Mar 2002 04:50:47 -0600 Received: from oddhack.engr.sgi.com (oddhack.engr.sgi.com [130.62.54.158]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id BAA74028 for ; Fri, 22 Mar 2002 01:41:12 -0800 (PST) Received: by oddhack.engr.sgi.com (Postfix, from userid 34316) id 97F8FF998; Fri, 22 Mar 2002 01:41:11 -0800 (PST) Date: Fri, 22 Mar 2002 01:41:11 -0800 From: Jon Leech To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] Parameter semantics in .spec files Message-ID: <20020322014111.B25428@oddhack.engr.sgi.com> References: <3C96FF1D.689051E0@BetaResearch.de> <20020321013100.C19046@oddhack.engr.sgi.com> <3C9AF209.B2024842@BetaResearch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <3C9AF209.B2024842@BetaResearch.de>; from Sven_Panne@BetaResearch.de on Fri, Mar 22, 2002 at 09:57:45AM +0100 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com On Fri, Mar 22, 2002 at 09:57:45AM +0100, Sven Panne wrote: > OK, perhaps the example was not really good, but I still can't grasp the > intended differences between e.g. > > param foo BarPointer in value > > and > > param foo Bar out reference There really isn't one from the standpoint of what the .spec files are used for today, though I wouldn't recommend using the prior form because it throws away some information and requires another typemap entry. Perhaps there should be 'canonical form' guidelines for writing these. Note that the base type (e.g. Bar) usually maps onto a scalar type, like one of the GLint/float/etc. or underlying C types. There are weaknesses in the descriptive power of the .spec files (e.g. there is no straightforward way to describe a C type like 'const GLXContext ctx') which make it hard to describe some types. This can be covered for by defining arbitrary out mappings in the auxiliary typemap file, which controls how the symbolic type in the .spec file is converted into an underlying real language type. [...] > Granted, they map to the same C types, but other languages have a much > richer type system than C (which is not *that* difficult :-) and an array > could be something very different from a pointer to the elements. That's an inconsistency which could stand to be fixed. There are lots of them, probably mostly because spec file entries were written by different people at different times without good guidelines. Underlying that, the OpenGL APIs, by design, only take scalars, references to scalars, or arrays of scalars whose size and internal structure are almost always not known at compile time, but are dependent on other call parameters. > No need for excuses: The .spec files are cool! If every API had such a > detailed formal description, the world would be a better place... :-) > Despite of my criticism, I like them, I'm only suggesting some minor > improvements which would make them even more usable. IMHO it's a pity that > e.g. Mesa uses its own variant of .spec files and declares the registry/SI > stuff as a PITA... Well, at least it's a reasonably useful PITA. I think Mesa's usage may have mostly to do with Brian liking to write Python scripts instead of Perl :-) I haven't looked at the Mesa build for a long time so don't know what he's doing there; at some point, though, it would be nice to get at least the GLX portion of the SI build brought up to date with the changes they made to the SI GLX to support DRI, and integrated into XFree86, so they could leverage the generator scripts to add extension protocol wrappers more easily. Unfortunately when we initially open sourced GLX we didn't include all the specfile/generator stuff, so that wasn't an option for the Precision Insight guys at the time and nobody seems to have had time for it since then. > > [...] so you're not alone in wanting enlightenment :-) > > :-) To improve the situation a bit, I'm planning (after Easter?) to write > down a few lines about the syntax and semantics of the two types of .spec > files and put it up on my web site. There are very probably a lot of people > using the .spec files who had to figure things out the hard way (like me), > and some tiny bits of information could help a lot... That would be nifty. If you want, I'd be happy to put such a document in some suitable spot on oss.sgi.com too. Jon From owner-ogl-sample@oss.sgi.com Tue Mar 26 03:33:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QBXHt14996 for ogl-sample-outgoing; Tue, 26 Mar 2002 03:33:17 -0800 Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QBWPq14983 for ; Tue, 26 Mar 2002 03:32:26 -0800 Received: from wwwvis.informatik.uni-stuttgart.de (wwwvis [129.69.215.162]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id MAA08064 for ; Tue, 26 Mar 2002 12:34:13 +0100 (MET) Received: from techno.informatik.uni-stuttgart.de (magallon@techno.informatik.uni-stuttgart.de [129.69.218.24]) by wwwvis.informatik.uni-stuttgart.de (8.11.6/2.2) with SMTP id g2QBYka30452 for ; Tue, 26 Mar 2002 12:34:46 +0100 Received: by techno.informatik.uni-stuttgart.de (sSMTP sendmail emulation); Tue, 26 Mar 2002 12:34:46 +0100 Date: Tue, 26 Mar 2002 12:34:46 +0100 From: "Marcelo E. Magallon" To: ogl-sample@oss.sgi.com Subject: [ogl-sample] update for glx.spec Message-ID: <20020326113446.GA21260@informatik.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.3.27i X-Operating-System: Linux techno 2.4.19-pre3-ac1 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, thanks to John for the explaination about the different .spec files. Attached is a diff for doc/registry/specs/glx.spec, it fixed it to the point where it's more or less correct. The current version is plainly incorrect, even if it exists only for documentation purposes. Thanks, Marcelo --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="glx.diff" --- doc/registry/specs/glx.spec Sat Mar 23 04:13:05 2002 +++ /home/magallon/devel/spyglass/src/specs/glx.spec Tue Mar 26 12:30:04 2002 @@ -55,49 +55,50 @@ glxopcode 2 -CreateContext(gc_id, screen, visual, share_list) - return void - param gc_id Int32 in value - param screen Int32 in value - param visual Int32 in value - param share_list Int32 in value +CreateContext(dpy, visual, share_list, direct) + return GLXContext + param dpy DisplayPointer in value + param visual XVisualInfoPointer in value + param share_list GLXContext in value + param direct Bool in value glxflags client-handcode server-handcode category glx dlflags notlistable glxopcode 3 -DestroyContext(context) +DestroyContext(dpy, ctx) return void - param context Int32 in value + param ctx GLXContext in value glxflags client-handcode server-handcode category glx dlflags notlistable glxopcode 4 -MakeCurrent(drawable, context) - return void - param drawable Int32 in value - param context Int32 in value - glxflags client-handcode server-handcode +MakeCurrent(dpy, drawable, ctx) + return Bool + param dpy DisplayPointer in value + param drawable GLXDrawable in value + param ctx GLXContext in value category glx dlflags notlistable glxopcode 5 -IsDirect(dpy, context) - return void - param dpy Int32 in value - param context Int32 in value - glxflags client-handcode server-handcode - category glx - dlflags notlistable - glxopcode 6 +IsDirect(dpy, ctx) + return Bool + param dpy DisplayPointer in value + param ctx GLXContext in value + glxflags client-handcode server-handcode + category glx + dlflags notlistable + glxopcode 6 -QueryVersion(major, minor) - return void +QueryVersion(dpy, major, minor) + return Bool + param dpy DisplayPointer in value param major Int32 out reference param minor Int32 out reference category glx @@ -106,9 +107,8 @@ glxopcode 7 -WaitGL(context) +WaitGL() return void - param context Int32 in value category glx dlflags notlistable glxflags client-handcode server-handcode @@ -123,20 +123,22 @@ glxopcode 9 -CopyContext(source, dest, mask) +CopyContext(dpy, source, dest, mask) return void - param source Int32 in value - param dest Int32 in value - param mask Int32 in value + param dpy DisplayPointer in value + param source GLXContext in value + param dest GLXContext in value + param mask UInt32 in value category glx dlflags notlistable glxflags client-handcode server-handcode glxopcode 10 -SwapBuffers(drawable) +SwapBuffers(dpy, drawable) return void - param drawable Int32 in value + param dpy DisplayPointer in value + param drawable GLXDrawable in value category glx dlflags notlistable glxflags client-handcode server-handcode @@ -145,7 +147,7 @@ UseXFont(font, first, count, list_base) return void - param font Int32 in value + param font Font in value param first Int32 in value param count Int32 in value param list_base Int32 in value @@ -155,11 +157,11 @@ glxopcode 12 -CreateGLXPixmap(visual, pixmap, glxpixmap) - return void - param visual Int32 in value - param pixmap Int32 in value - param glxpixmap Int32 in value +CreateGLXPixmap(dpy, visual, pixmap) + return GLXPixmap + param dpy DisplayPointer in value + param visual XVisualInfoPointer in value + param pixmap Pixmap in value category glx dlflags notlistable glxflags client-handcode server-handcode @@ -173,9 +175,10 @@ glxopcode 14 -DestroyGLXPixmap(pixmap) +DestroyGLXPixmap(dpy, pixmap) return void - param pixmap Int32 in value + param dpy DisplayPointer in value + param pixmap GLXPixmap in value glxflags client-handcode category glx dlflags notlistable @@ -202,16 +205,18 @@ # GLX1.1 commands # ############################################################################### -QueryExtensionsString(screen) - return void +QueryExtensionsString(dpy, screen) + return GLXstring + param dpy DisplayPointer in value param screen Int32 in value glxflags client-handcode server-handcode category glx dlflags notlistable glxopcode 18 -QueryServerString(screen, name) - return void +QueryServerString(dpy, screen, name) + return GLXstring + param dpy DisplayPointer in value param screen Int32 in value param name Int32 in value glxflags client-handcode server-handcode @@ -231,71 +236,84 @@ # GLX1.3 commands # ############################################################################### -GetFBConfigs() - return void +GetFBConfigs(dpy, screen, nelements) + return GLXFBConfigPointer + param dpy DisplayPointer in value + param screen Int32 in value + param nelements Int32 out reference category glx dlflags notlistable glxflags client-handcode server-handcode glxopcode 21 -CreatePixmap(config, pixmap, glxpixmap) - return void - param config Int32 in value - param pixmap Int32 in value - param glxpixmap Int32 in value +CreatePixmap(dpy, config, pixmap, attriblist) + return GLXPixmap + param dpy DisplayPointer in value + param config GLXFBConfig in value + param pixmap Pixmap in value + param attriblist Int32 in array dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 22 -DestroyPixmap(glxpixmap) +DestroyPixmap(dpy, pixmap) return void - param glxpixmap Int32 in value + param dpy DisplayPointer in value + param pixmap Pixmap in value dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 23 -CreateNewContext(config, render_type, share_list, direct) - return void - param config Int32 in value +CreateNewContext(dpy, config, render_type, share_list, direct) + return GLXContext + param dpy DisplayPointer in value + param config GLXFBConfig in value param render_type Int32 in value - param share_list Int32 in value - param direct Int32 in value + param share_list GLXContext in value + param direct Bool in value dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 24 -QueryContext() - return void +QueryContext(dpy, context, attribute, value) + return Int32 + param dpy DisplayPointer in value + param context GLXContext in value + param attribute Int32 in value + param value Int32 out reference dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 25 -MakeContextCurrent(drawable, readdrawable, context) - return void - param drawable Int32 in value - param readdrawable Int32 in value - param context Int32 in value +MakeContextCurrent(dpy, drawdrawable, readdrawable, context) + return Bool + param dpy DisplayPointer in value + param drawdrawable GLXDrawable in value + param readdrawable GLXDrawable in value + param context GLXContext in value dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 26 -CreatePbuffer(config, pbuffer) - return void - param config Int32 in value - param pbuffer Int32 in value +CreatePbuffer(dpy, config, attrib_list) + return GLXPbuffer + param dpy DisplayPointer in value + param config GLXFBConfig in value + param attrib_list Int32 in array dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 27 -DestroyPbuffer(pbuffer) +DestroyPbuffer(dpy, pbuffer) return void - param pbuffer Int32 in value + param dpy DisplayPointer in value + param pbuffer GLXPbuffer in value dlflags notlistable glxflags client-handcode category glx @@ -317,24 +335,33 @@ category glx glxopcode 30 -CreateWindow(config, window, glxwindow) - return void - param config Int32 in value - param window Int32 in value - param glxwindow Int32 in value +CreateWindow(dpy, config, window, attrib_list) + return GLXWindow + param dpy DisplayPointer in value + param config GLXFBConfig in value + param window Window in value + param attrib_list Int32 in array dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 31 -DestroyWindow(glxwindow) +DestroyWindow(dpy, window) return void - param glxwindow Int32 in value + param dpy DisplayPointer in value + param window Window in value dlflags notlistable glxflags client-handcode server-handcode category glx glxopcode 32 +ChooseVisual(dpy, screen, attriblist) + return XVisualInfoPointer + param dpy DisplayPointer in value + param screen Int32 in value + param attriblist Int32 out array + category glx + ############################################################################### # # IRIX5.3 extension commands @@ -412,8 +439,12 @@ # EXT_import_context extension commands # ############################################################################### -QueryContextInfoEXT() - return void +QueryContextInfoEXT(dpy, context, attribute, value) + return Int32 + param dpy DisplayPointer in value + param context GLXContext in value + param attribute Int32 in value + param value Int32 out reference category glx dlflags notlistable glxflags client-handcode server-handcode @@ -431,26 +462,28 @@ glxflags client-handcode server-handcode glxvendorglx 65540 -CreateContextWithConfigSGIX(gc_id, screen, config, share_list) - return void - param gc_id Int32 in value - param screen Int32 in value - param config Int32 in value - param share_list Int32 in value +CreateContextWithConfigSGIX(dpy, config, renderType, share_list, allow_direct) + return GLXContext + param dpy DisplayPointer in value + param config GLXFBConfigSGIX in value + param renderType Int32 in value + param share_list GLXContext in value + param allow_direct Bool in value glxflags client-handcode server-handcode category glx dlflags notlistable glxvendorglx 65541 -CreateGLXPixmapWithConfigSGIX(config, pixmap, glxpixmap) - return void - param config Int32 in value - param pixmap Int32 in value - param glxpixmap Int32 in value - category glx - dlflags notlistable - glxflags client-handcode server-handcode - glxvendorglx 65542 +CreateGLXPixmapWithConfigSGIX(dpy, config, pixmap, attriblist) + return GLXPixmap + param dpy DisplayPointer in value + param config GLXFBConfigSGIX in value + param pixmap Pixmap in value + param attriblist Int32 in array + category glx + dlflags notlistable + glxflags client-handcode server-handcode + glxvendorglx 65542 ############################################################################### # @@ -458,18 +491,22 @@ # ############################################################################### -CreateGLXPbufferSGIX(config, pbuffer) - return void - param config Int32 in value - param pbuffer Int32 in value +CreateGLXPbufferSGIX(dpy, config, width, height, attriblist) + return GLXPbuffer + param dpy DisplayPointer in value + param config GLXFBConfig in value + param width UInt32 in value + param height UInt32 in value + param attriblist Int32 in array dlflags notlistable glxflags client-handcode server-handcode category glx glxvendorglx 65543 -DestroyGLXPbufferSGIX(pbuffer) +DestroyGLXPbufferSGIX(dpy, pbuffer) return void - param pbuffer Int32 in value + param dpy DisplayPointer in value + param pbuffer GLXPbuffer in value dlflags notlistable glxflags client-handcode category glx @@ -497,10 +534,11 @@ # ############################################################################### -JoinSwapGroupSGIX(window,group) +JoinSwapGroupSGIX(dpy, drawable, member) return void - param window Int32 in value - param group Int32 in value + param dpy DisplayPointer in value + param drawable GLXDrawable in value + param member GLXDrawable in value glxflags client-handcode server-handcode category glx dlflags notlistable @@ -512,17 +550,21 @@ # ############################################################################### -BindSwapBarrierSGIX(window,barrier) +BindSwapBarrierSGIX(dpy, drawable, barrier) return void - param window Int32 in value + param dpy DisplayPointer in value + param drawable GLXDrawable in value param barrier Int32 in value glxflags client-handcode server-handcode category glx dlflags notlistable glxvendorglx 65548 -QueryMaxSwapBarriersSGIX() - return void +QueryMaxSwapBarriersSGIX(dpy, screen, max) + return Bool + param dpy DisplayPointer in value + param screen Int32 in value + param max Int32 out value glxflags client-handcode server-handcode category glx dlflags notlistable --EeQfGwPcQSOJBaQU--