From pya...@ Wed Aug 1 03:04:45 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Aug 2012 12:04:45 +0200 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: <2027804580.383955.1343784861420.JavaMail.root@mozilla.com> References: <2027804580.383955.1343784861420.JavaMail.root@mozilla.com> Message-ID: On Wed, Aug 1, 2012 at 3:34 AM, Benoit Jacob wrote: > I don't see why webglcontextcreationerror would have to give away any > information. It can simply give a link to a browser-specific wiki page > where instructions can be found; going slightly further it can give > GPU-vendor-specific info about where to find drivers, which is like 2 bits > of info that can probably be obtained anyways by analyzing some rendering; > so it doesn't have to be a privacy issue and each browser vendor is free to > decide where to draw the line. > Having to obtain the GPU information by a heuristic is crap. You'd get to a page that would have to essentially say this: "We think you have an Nvidia-ish GPU (maybe), don't hit us if we're wrong, but look, here's (maybe) the Nvidia update page, sooooooo sorry if you're ATI, my bad." There three pieces of information required to make a remotely sensible choice of what to tell a user: Operating System Information: contained in the user-agent [OK] GPU name/vendor: [MISSING] Driver version: [MISSING] Those are not "2 bits". As to why that is required: 1) Update procedure is different depending on OS AND 2) Depending on the vendor, update procedure can be different depending on the GPU AND 3) Depending on the driver version an update might be recommended, or counterindicated We have also discussed the browsers doing that, with a helpful dialog, and a variety of non-annoying semantics, this however went nowhere as well. So this is todays situation: WebGL breaks randomly and nobody can do jack to help users. Not acceptable -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Wed Aug 1 04:09:57 2012 From: ash...@ (Ashley Gullen) Date: Wed, 1 Aug 2012 12:09:57 +0100 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: References: <2027804580.383955.1343784861420.JavaMail.root@mozilla.com> Message-ID: Is it possible user agents could offer to install driver updates automatically if WebGL is blacklisted and a newer driver is available? This does not expose any extra information and is just a single click for non-technical users. At least on Windows Vista and 7 apparently driver updates can be done without a reboot too. Also, does anyone know why driver updates are not being distributed? It seems a very large number of people have old drivers, but if they visit the AMD/nVidia/Intel website then newer ones are available. Why aren't those updates going over automatic update systems like Windows Update? That would help significantly with the WebGL driver problem. Ashley Gullen Scirra.com On 1 August 2012 11:04, Florian B?sch wrote: > On Wed, Aug 1, 2012 at 3:34 AM, Benoit Jacob wrote: > >> I don't see why webglcontextcreationerror would have to give away any >> information. It can simply give a link to a browser-specific wiki page >> where instructions can be found; going slightly further it can give >> GPU-vendor-specific info about where to find drivers, which is like 2 bits >> of info that can probably be obtained anyways by analyzing some rendering; >> so it doesn't have to be a privacy issue and each browser vendor is free to >> decide where to draw the line. >> > > Having to obtain the GPU information by a heuristic is crap. You'd get to > a page that would have to essentially say this: "We think you have an > Nvidia-ish GPU (maybe), don't hit us if we're wrong, but look, here's > (maybe) the Nvidia update page, sooooooo sorry if you're ATI, my bad." > > There three pieces of information required to make a remotely sensible > choice of what to tell a user: > > Operating System Information: contained in the user-agent [OK] > GPU name/vendor: [MISSING] > Driver version: [MISSING] > > Those are not "2 bits". As to why that is required: > > 1) Update procedure is different depending on OS AND > 2) Depending on the vendor, update procedure can be different depending on > the GPU AND > 3) Depending on the driver version an update might be recommended, or > counterindicated > > We have also discussed the browsers doing that, with a helpful dialog, and > a variety of non-annoying semantics, this however went nowhere as well. So > this is todays situation: > > WebGL breaks randomly and nobody can do jack to help users. > > Not acceptable > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Aug 1 04:28:13 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Aug 2012 13:28:13 +0200 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: References: <2027804580.383955.1343784861420.JavaMail.root@mozilla.com> Message-ID: On Wed, Aug 1, 2012 at 1:09 PM, Ashley Gullen wrote: > Also, does anyone know why driver updates are not being distributed? It > seems a very large number of people have old drivers, but if they visit the > AMD/nVidia/Intel website then newer ones are available. Why aren't those > updates going over automatic update systems like Windows Update? That > would help significantly with the WebGL driver problem. > On OSX, Apple usually doesn't update graphics drivers (much) in the current version, and major driver updates only arrive in newer versions of the OS, with older version not being updated at all anymore. Most people never update their OSX from what they have, but they'll buy a new machine eventually, having a new version it. For Apple, driver updates for their desktop style products is directly tied to their hardware sales turnover. On Linux drivers are a very mixed bag of goods, some users have up to date drivers, others don't for a variety of compatiblity/bug reasons. On Windows machines you need to differentiate between 3 classes of machines: 1) The enthusiast users who usually get their own machine (or build it) and install windows on it by themselves. 2) the OEM home users, who get their systems from the likes of Dell and HP 3) The business users, who get their machine provided for them by the IT-departement of whatever company they happen to be in Enthusiast users enjoy full admin priviledges on their machines and they often have updated drivers. However, a lot of those users are still using Windows XP, and driver vendors have sort of stopped providing drivers for XP since it'll soon reach its EOL, leaving a good chunk of these users with no viable upgrade path than to install Windows7 or Windows8. On any account this is a minority user group. OEM Home users get their machiens with extensive modification of the OEM which include changed update procedures, OEM specific bloatware and restricted admin priviledges. OEMs do this in order to provide unified support. They don't want to have to deal with a whole Zoo of issues as every user customizes his machines software. Consequently they make it difficult to do that, and often claim warranty void if you modify the software. OEMs are notorious for not updating drivers, ever. Again this stems from them not wanting to deal with a Zoo of issues. Unforunately a large portion of Windows users are OEM users. Business users do usually have no admin priviledges, and the IT departments of companies do not like to update their machines, ever, except for security patches. The update policy of those users is set by the business realities of the IT-department which tries to keep the corporate desktops secure and running with a minimum of effort. Updating drivers to get 3D working, which is not considered an essential business function in most companies, is therefore a net-loss activity because it does not deliver additional business value, but it costs money to keep drivers up to date and might throw up more work in case of the drivers introducing security issues and other support cases. For these reasons, the vast majority of desktop-style computer users never get driver updates, ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Wed Aug 1 08:20:13 2012 From: ash...@ (Ashley Gullen) Date: Wed, 1 Aug 2012 16:20:13 +0100 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: References: <2027804580.383955.1343784861420.JavaMail.root@mozilla.com> Message-ID: Gee, so I guess even if a browser offered to install a driver update automatically then most users still wouldn't be able to? Sounds like the only solution is to wait for everyone to buy new computers. Could be a few years before this problem evaporates completely but it will get there eventually I suppose. Ashley On 1 August 2012 12:28, Florian B?sch wrote: > On Wed, Aug 1, 2012 at 1:09 PM, Ashley Gullen wrote: > >> Also, does anyone know why driver updates are not being distributed? It >> seems a very large number of people have old drivers, but if they visit the >> AMD/nVidia/Intel website then newer ones are available. Why aren't those >> updates going over automatic update systems like Windows Update? That >> would help significantly with the WebGL driver problem. >> > > On OSX, Apple usually doesn't update graphics drivers (much) in the > current version, and major driver updates only arrive in newer versions of > the OS, with older version not being updated at all anymore. Most people > never update their OSX from what they have, but they'll buy a new machine > eventually, having a new version it. For Apple, driver updates for their > desktop style products is directly tied to their hardware sales turnover. > > On Linux drivers are a very mixed bag of goods, some users have up to date > drivers, others don't for a variety of compatiblity/bug reasons. > > On Windows machines you need to differentiate between 3 classes of > machines: > 1) The enthusiast users who usually get their own machine (or build it) > and install windows on it by themselves. > 2) the OEM home users, who get their systems from the likes of Dell and HP > 3) The business users, who get their machine provided for them by the > IT-departement of whatever company they happen to be in > > Enthusiast users enjoy full admin priviledges on their machines and they > often have updated drivers. However, a lot of those users are still using > Windows XP, and driver vendors have sort of stopped providing drivers for > XP since it'll soon reach its EOL, leaving a good chunk of these users with > no viable upgrade path than to install Windows7 or Windows8. On any account > this is a minority user group. > > OEM Home users get their machiens with extensive modification of the OEM > which include changed update procedures, OEM specific bloatware and > restricted admin priviledges. OEMs do this in order to provide unified > support. They don't want to have to deal with a whole Zoo of issues as > every user customizes his machines software. Consequently they make it > difficult to do that, and often claim warranty void if you modify the > software. OEMs are notorious for not updating drivers, ever. Again this > stems from them not wanting to deal with a Zoo of issues. Unforunately a > large portion of Windows users are OEM users. > > Business users do usually have no admin priviledges, and the IT > departments of companies do not like to update their machines, ever, except > for security patches. The update policy of those users is set by the > business realities of the IT-department which tries to keep the corporate > desktops secure and running with a minimum of effort. Updating drivers to > get 3D working, which is not considered an essential business function in > most companies, is therefore a net-loss activity because it does not > deliver additional business value, but it costs money to keep drivers up to > date and might throw up more work in case of the drivers introducing > security issues and other support cases. > > For these reasons, the vast majority of desktop-style computer users never > get driver updates, ever. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Aug 1 09:02:57 2012 From: bja...@ (Benoit Jacob) Date: Wed, 1 Aug 2012 09:02:57 -0700 (PDT) Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: Message-ID: <1504456915.514463.1343836977222.JavaMail.root@mozilla.com> Either OEMs or Microsoft (not sure -- maybe both) can install driver updates automatically. Convincing either about the need for that, is the only thing I can see that would make a large difference overall. For the segment of experienced users, actually, here is something we can do that would give specific instructions without compromising privacy: how about, when context creation fails, using the canvas area to display the informative message? There is no way for Web content to read back the content of a canvas that doesn't have a context, so we should be able to put all the information that we want there, without compromising security or privacy at all. Thoughts? Benoit ----- Original Message ----- > Gee, so I guess even if a browser offered to install a driver update > automatically then most users still wouldn't be able to? > Sounds like the only solution is to wait for everyone to buy new > computers. Could be a few years before this problem evaporates > completely but it will get there eventually I suppose. > Ashley > On 1 August 2012 12:28, Florian B?sch < pyalot...@ > wrote: > > On Wed, Aug 1, 2012 at 1:09 PM, Ashley Gullen < ashley...@ > > > wrote: > > > > Also, does anyone know why driver updates are not being > > > distributed? > > > It seems a very large number of people have old drivers, but if > > > they > > > visit the AMD/nVidia/Intel website then newer ones are available. > > > Why aren't those updates going over automatic update systems like > > > Windows Update? That would help significantly with the WebGL > > > driver > > > problem. > > > > > On OSX, Apple usually doesn't update graphics drivers (much) in the > > current version, and major driver updates only arrive in newer > > versions of the OS, with older version not being updated at all > > anymore. Most people never update their OSX from what they have, > > but > > they'll buy a new machine eventually, having a new version it. For > > Apple, driver updates for their desktop style products is directly > > tied to their hardware sales turnover. > > > On Linux drivers are a very mixed bag of goods, some users have up > > to > > date drivers, others don't for a variety of compatiblity/bug > > reasons. > > > On Windows machines you need to differentiate between 3 classes of > > machines: > > > 1) The enthusiast users who usually get their own machine (or build > > it) and install windows on it by themselves. > > > 2) the OEM home users, who get their systems from the likes of Dell > > and HP > > > 3) The business users, who get their machine provided for them by > > the > > IT-departement of whatever company they happen to be in > > > Enthusiast users enjoy full admin priviledges on their machines and > > they often have updated drivers. However, a lot of those users are > > still using Windows XP, and driver vendors have sort of stopped > > providing drivers for XP since it'll soon reach its EOL, leaving a > > good chunk of these users with no viable upgrade path than to > > install Windows7 or Windows8. On any account this is a minority > > user > > group. > > > OEM Home users get their machiens with extensive modification of > > the > > OEM which include changed update procedures, OEM specific bloatware > > and restricted admin priviledges. OEMs do this in order to provide > > unified support. They don't want to have to deal with a whole Zoo > > of > > issues as every user customizes his machines software. Consequently > > they make it difficult to do that, and often claim warranty void if > > you modify the software. OEMs are notorious for not updating > > drivers, ever. Again this stems from them not wanting to deal with > > a > > Zoo of issues. Unforunately a large portion of Windows users are > > OEM > > users. > > > Business users do usually have no admin priviledges, and the IT > > departments of companies do not like to update their machines, > > ever, > > except for security patches. The update policy of those users is > > set > > by the business realities of the IT-department which tries to keep > > the corporate desktops secure and running with a minimum of effort. > > Updating drivers to get 3D working, which is not considered an > > essential business function in most companies, is therefore a > > net-loss activity because it does not deliver additional business > > value, but it costs money to keep drivers up to date and might > > throw > > up more work in case of the drivers introducing security issues and > > other support cases. > > > For these reasons, the vast majority of desktop-style computer > > users > > never get driver updates, ever. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Aug 1 09:10:09 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Aug 2012 18:10:09 +0200 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: <1504456915.514463.1343836977222.JavaMail.root@mozilla.com> References: <1504456915.514463.1343836977222.JavaMail.root@mozilla.com> Message-ID: On Wed, Aug 1, 2012 at 6:02 PM, Benoit Jacob wrote: > For the segment of experienced users, actually, here is something we can > do that would give specific instructions without compromising privacy: how > about, when context creation fails, using the canvas area to display the > informative message? There is no way for Web content to read back the > content of a canvas that doesn't have a context, so we should be able to > put all the information that we want there, without compromising security > or privacy at all. > > Thoughts? > I generally like the idea of the browser handling any message to convey that webgl is not working because... and maybe try... I'm not sure if the canvas is the perfect though in two cases: 1) some kind of fallback scheme which would result in some situations in the canvas quickly flickering the message before it disappears 2) In case you add many canvas elements on the page, you'll get a whole page full of the same text (kind of like filling the page with broken images symbols or non-working java applets) In most cases putting the help message in the canvas is probably ok though. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Wed Aug 1 16:06:34 2012 From: kos...@ (David Sheets) Date: Wed, 1 Aug 2012 16:06:34 -0700 Subject: [Public WebGL] WEBGL_dynamic_texture extension proposal In-Reply-To: <5017601A.1020000@hicorp.co.jp> References: <4FF5468E.5000603@hicorp.co.jp> <4FF66222.8080702@hicorp.co.jp> <4FFE82C8.50801@hicorp.co.jp> <500D02B6.9010007@hicorp.co.jp> <5017601A.1020000@hicorp.co.jp> Message-ID: > On 26/07/2012 10:51, David Sheets wrote: >> The stream producer interface would be useful to any component >> (standard or custom) that wishes to supply a dynamic, >> time-synchronized texture stream to a stream consumer ... > In essence this means this WebGL extension will include extensions for > other HTML elements. If nobody here objects to it doing so, then in the > next draft I'll add a stream producer interface which will be used to > acquire image frames, etc. I look forward to implementing dynamic texture pipelines sourced from WebWorkers. >>>> The browser has a handful of metrics useful to the page for estimating >>>> time-to-render latency. ... >>> Do the browsers currently expose these metrics to JS apps? If so, where is >>> the API documented? >> To my knowledge, these metrics are presently unavailable to scripts >> except through per-page-load benchmarking. > Is there any documentation anywhere about these metrics? I'm not > actually sure they are useful in this case but it would be helpful to > know what they are. Any formal or informal model of CPU-GPU systems contains these heuristics. This system modeling is precisely the mandate of The Khronos Group. Here are a few potential dimensions: - uncontended API -> GPU command latency (driver, bus, thread dispatch stages) - uncontended API -> GPU data throughput (driver, bus, thread dispatch stages) - page composite latency - video decode latency - estimated render latency of shader S No model of these systems will be complete (it's an abstract model...) but some control more than "I just use 50ms for my consumer latency" would be nice. Even a single dimension: - estimated time-to-render for shader S would be appreciated. I believe the proposal to just guess a latency was already floated. I would like to guess a latency that has some bearing to the host's underlying characteristics based on my model of my specific rendering application. > Separately but related I was already aware of the issue Florian pointed > out that the WebGL application does not know when the final page image > will appear on the screen. I intend to look at previous GL extensions > that have dealt with similar issues and propose a solution. There are no guarantees but instead "best effort" for time slices of shared, asynchronous resources. It seems to be working pretty well for the net and RTT distribution parameters are successfully employed in latency compensation for real-time internetwork applications. >> I am stacking dynamic textures 4 deep sourced from a single video >> element. V => A => B => C where B and C may depend on any subset of >> previous producers in the chain. >> >> In this use case, HTMLVideoElement V has <=3 different consumer >> latencies, WebGLRenderingContext A has <=2 consumer latencies, etc. >> >> Should 3 separate HTMLVideoElements be created with the same video >> source? How do I keep them in sync? > As best I can understand your scenario you are composing several video > frames to produce a final image. Keeping in mind that the purpose of > setting the consumer latency is so the producer can keep the audio > synchronized, the answer to your question is to set the latency to the > time from acquiring the first image frame to when the final composited > image is displayed. How do I get frames at specific temporal spacings? Declaring latency is a solution for stream synchronization. We have 2+ streams: audio and one or more video streams (possibly from 1 decoder) but only a way to declare a single stream-stream latency (audio relative to _this_ dynamic texture acquisition). How do I synchronize video streams with each other? >> Sampling does not need to be available for non-RGBA colorspaces >> (samplerExternalYUV would be abstract and only consumed by >> conversion). Colorspace conversion branching can be done at >> compile-time using overloaded convertColorspaceRGBA(...) and sampler >> type -> sampler type macro renames. With this design, the colorspace >> sampler type names do not have to be standard -- simply available to >> the page and overloaded in the GLSL conversion functions. This gives >> the page author the most control and performance and is a superset of >> the presently proposed functionality. The author is now free to choose >> at what time the sampler conversion should be specialized and may >> anticipate format changes in advance of their occurrence and compile >> the appropriate shader before it is needed. > I don't entirely understand what you are proposing but the following > points must be kept in mind: > > * The spec. already says that the author's shader receives > colorspace-normalized RGBA data when sampling an external texture. The phases in which the colorspace normalization and per-colorspace branching occur are unspecified. > * The sampler conversion cannot be specialized at compile-time > o The video format can change at any time, even within a video > when adaptive streaming is used and there is no way for the > application to be notified when it changes. This is known to the decoder. Decoder can say "samplerExternalOESReallyReallyDynamic". Author can always elect to use the most generic sampler supertype. No guarantee is made for reuse of a specialized shader with dynamic texture sources of type outside supplied sum type. > o The value of the sampler variable can be changed at any time via > the API Only samplers of the same type (or compatible subtype) may be bound. As Acorn elaborated, "You would not create a cubemap texture and then try to use it as a 3D texture, right?" > * We cannot allow general texture operations (copyTexImage, > tex{,Sub}Image, etc) to external textures because the hardware > generally does not support the necessary conversions when those > textures are YUV, even hardware that supports EGLStreams. Do not overload those API calls for non-RGBA textures. > * There is an enormous number of YUV formats. Check out fourcc.org > . Generally the format information is > only available at very low levels in the software stack (e.g., the > OpenMAX IL level). The API's provided for applications to play video > (e.g. OpenMAX AL) do not provide the information. Forcing every > author who wants to texture some geometry with video to have to deal > with all this is doing them a great disservice. Function overloading means there is neither forcing to handle colorspace conversion nor to incur branching in an inconvenient phase. Consider: samplerExternalOES convertColorspaceRGBA(samplerExternalSuperDynamic) // present proposal implicit in texture2D overload, very conditional samplerExternalOES convertColorspaceRGBA(samplerExternalQ) // possible conditional host-specific, fresh sampler type for video format F samplerExternalOES convertColorspaceRGBA(samplerExternalX) // possible host-specific, fresh sampler type for shared texture from another context Authors who do not care may always use samplerExternalSuperDynamic which is effectively the conditional sum of every possible dynamic texture format decided at the last possible moment. Authors who care may query their source for a specialized sampler type and select the conversion branch at the time of their earliest convenience. No colorspace information is leaked. The sampler type names may be generated fresh for each query. Extremely common dynamic texture colorspaces may be standardized and overloaded at will (RGBA 8888 seems like a good candidate). Consider a video pipeline with 3 shader stages. As author, I use several generic processing stages from a common library. In the construction of my application, I know I will always use these stages in a specific configuration. If authors are forced to use an API that does not give them the ability to specialize their shaders to their pipeline configuration, they will pay for conditionals over "an enormous number of YUV formats" at every stage. Is that a good idea for mobile phones and tablets? >> TeX is a fine source language. DocBook is a fine target language. No >> manual conversion is necessary. >> >> Many HTML-of-TeX convertors exist not the least of which is HeVeA >> . >> >> I'm sure someone in our community would contribute a build system for >> converting the present TeX source into (X)HTML provided the spec >> source was made public. >> >> Will Khronos publish the TeX source for the specification of the Open Standard? > The question has never been raised before and therefore never > discussed. I personally don't see any reason why not. I'll raise the > question in Khronos. Thank you. > As far as I'm concerned the only reason for using PDF is because you > have everything in a single file. I do wish the browser makers would > support MHTML or something like it. HTML supports inline styles, inline scripts, inline raster images in data: URLs, and inline vector images with SVG. What other media is included in Khronos specification documents? >> Are OpenGL ES extensions drafted in text/plain as they are published? >> I may or may not already have a parser for this format. > Yes they are drafted in text/plain. You find the template at > http://www.opengl.org/registry/doc/template.txt. There was talk of > moving to DocBook but it hasn't happened. I'm sure something will turn up. Regards, David > Regards > > -Mark ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kos...@ Wed Aug 1 16:07:57 2012 From: kos...@ (David Sheets) Date: Wed, 1 Aug 2012 16:07:57 -0700 Subject: [Public WebGL] WEBGL_dynamic_texture extension proposal In-Reply-To: <501762BC.2020105@hicorp.co.jp> References: <4FF5468E.5000603@hicorp.co.jp> <4FF66222.8080702@hicorp.co.jp> <4FFE82C8.50801@hicorp.co.jp> <500D02B6.9010007@hicorp.co.jp> <5017601A.1020000@hicorp.co.jp> <501762BC.2020105@hicorp.co.jp> Message-ID: >>> Will Khronos publish the TeX source for the specification of the Open >>> Standard? >> >> The question has never been raised before and therefore never discussed. I >> personally don't see any reason why not. I'll raise the question in Khronos. > > David, > > What do you see as the advantages of > (a) the TeX source being made available The OpenGL specifications are Open Standards consumed by any living human with an interest in standardized graphics rendering and internet access. The specifications are drafted in TeX and then translated into publication format(s). This translation step almost always loses semantic information and typically adds structural, stylistic noise. By publishing the TeX source: - The standard can go anywhere (epub? docbook? man pages? texinfo?) at any granularity (quoted fragment excerpts) - The barrier to community contribution to fix formatting or typographic errors is drastically reduced - Derivative formats may be of the highest possible fidelity to the standard as drafted - Khronos retains control over the official source of the standard instead of forcing hostile document extractions > and (b) having an HTML version of the OpenGL specifications? The OpenGL specifications are primarily distributed using the World Wide Web which uses HTML as its primary document format. The advantages of HTML include: - Well-defined document fragment user-agent behavior for incoming and outgoing links - A variety of mechanisms for dealing with specific user-agent rendering constraints (screen sizes, media formats, accessibility) - A huge number of parsers and document editors including browser extensions enabling collaborative annotations - Excellent hyperlink navigation integration in user-agents (tabs!) The King of the Titans may also be interested in as a popular many-to-many document conversion solution. David > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kpr...@ Wed Aug 1 17:47:39 2012 From: kpr...@ (Kevin Reid) Date: Wed, 1 Aug 2012 17:47:39 -0700 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: <1504456915.514463.1343836977222.JavaMail.root@mozilla.com> References: <1504456915.514463.1343836977222.JavaMail.root@mozilla.com> Message-ID: <272839B9-C10D-43C1-B2DD-CC2F425C9B99@switchb.org> On Aug 1, 2012, at 9:02, Benoit Jacob wrote: > For the segment of experienced users, actually, here is something we can do that would give specific instructions without compromising privacy: how about, when context creation fails, using the canvas area to display the informative message? There is no way for Web content to read back the content of a canvas that doesn't have a context, so we should be able to put all the information that we want there, without compromising security or privacy at all. Nitpick: The canvas element itself provides toDataURL(...), independent of any context, which allows reading the contents of the canvas. However, there are at least two possibilities for mostly-compatible extension: - toDataURL may throw if the canvas is not origin-clean; having this case throw as well would likely not break much. - The canvas could be *rendered* in the document with the informative message, but not actually contain the message as its image data. I also note that unsupported image formats and missing plugins are both precedent for displaying browser-specific error indications inside the area of the element. -- Kevin Reid ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Wed Aug 1 18:01:57 2012 From: ben...@ (Ben Vanik) Date: Wed, 1 Aug 2012 18:01:57 -0700 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: <272839B9-C10D-43C1-B2DD-CC2F425C9B99@switchb.org> References: <1504456915.514463.1343836977222.JavaMail.root@mozilla.com> <272839B9-C10D-43C1-B2DD-CC2F425C9B99@switchb.org> Message-ID: I'd steer clear of this route - it doesn't solve a lot of core scenarios and is messy in the rest of them. Browser vendor time would be much better spent on more robust solutions (infobars like Chrome has/etc). Hopefully some work here will be coming soon. On Wed, Aug 1, 2012 at 5:47 PM, Kevin Reid wrote: > > On Aug 1, 2012, at 9:02, Benoit Jacob wrote: > > > For the segment of experienced users, actually, here is something we can > do that would give specific instructions without compromising privacy: how > about, when context creation fails, using the canvas area to display the > informative message? There is no way for Web content to read back the > content of a canvas that doesn't have a context, so we should be able to > put all the information that we want there, without compromising security > or privacy at all. > > Nitpick: The canvas element itself provides toDataURL(...), independent of > any context, which allows reading the contents of the canvas. However, > there are at least two possibilities for mostly-compatible extension: > > - toDataURL may throw if the canvas is not origin-clean; having this case > throw as well would likely not break much. > > - The canvas could be *rendered* in the document with the informative > message, but not actually contain the message as its image data. > > I also note that unsupported image formats and missing plugins are both > precedent for displaying browser-specific error indications inside the area > of the element. > > -- > Kevin Reid > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Aug 1 19:04:29 2012 From: bja...@ (Benoit Jacob) Date: Wed, 1 Aug 2012 19:04:29 -0700 (PDT) Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: Message-ID: <1402042138.738083.1343873069712.JavaMail.root@mozilla.com> I didn't know that Chrome had infobars for that, that sounds like it can be a good idea, but how do you solve the problem of knowing when to display the infobar vs. let the page silently fall back to a solution that doesn't involve WebGL without disrupting it? Or do you unconditionally display the infobar? Benoit ----- Original Message ----- > I'd steer clear of this route - it doesn't solve a lot of core > scenarios and is messy in the rest of them. Browser vendor time > would be much better spent on more robust solutions (infobars like > Chrome has/etc). Hopefully some work here will be coming soon. > On Wed, Aug 1, 2012 at 5:47 PM, Kevin Reid < kpreid...@ > > wrote: > > On Aug 1, 2012, at 9:02, Benoit Jacob wrote: > > > > For the segment of experienced users, actually, here is something > > > we can do that would give specific instructions without > > > compromising privacy: how about, when context creation fails, > > > using the canvas area to display the informative message? There > > > is > > > no way for Web content to read back the content of a canvas that > > > doesn't have a context, so we should be able to put all the > > > information that we want there, without compromising security or > > > privacy at all. > > > Nitpick: The canvas element itself provides toDataURL(...), > > independent of any context, which allows reading the contents of > > the > > canvas. However, there are at least two possibilities for > > mostly-compatible extension: > > > - toDataURL may throw if the canvas is not origin-clean; having > > this > > case throw as well would likely not break much. > > > - The canvas could be *rendered* in the document with the > > informative > > message, but not actually contain the message as its image data. > > > I also note that unsupported image formats and missing plugins are > > both precedent for displaying browser-specific error indications > > inside the area of the element. > > > -- > > > Kevin Reid < http://switchb.org/kpreid/ > > > > ----------------------------------------------------------- > > > You are currently subscribed to public_webgl...@ . > > > To unsubscribe, send an email to majordomo...@ with > > > the following command in the body of your email: > > > unsubscribe public_webgl > > > ----------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Aug 2 02:24:30 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 2 Aug 2012 11:24:30 +0200 Subject: [Public WebGL] blacklisting NVIDIA proprietary Linux drivers older than 295.* in chrome In-Reply-To: <1402042138.738083.1343873069712.JavaMail.root@mozilla.com> References: <1402042138.738083.1343873069712.JavaMail.root@mozilla.com> Message-ID: On Thu, Aug 2, 2012 at 4:04 AM, Benoit Jacob wrote: > I didn't know that Chrome had infobars for that, that sounds like it can > be a good idea, but how do you solve the problem of knowing when to display > the infobar vs. let the page silently fall back to a solution that doesn't > involve WebGL without disrupting it? Or do you unconditionally display the > infobar? > - websites would have to indicate if they want the infobar help - the user will see the infobar depending on his choice of "Yes show me why" or "Not now" or "Don't show this again" - some conditions like a changed blacklist affecting the users or a changed driver/gpu could maybe be exceptions to the "Don't show this again" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu Aug 2 12:17:58 2012 From: bja...@ (Benoit Jacob) Date: Thu, 2 Aug 2012 12:17:58 -0700 (PDT) Subject: [Public WebGL] Nearly 4x more Firefox users visit Websites that use WebGL, than 6 months ago In-Reply-To: <2028731999.3014699.1343934919872.JavaMail.root@mozilla.com> Message-ID: <826564299.3014937.1343935078321.JavaMail.root@mozilla.com> That is, at least, if the data here is correct: http://people.mozilla.org/~bjacob/gfx_features_stats/#webgl-attempts That is, assuming that collecting this data from crash reports doesn't skew the results too much. In 6 months, we went from 1.2% to > 4%, with currently a sudden spike at over 6%. In other news (visible elsewhere on the same page), the overall WebGL context creation success rate in Firefox is now 53%; it is about 65% on Win7 and 75% on Win8. Cheers, Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Aug 2 12:32:17 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 2 Aug 2012 21:32:17 +0200 Subject: [Public WebGL] Nearly 4x more Firefox users visit Websites that use WebGL, than 6 months ago In-Reply-To: <826564299.3014937.1343935078321.JavaMail.root@mozilla.com> References: <2028731999.3014699.1343934919872.JavaMail.root@mozilla.com> <826564299.3014937.1343935078321.JavaMail.root@mozilla.com> Message-ID: On Thu, Aug 2, 2012 at 9:17 PM, Benoit Jacob wrote: > > That is, at least, if the data here is correct: > > http://people.mozilla.org/~bjacob/gfx_features_stats/#webgl-attempts > > That is, assuming that collecting this data from crash reports doesn't > skew the results too much. In 6 months, we went from 1.2% to > 4%, with > currently a sudden spike at over 6%. > > In other news (visible elsewhere on the same page), the overall WebGL > context creation success rate in Firefox is now 53%; it is about 65% on > Win7 and 75% on Win8. > Does this mean people are more enthusiastic and seek out more webgl content, or is there more webgl content on the web? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Aug 2 17:22:51 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 2 Aug 2012 17:22:51 -0700 Subject: [Public WebGL] Nearly 4x more Firefox users visit Websites that use WebGL, than 6 months ago In-Reply-To: <826564299.3014937.1343935078321.JavaMail.root@mozilla.com> References: <2028731999.3014699.1343934919872.JavaMail.root@mozilla.com> <826564299.3014937.1343935078321.JavaMail.root@mozilla.com> Message-ID: Interesting news! Regardless of how the data is interpreted, definitely shows increased usage! Let's continue to work on robust and consistent behavior across implementations. -Ken On Thu, Aug 2, 2012 at 12:17 PM, Benoit Jacob wrote: > > That is, at least, if the data here is correct: > > http://people.mozilla.org/~bjacob/gfx_features_stats/#webgl-attempts > > That is, assuming that collecting this data from crash reports doesn't skew the results too much. In 6 months, we went from 1.2% to > 4%, with currently a sudden spike at over 6%. > > In other news (visible elsewhere on the same page), the overall WebGL context creation success rate in Firefox is now 53%; it is about 65% on Win7 and 75% on Win8. > > Cheers, > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Aug 3 06:36:22 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 3 Aug 2012 15:36:22 +0200 Subject: [Public WebGL] Oculus Rift Message-ID: I've just written a blog entry on this http://codeflow.org/entries/2012/aug/03/oculus-rift/#webgl-oculus-rift and I'm really excited about this device. I would love to get support for it in WebGL :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Aug 3 09:14:59 2012 From: ben...@ (Ben Vanik) Date: Fri, 3 Aug 2012 09:14:59 -0700 Subject: [Public WebGL] Oculus Rift In-Reply-To: References: Message-ID: I backed it as well, thinking of WebGL. The display portion should be doable right away (stereo shaders + fullscreen mode), but the input will be trickier. An npapi plugin that exposed the gyro/accel would be easy to throw together and could be released as an extension. If the device takes off maybe even exposing that data through the device APIs in the browser would be feasible, depending on how good their SDK is. On Friday, August 3, 2012, Florian B?sch wrote: > I've just written a blog entry on this > http://codeflow.org/entries/2012/aug/03/oculus-rift/#webgl-oculus-rift and > I'm really excited about this device. I would love to get support for it in > WebGL :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 3 09:28:30 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 3 Aug 2012 18:28:30 +0200 Subject: [Public WebGL] Oculus Rift In-Reply-To: References: Message-ID: On Fri, Aug 3, 2012 at 6:14 PM, Ben Vanik wrote: > I backed it as well, thinking of WebGL. The display portion should be > doable right away (stereo shaders + fullscreen mode), It seems they're targeting a single screen 720p output and split it down the middle for each eye, so that's easy enough for a start if so. But I think those devices will evolve non standard resolutions or multi-port inputs (it's obvious that if something like this takes off it'll target full-hd for each eye eventually). > but the input will be trickier. An npapi plugin that exposed the > gyro/accel would be easy to throw together and could be released as an > extension. If the device takes off maybe even exposing that data through > the device APIs in the browser would be feasible, depending on how good > their SDK is. The input will go over USB and it'll probably have driver support in the host OS, so it's probably just like a gamepad. There are definitely latency/resolution issues in the gamepad API though. What's bothering me a bit about it is ease of use. With the hodgepodge fullscreen + gamepad approach it'd be like: 1) Now drag your browser to the right "monitor" 2) Now click fullscreen 3) Now click acquire gamepad 4) Now tell the app this gamepad is the head tracker 5) Good to go Ideally it should be something like "We detected you have a Oculus device, do you want to switch to that? [Yes]" -> done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Fri Aug 3 12:21:38 2012 From: vla...@ (Vladimir Vukicevic) Date: Fri, 3 Aug 2012 12:21:38 -0700 (PDT) Subject: [Public WebGL] Oculus Rift In-Reply-To: Message-ID: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> I've backed it; I'll hack in browser event support once I get my hands on a SDK :D - Vlad ----- Original Message ----- > I backed it as well, thinking of WebGL. The display portion should be > doable right away (stereo shaders + fullscreen mode), but the input > will be trickier. An npapi plugin that exposed the gyro/accel would > be easy to throw together and could be released as an extension. If > the device takes off maybe even exposing that data through the > device APIs in the browser would be feasible, depending on how good > their SDK is. > > On Friday, August 3, 2012, Florian B?sch wrote: > > > I've just written a blog entry on this > http://codeflow.org/entries/2012/aug/03/oculus-rift/#webgl-oculus-rift > and I'm really excited about this device. I would love to get > support for it in WebGL :) ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Aug 3 12:55:54 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 3 Aug 2012 21:55:54 +0200 Subject: [Public WebGL] Oculus Rift In-Reply-To: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> References: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> Message-ID: On Fri, Aug 3, 2012 at 9:21 PM, Vladimir Vukicevic wrote: > I've backed it; I'll hack in browser event support once I get my hands on > a SDK :D I don't think we'll have to wait for that. Ideally I'd like the browsers to be able to support it the moment the dev kits hit the street for two reasons: 1) It gives Oculus an even better running start 2) It promotes HTML5/WebGL as a serious platform (huge PR win, Carmack is always dissing us) I'd suggest a two-pronged strategy. Can we get google and/or mozilla in contact with Oculus VR to obtain information/sdk and start a collaboration? It doesn't have to be a dev kit (although that would definitely help too). Failing or complementing that we know: - It's using a single screen output split in the middle, fed to by DVI. - Due to some lens arrangement the geometry for each eye is not equirectangular, so we know we'll need some vertex transform a little different than equirectangular. - We know it will deliver its inputs via USB, which probably means it'll just be a 6-axis joystick. If we could corroborate/confirm this and get some information whatsoever, we can start preparing the ground. We can cook up a few helpers/tutorials/examples to render the scene twice with the required geometry. And we could start with an napi plugin. Incidentally I have a 6-axis mouse on my table I could use for mock input. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emo...@ Fri Aug 3 14:07:09 2012 From: emo...@ (=?utf-8?Q?Erik_M=C3=B6ller?=) Date: Fri, 03 Aug 2012 23:07:09 +0200 Subject: [Public WebGL] Oculus Rift In-Reply-To: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> References: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> Message-ID: Same here! On Fri, 03 Aug 2012 21:21:38 +0200, Vladimir Vukicevic wrote: > > I've backed it; I'll hack in browser event support once I get my hands > on a SDK :D > > - Vlad > > ----- Original Message ----- >> I backed it as well, thinking of WebGL. The display portion should be >> doable right away (stereo shaders + fullscreen mode), but the input >> will be trickier. An npapi plugin that exposed the gyro/accel would >> be easy to throw together and could be released as an extension. If >> the device takes off maybe even exposing that data through the >> device APIs in the browser would be feasible, depending on how good >> their SDK is. >> >> On Friday, August 3, 2012, Florian B?sch wrote: >> >> >> I've just written a blog entry on this >> http://codeflow.org/entries/2012/aug/03/oculus-rift/#webgl-oculus-rift >> and I'm really excited about this device. I would love to get >> support for it in WebGL :) > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- -- Erik M?ller Core Developer Opera Software twitter.com/erikjmoller ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Fri Aug 3 17:39:28 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 3 Aug 2012 17:39:28 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <5018C2B0.1010500@hicorp.co.jp> References: <1025309454.414188.1343793930645.JavaMail.root@mozilla.com> <5018C2B0.1010500@hicorp.co.jp> Message-ID: So apparently the Math extension has been used extensively in the OpenGL wikis for years. It's now on in the WebGL wiki Also the iframe widget is in. I'd like to propose a guideline that iframes will only be used for context hosted on khronos.org so if you want to put a sample in, add it to the repo through github first. Example of both features is here http://www.khronos.org/webgl/wiki/Test (ps: Yes, I know that iframe sample is not on khronos.org) Also, I'll see if I can write up some guidelines. It's relatively easy to setup CSS for a sample so that if the sample is run in a window by itself it has different styles than when run in an iframe. On Tue, Jul 31, 2012 at 10:46 PM, Mark Callow wrote: > On 01/08/2012 13:05, Benoit Jacob wrote: > > Wonderful! I didn't know about that, but that project is doing exacty the right thing. > > A Google search for Mathjax Mediawiki returned this result: > http://www.mediawiki.org/wiki/Extension:MathJax > > I would be more convinced of both the claimed ease of installation of > this Wiki extension and it working if the above page contained an example. > Instead it contains a link to a, er ..., .png file to show you what the how > the example source is rendered. What's with that? > > > Regards > > -Mark > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Aug 3 17:45:50 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 3 Aug 2012 17:45:50 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1025309454.414188.1343793930645.JavaMail.root@mozilla.com> <5018C2B0.1010500@hicorp.co.jp> Message-ID: Oh, and also a big shout out thank you to James Riordon, the Khronos.org webmaster for getting this all setup. He also got the directory listings prettified https://www.khronos.org/registry/webgl/sdk/tests/conformance/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Aug 3 18:43:14 2012 From: bja...@ (Benoit Jacob) Date: Fri, 3 Aug 2012 18:43:14 -0700 (PDT) Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: Message-ID: <240385438.3399153.1344044594432.JavaMail.root@mozilla.com> ----- Original Message ----- > So apparently the Math extension has been used extensively in the > OpenGL wikis for years. It's now on in the WebGL wiki OK, cool! That is definitely good enough to get started, and it will be easy to switch to MathJax afterwards as it's LaTeX syntax. Still, it would be really cool if the MathJax extension could be installed in the WebGL wiki, so we could try it out. The benefit would be generating actual text on the client side, as opposed to fix ed-size bitmaps on the server side. > Also the iframe widget is in. I'd like to propose a guideline that > iframes will only be used for context hosted on khronos.org so if > you want to put a sample in, add it to the repo through github > first. OK, makes sense. > Example of both features is here > http://www.khronos.org/webgl/wiki/Test > (ps: Yes, I know that iframe sample is not on khronos.org ) Very cool! Where should we put the WebGL method "man pages" ? Benoit > Also, I'll see if I can write up some guidelines. It's relatively > easy to setup CSS for a sample so that if the sample is run in a > window by itself it has different styles than when run in an iframe. > On Tue, Jul 31, 2012 at 10:46 PM, Mark Callow < > callow_mark...@ > wrote: > > On 01/08/2012 13:05, Benoit Jacob wrote: > > > > Wonderful! I didn't know about that, but that project is doing > > > exacty > > > the right thing. > > > > > > A Google search for Mathjax Mediawiki returned this result: > > > http://www.mediawiki.org/wiki/Extension:MathJax > > > > > I would be more convinced of both the claimed ease of installation > > of > > this Wiki extension and it working if the above page contained an > > example. Instead it contains a link to a, er ..., .png file to show > > you what the how the example source is rendered. What's with that? > > > Regards > > > -Mark > > > -- > > > ???????????????????????????????????????????????????????????????? > > ???????????????????????????????????????????????????????????????? > > ??? > > > NOTE: This electronic mail message may contain confidential and > > privileged information from HI Corporation. If you are not the > > intended recipient, any disclosure, photocopying, distribution or > > use of the contents of the received information is prohibited. If > > you have received this e-mail in error, please notify the sender > > immediately and permanently delete this message and all related > > copies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Aug 4 12:21:58 2012 From: kbr...@ (Kenneth Russell) Date: Sat, 4 Aug 2012 12:21:58 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1025309454.414188.1343793930645.JavaMail.root@mozilla.com> <5018C2B0.1010500@hicorp.co.jp> Message-ID: Awesome! Gregg, thanks to you and James for getting this set up! Crowdsourced WebGL reference pages...will be interesting! -Ken On Fri, Aug 3, 2012 at 5:45 PM, Gregg Tavares (??) wrote: > Oh, and also a big shout out thank you to James Riordon, the Khronos.org > webmaster for getting this all setup. > > He also got the directory listings prettified > https://www.khronos.org/registry/webgl/sdk/tests/conformance/ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Sat Aug 4 12:31:43 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 4 Aug 2012 21:31:43 +0200 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1025309454.414188.1343793930645.JavaMail.root@mozilla.com> <5018C2B0.1010500@hicorp.co.jp> Message-ID: Can we get it to look a bit more snazzy like http://docs.python.org/library/ or http://webglref.codeflow.org/index.html ? On Sat, Aug 4, 2012 at 9:21 PM, Kenneth Russell wrote: > > Awesome! Gregg, thanks to you and James for getting this set up! > > Crowdsourced WebGL reference pages...will be interesting! > > -Ken > > > On Fri, Aug 3, 2012 at 5:45 PM, Gregg Tavares (??) > wrote: > > Oh, and also a big shout out thank you to James Riordon, the Khronos.org > > webmaster for getting this all setup. > > > > He also got the directory listings prettified > > https://www.khronos.org/registry/webgl/sdk/tests/conformance/ > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Aug 4 15:16:58 2012 From: kbr...@ (Kenneth Russell) Date: Sat, 4 Aug 2012 15:16:58 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1025309454.414188.1343793930645.JavaMail.root@mozilla.com> <5018C2B0.1010500@hicorp.co.jp> Message-ID: Would you be interested in contributing your look-and-feel from codeflow.org? On Sat, Aug 4, 2012 at 12:31 PM, Florian B?sch wrote: > Can we get it to look a bit more snazzy like http://docs.python.org/library/ > or http://webglref.codeflow.org/index.html ? > > On Sat, Aug 4, 2012 at 9:21 PM, Kenneth Russell wrote: >> >> >> Awesome! Gregg, thanks to you and James for getting this set up! >> >> Crowdsourced WebGL reference pages...will be interesting! >> >> -Ken >> >> >> On Fri, Aug 3, 2012 at 5:45 PM, Gregg Tavares (??) >> wrote: >> > Oh, and also a big shout out thank you to James Riordon, the Khronos.org >> > webmaster for getting this all setup. >> > >> > He also got the directory listings prettified >> > https://www.khronos.org/registry/webgl/sdk/tests/conformance/ >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Sat Aug 4 15:24:59 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sun, 5 Aug 2012 00:24:59 +0200 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1025309454.414188.1343793930645.JavaMail.root@mozilla.com> <5018C2B0.1010500@hicorp.co.jp> Message-ID: On Sun, Aug 5, 2012 at 12:16 AM, Kenneth Russell wrote: > Would you be interested in contributing your look-and-feel from > codeflow.org? Sure, though I've got no clue of mediawiki and try to avoid PHP. The "look" is just a bit of twiddling with twitter bootstrap and the bootstrap default skin. There's about 4-5 other skins that'd work and there's also commercial skins. I could just push this into a repo if you'd like? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Sun Aug 5 00:08:07 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Sun, 5 Aug 2012 00:08:07 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <240385438.3399153.1344044594432.JavaMail.root@mozilla.com> References: <240385438.3399153.1344044594432.JavaMail.root@mozilla.com> Message-ID: On Fri, Aug 3, 2012 at 6:43 PM, Benoit Jacob wrote: > > > ------------------------------ > > So apparently the Math extension has been used extensively in the OpenGL > wikis for years. It's now on in the WebGL wiki > > OK, cool! That is definitely good enough to get started, and it will be > easy to switch to MathJax afterwards as it's LaTeX syntax. > > Still, it would be really cool if the MathJax extension could be installed > in the WebGL wiki, so we could try it out. The benefit would be generating > actual text on the client side, as opposed to fixed-size bitmaps on the > server side. > > > > Also the iframe widget is in. I'd like to propose a guideline that iframes > will only be used for context hosted on khronos.org so if you want to put > a sample in, add it to the repo through github first. > > > OK, makes sense. > > > Example of both features is here http://www.khronos.org/webgl/wiki/Test > (ps: Yes, I know that iframe sample is not on khronos.org) > > Very cool! > > Where should we put the WebGL method "man pages"? > I started something here. (http://www.khronos.org/webgl/wiki/Reference) and filled out the first one ( http://www.khronos.org/webgl/wiki/Reference:activeTexture) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Sun Aug 5 11:02:15 2012 From: bja...@ (Benoit Jacob) Date: Sun, 5 Aug 2012 11:02:15 -0700 (PDT) Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: Message-ID: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> ----- Original Message ----- > On Fri, Aug 3, 2012 at 6:43 PM, Benoit Jacob < bjacob...@ > > wrote: > > Where should we put the WebGL method "man pages"? > > I started something here. ( > http://www.khronos.org/webgl/wiki/Reference ) and filled out the > first one ( > http://www.khronos.org/webgl/wiki/Reference:activeTexture ) Is it acceptable to copy text from other Khronos resources, such as: - OpenGL ES man pages - OpenGL ES sprc - WebGL spec ? Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 6 04:30:00 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 6 Aug 2012 13:30:00 +0200 Subject: [Public WebGL] Oculus Rift In-Reply-To: References: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> Message-ID: I've collected some information that will help in targeting this device. Tracking: 6 DOF FOV: 110? diagonal, 90? horizontal Resolution: 1280x800, 640x800 per eye. Single display, split in the middle. Perspective: orthostereoscopic (i.e. convergence in infinity) Projection: Unknown, something fisheye-like Redraw frequency: 60hz, Preferred (but not supported by the dev kit) 120hz Expected latency of input -> display: 30-40ms, preferred would be 20ms Input device: probably some variation of a razor hydra style device (absolute spatial positioning with good accuracy, absolute rotation with a lot of variance +-10?) coupled with gyroscopes to improve rotational response. There was a lot of talk by John Carmack/Palmer Luckey about what differs technically to traditional display technology. And a *major* factor is latency. The magic happens around 20ms delay from input -> display. The large FOV and immersion in the display makes this device very sensitive to display lag. A prime concern in supporting this in WebGL will be how we can get input -> display latency into the desired range. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 6 04:39:16 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 6 Aug 2012 13:39:16 +0200 Subject: [Public WebGL] Oculus Rift In-Reply-To: References: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> Message-ID: Oh and frame tear is a big issue for the device. The display/projection makes the effect of frame tear much more pronounced and vsync should probably be enabled to avoid that. Otherwise turning of the head makes the world "tilt". -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 6 07:17:51 2012 From: cal...@ (Mark Callow) Date: Mon, 06 Aug 2012 07:17:51 -0700 Subject: [Public WebGL] OpenGL ES 3.0 announced Message-ID: <501FD20F.8020505@hicorp.co.jp> OpenGL ES 3.0 has just been announced, along with OpenGL 4.3 and a few other things. Visit www.khronos.org for more details. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Mon Aug 6 15:12:48 2012 From: ash...@ (Ashley Gullen) Date: Mon, 6 Aug 2012 23:12:48 +0100 Subject: [Public WebGL] OpenGL ES 3.0 announced In-Reply-To: <501FD20F.8020505@hicorp.co.jp> References: <501FD20F.8020505@hicorp.co.jp> Message-ID: Are there any plans for a WebGL spec based on the updated OpenGL ES 3.0? Ashley On 6 August 2012 15:17, Mark Callow wrote: > OpenGL ES 3.0 has just been announced, along with OpenGL 4.3 and a few > other things. Visit www.khronos.org for more details. > > Regards > > -Mark > > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 6 15:17:03 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 7 Aug 2012 00:17:03 +0200 Subject: [Public WebGL] OpenGL ES 3.0 announced In-Reply-To: References: <501FD20F.8020505@hicorp.co.jp> Message-ID: On Tue, Aug 7, 2012 at 12:12 AM, Ashley Gullen wrote: > Are there any plans for a WebGL spec based on the updated OpenGL ES 3.0? Also can we start introducing extensions to bridge the expected gap to WebGL 2.0 based on OpenGL ES 3.0 such as multi render targets and draw instanced? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Mon Aug 6 16:45:04 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Mon, 6 Aug 2012 16:45:04 -0700 Subject: [Public WebGL] OpenGL ES 3.0 announced In-Reply-To: References: <501FD20F.8020505@hicorp.co.jp> Message-ID: Here's my 10 minute scan of new features in 3.0 vs 2.0 TransformFeedback (output from vertex shader to buffer) Mapping Buffers to memory Pixel Buffers, Copying Buffers. Uniform Blocks (mapping uniforms to buffers) Vertex Array Objects Occlusion Queries Lots more texture formats (floating point, integer, etc..) Flat Shading 3D textures Textures: NPOT, Min LOD, Max LOD, Compare Mode Samplers (samplers are separate from textures, not sure of the implications since the same settings are available on both) Multiple Render Targets Multi-Sampling Sync/Fence ETC2 texture compression min MAX_TEXTURE_IMAGE_UNITS = 16 (was 8) min MAX_VERTEX_UNIFORM_VECTORS = 256 (was 128) min MAX_FRAGMENT_UNIFORM_VECTORS = 224 (was 16) min MAX_VERTEX_TEXTURE_IMAGE_UNITS = 16 (was 0) min MAX_VARYING_VECTORS = 15 (was 8) min MAX_DRAW_BUFFERS = 4 (was 0) The ETC2 thing is both great and sad. Great that someday ETC2 will be everywhere. Sad that there is no ETC2 on desktop so I'm not sure what's supposed to happen there. Expand to uncompressed? And this gotcha from the ES 3.0 spec: "When using array or matrix variables in a shader, it is possible to access > a variable with an index computed at run time that is outside the declared > extent of the > variable. *Such out-of-bounds accesses have unde?ned behavior, and system > errors (possibly including program termination) may occur.* The level of > protection > provided against such errors in the shader is implementation-dependent" Yea!! :-( On Mon, Aug 6, 2012 at 3:17 PM, Florian B?sch wrote: > On Tue, Aug 7, 2012 at 12:12 AM, Ashley Gullen wrote: > >> Are there any plans for a WebGL spec based on the updated OpenGL ES 3.0? > > Also can we start introducing extensions to bridge the expected gap to > WebGL 2.0 based on OpenGL ES 3.0 such as multi render targets and draw > instanced? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan...@ Mon Aug 6 17:54:12 2012 From: dan...@ (Daniel Koch) Date: Mon, 6 Aug 2012 20:54:12 -0400 Subject: [Public WebGL] OpenGL ES 3.0 announced In-Reply-To: References: <501FD20F.8020505@hicorp.co.jp> Message-ID: <8718DE55-1C77-4D4B-BE2A-958939C3E421@transgaming.com> On 2012-08-06, at 7:45 PM, Gregg Tavares (??) wrote: > Here's my 10 minute scan of new features in 3.0 vs 2.0 > > TransformFeedback (output from vertex shader to buffer) > Mapping Buffers to memory > Pixel Buffers, Copying Buffers. > Uniform Blocks (mapping uniforms to buffers) > Vertex Array Objects > Occlusion Queries > Lots more texture formats (floating point, integer, etc..) > Flat Shading > 3D textures > Textures: NPOT, Min LOD, Max LOD, Compare Mode > Samplers (samplers are separate from textures, not sure of the implications since the same settings are available on both) The sampler parameters take precedence over those from the textures. (This is the same as in Desktop GL.) > Multiple Render Targets > Multi-Sampling > Sync/Fence > ETC2 texture compression > > min MAX_TEXTURE_IMAGE_UNITS = 16 (was 8) > min MAX_VERTEX_UNIFORM_VECTORS = 256 (was 128) > min MAX_FRAGMENT_UNIFORM_VECTORS = 224 (was 16) > min MAX_VERTEX_TEXTURE_IMAGE_UNITS = 16 (was 0) > min MAX_VARYING_VECTORS = 15 (was 8) > min MAX_DRAW_BUFFERS = 4 (was 0) > > The ETC2 thing is both great and sad. Great that someday ETC2 will be everywhere. Sad that there is no ETC2 on desktop so I'm not sure what's supposed to happen there. Expand to uncompressed? But there is -- GL 4.3 (which was also released today BTW!) includes support for ES3 compatibility and brings ETC2/EAC to the desktop (Of course the driver may just be uncompressing them for you though.) > And this gotcha from the ES 3.0 spec: > > "When using array or matrix variables in a shader, it is possible to access a variable with an index computed at run time that is outside the declared extent of the > variable. Such out-of-bounds accesses have unde?ned behavior, and system errors (possibly including program termination) may occur. The level of protection > provided against such errors in the shader is implementation-dependent" > > Yea!! :-( > > > On Mon, Aug 6, 2012 at 3:17 PM, Florian B?sch wrote: > On Tue, Aug 7, 2012 at 12:12 AM, Ashley Gullen wrote: > Are there any plans for a WebGL spec based on the updated OpenGL ES 3.0? > Also can we start introducing extensions to bridge the expected gap to WebGL 2.0 based on OpenGL ES 3.0 such as multi render targets and draw instanced? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Aug 7 10:06:32 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 7 Aug 2012 10:06:32 -0700 Subject: [Public WebGL] OpenGL ES 3.0 announced In-Reply-To: References: <501FD20F.8020505@hicorp.co.jp> Message-ID: First: thanks and congratulations to the OpenGL ES working group for this significant advancement in the graphics capabilities of mobile devices. Second: the plan of the WebGL WG is to advance the specification as soon as possible to add the new functionality in ES 3.0. I am not in favor of adding extensions to the current WebGL implementation to do so, because it is difficult to carve off pieces of functionality and make sure they all interoperate well. Better to incorporate everything at once in a way that continues to allow WebGL to run on ES 2.0 devices. -Ken On Mon, Aug 6, 2012 at 3:17 PM, Florian B?sch wrote: > On Tue, Aug 7, 2012 at 12:12 AM, Ashley Gullen wrote: >> >> Are there any plans for a WebGL spec based on the updated OpenGL ES 3.0? > > Also can we start introducing extensions to bridge the expected gap to WebGL > 2.0 based on OpenGL ES 3.0 such as multi render targets and draw instanced? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Aug 7 14:42:42 2012 From: bja...@ (Benoit Jacob) Date: Tue, 7 Aug 2012 14:42:42 -0700 (PDT) Subject: [Public WebGL] extension proposal: WEBGL_compressed_texture_pvrtc In-Reply-To: <1606618078.6288482.1344375112210.JavaMail.root@mozilla.com> Message-ID: <686515026.6288818.1344375762885.JavaMail.root@mozilla.com> Hi, This is about a new extension proposal, WEBGL_compressed_texture_pvrtc. The pull request is there: https://github.com/KhronosGroup/WebGL/pull/11 I've attached the generated HTML. Unfortunately Github doesn't appear to allow viewing HTML files directly off the repository. The need for mobile compressed texture formats is real. This is the #1 thing we're being asked for my game developers regarding Web games on mobile devices. Also, while I understand that ETC2 is coming, we need something that will help WebGL take off on today's mobile devices. This extension stays close to the corresponding OpenGL ES extension, http://www.khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc.txt In particular, the power-of-two and texSubImage-must-replace-the-whole-image requirements come from there. You might notice that the formulas for butter byte length are looking different: for the 2bpp formats, the OpenGL ES extension has ( max(width, 16) * max(height, 8) * 2 + 7) / 8 whereas the WebGL extension proposal has max(width, 16) * max(height, 8) / 4 The two formulas are in fact equivalent, given that width and height must be powers of two. The latter formula is just a simplification taking advantage of this fact. Please, consider it for promotion to draft status so that implementation can start. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Aug 7 14:51:33 2012 From: bja...@ (Benoit Jacob) Date: Tue, 7 Aug 2012 14:51:33 -0700 (PDT) Subject: [Public WebGL] ATC compressed format undocumented (?) In-Reply-To: <1544572941.6288944.1344376030457.JavaMail.root@mozilla.com> Message-ID: <398665525.6289151.1344376293017.JavaMail.root@mozilla.com> Hi List, I was under the impression that we wanted to add support for ATC mobile compressed texture formats, and that we just needed to find the right formula for the number of bytes. But looking into the OpenGL ES extension spec, the lack of such a formula is only the tip of the iceberg: the format itself is explicitly undocumented and the spec says: http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt Quote: The details of these formats is not disclosed, so refer to AMD's Compressonator tool in order to encode your textures offline: http://ati.amd.com/developer/compressonator.html Is this text still up-to-date? If yes, that sounds like we won't be able to support it in WebGL. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Tue Aug 7 15:10:24 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Tue, 7 Aug 2012 15:10:24 -0700 Subject: [Public WebGL] extension proposal: WEBGL_compressed_texture_pvrtc In-Reply-To: <686515026.6288818.1344375762885.JavaMail.root@mozilla.com> References: <1606618078.6288482.1344375112210.JavaMail.root@mozilla.com> <686515026.6288818.1344375762885.JavaMail.root@mozilla.com> Message-ID: On Tue, Aug 7, 2012 at 2:42 PM, Benoit Jacob wrote: > Hi, > > This is about a new extension proposal, WEBGL_compressed_texture_pvrtc. > > The pull request is there: > https://github.com/KhronosGroup/WebGL/pull/11 > > I've attached the generated HTML. Unfortunately Github doesn't appear to > allow viewing HTML files directly off the repository. > Github requires pushing to a branch named "gh-pages" to serve live content. Currently though it seemed better to serve the live stuff from khronos.org https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_pvrtc/ > > The need for mobile compressed texture formats is real. This is the #1 > thing we're being asked for my game developers regarding Web games on > mobile devices. > > Also, while I understand that ETC2 is coming, we need something that will > help WebGL take off on today's mobile devices. > > This extension stays close to the corresponding OpenGL ES extension, > > http://www.khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc.txt > > In particular, the power-of-two and > texSubImage-must-replace-the-whole-image requirements come from there. > > You might notice that the formulas for butter byte length are looking > different: for the 2bpp formats, the OpenGL ES extension has > > ( max(width, 16) * max(height, 8) * 2 + 7) / 8 > > whereas the WebGL extension proposal has > > max(width, 16) * max(height, 8) / 4 > > The two formulas are in fact equivalent, given that width and height must > be powers of two. The latter formula is just a simplification taking > advantage of this fact. > > Please, consider it for promotion to draft status so that implementation > can start. > Benoit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Aug 7 15:11:27 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Tue, 7 Aug 2012 15:11:27 -0700 Subject: [Public WebGL] ATC compressed format undocumented (?) In-Reply-To: <398665525.6289151.1344376293017.JavaMail.root@mozilla.com> References: <1544572941.6288944.1344376030457.JavaMail.root@mozilla.com> <398665525.6289151.1344376293017.JavaMail.root@mozilla.com> Message-ID: That's my understanding as well. On Tue, Aug 7, 2012 at 2:51 PM, Benoit Jacob wrote: > > Hi List, > > I was under the impression that we wanted to add support for ATC mobile > compressed texture formats, and that we just needed to find the right > formula for the number of bytes. > > But looking into the OpenGL ES extension spec, the lack of such a formula > is only the tip of the iceberg: the format itself is explicitly > undocumented and the spec says: > > > http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt > > Quote: > The details of these formats is not disclosed, so refer to AMD's > Compressonator tool in order to encode your textures offline: > http://ati.amd.com/developer/compressonator.html > > Is this text still up-to-date? If yes, that sounds like we won't be able > to support it in WebGL. > > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Aug 7 18:20:59 2012 From: bja...@ (Benoit Jacob) Date: Tue, 7 Aug 2012 18:20:59 -0700 (PDT) Subject: [Public WebGL] extension proposal: WEBGL_compressed_texture_pvrtc In-Reply-To: Message-ID: <1505488838.50236.1344388859611.JavaMail.root@mozilla.com> ----- Original Message ----- > On Tue, Aug 7, 2012 at 2:42 PM, Benoit Jacob < bjacob...@ > > wrote: > > Hi, > > > This is about a new extension proposal, > > WEBGL_compressed_texture_pvrtc. > > > The pull request is there: > > > https://github.com/KhronosGroup/WebGL/pull/11 > > > I've attached the generated HTML. Unfortunately Github doesn't > > appear > > to allow viewing HTML files directly off the repository. > > Github requires pushing to a branch named "gh-pages" to serve live > content. Currently though it seemed better to serve the live stuff > from khronos.org > https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_pvrtc/ Great! Out of curiosity, could you explain how this works? Are all commits in KhronosGroup/WebGL automatically reflected on this site? Thanks for merging the pull request, as well. Now please discuss promotion to draft status! Benoit > > The need for mobile compressed texture formats is real. This is the > > #1 thing we're being asked for my game developers regarding Web > > games on mobile devices. > > > Also, while I understand that ETC2 is coming, we need something > > that > > will help WebGL take off on today's mobile devices. > > > This extension stays close to the corresponding OpenGL ES > > extension, > > > http://www.khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc.txt > > > In particular, the power-of-two and > > texSubImage-must-replace-the-whole-image requirements come from > > there. > > > You might notice that the formulas for butter byte length are > > looking > > different: for the 2bpp formats, the OpenGL ES extension has > > > ( max(width, 16) * max(height, 8) * 2 + 7) / 8 > > > whereas the WebGL extension proposal has > > > max(width, 16) * max(height, 8) / 4 > > > The two formulas are in fact equivalent, given that width and > > height > > must be powers of two. The latter formula is just a simplification > > taking advantage of this fact. > > > Please, consider it for promotion to draft status so that > > implementation can start. > > > Benoit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Aug 7 18:25:00 2012 From: bja...@ (Benoit Jacob) Date: Tue, 7 Aug 2012 18:25:00 -0700 (PDT) Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> Message-ID: <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> ----- Original Message ----- > ----- Original Message ----- > > On Fri, Aug 3, 2012 at 6:43 PM, Benoit Jacob < bjacob...@ > > > wrote: > > > > Where should we put the WebGL method "man pages"? > > > > > I started something here. ( > > http://www.khronos.org/webgl/wiki/Reference ) and filled out the > > first one ( > > http://www.khronos.org/webgl/wiki/Reference:activeTexture ) > > Is it acceptable to copy text from other Khronos resources, such as: > - OpenGL ES man pages > - OpenGL ES sprc > - WebGL spec > ? Ping about that question: I just need an answer here and then I really want to start writing a few pages. Also, I was thinking: we could have certain concepts discussed in greated detail in separate pages, that these method-specific pages could link to. Example: we could have a wiki page on WebGL texture completeness rules, and link to it from the texImage2D, texSubImage2D and other texture-image-upload-method pages. Benoit > Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Aug 7 18:44:27 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Tue, 7 Aug 2012 18:44:27 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> References: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> Message-ID: On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob wrote: > > > ------------------------------ > > > > ------------------------------ > > > > > On Fri, Aug 3, 2012 at 6:43 PM, Benoit Jacob wrote: > >> >> Where should we put the WebGL method "man pages"? >> > > I started something here. (http://www.khronos.org/webgl/wiki/Reference) > and filled out the first one ( > http://www.khronos.org/webgl/wiki/Reference:activeTexture) > > Is it acceptable to copy text from other Khronos resources, such as: > - OpenGL ES man pages > - OpenGL ES sprc > - WebGL spec > > I don't know if it is acceptable copy from the OpenGL ES spec or man pages. Honestly those pages often seem derived from OpenGL 1.0 and it would be nice, where appropriate, to just write new docs. > > ? > > Ping about that question: I just need an answer here and then I really > want to start writing a few pages. > > Also, I was thinking: we could have certain concepts discussed in greated > detail in separate pages, that these method-specific pages could link to. > > Example: we could have a wiki page on WebGL texture completeness rules, > and link to it from the texImage2D, texSubImage2D and other > texture-image-upload-method pages. > I agree that would be great. I would be nice not to repeat ourselves where possible. I did one 'detail' on that first page. activeTexture has a link to TextureState (http://www.khronos.org/webgl/wiki/TextureState) > > Benoit > > > > Benoit > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Aug 7 18:46:35 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Tue, 7 Aug 2012 18:46:35 -0700 Subject: [Public WebGL] extension proposal: WEBGL_compressed_texture_pvrtc In-Reply-To: <1505488838.50236.1344388859611.JavaMail.root@mozilla.com> References: <1505488838.50236.1344388859611.JavaMail.root@mozilla.com> Message-ID: On Tue, Aug 7, 2012 at 6:20 PM, Benoit Jacob wrote: > > > ------------------------------ > > > > > On Tue, Aug 7, 2012 at 2:42 PM, Benoit Jacob wrote: > >> Hi, >> >> This is about a new extension proposal, WEBGL_compressed_texture_pvrtc. >> >> The pull request is there: >> https://github.com/KhronosGroup/WebGL/pull/11 >> >> I've attached the generated HTML. Unfortunately Github doesn't appear to >> allow viewing HTML files directly off the repository. >> > > Github requires pushing to a branch named "gh-pages" to serve live > content. Currently though it seemed better to serve the live stuff from > khronos.org > > > https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_pvrtc/ > > Great! Out of curiosity, could you explain how this works? Are all commits > in KhronosGroup/WebGL automatically reflected on this site? > The Khronos server does a 'git pull' every 10 or 15 mins. A slicker solution would be to install a post-commit script on github that pinged the khronos server ('hey, go a git pull') It's on the TODO list :-p > > Thanks for merging the pull request, as well. > > Now please discuss promotion to draft status! > > Benoit > > > > >> >> The need for mobile compressed texture formats is real. This is the #1 >> thing we're being asked for my game developers regarding Web games on >> mobile devices. >> >> Also, while I understand that ETC2 is coming, we need something that will >> help WebGL take off on today's mobile devices. >> >> This extension stays close to the corresponding OpenGL ES extension, >> >> http://www.khronos.org/registry/gles/extensions/IMG/IMG_texture_compression_pvrtc.txt >> >> In particular, the power-of-two and >> texSubImage-must-replace-the-whole-image requirements come from there. >> >> You might notice that the formulas for butter byte length are looking >> different: for the 2bpp formats, the OpenGL ES extension has >> >> ( max(width, 16) * max(height, 8) * 2 + 7) / 8 >> >> whereas the WebGL extension proposal has >> >> max(width, 16) * max(height, 8) / 4 >> >> The two formulas are in fact equivalent, given that width and height must >> be powers of two. The latter formula is just a simplification taking >> advantage of this fact. >> >> Please, consider it for promotion to draft status so that implementation >> can start. >> Benoit >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik...@ Tue Aug 7 23:21:55 2012 From: mik...@ (Mikko Mononen) Date: Wed, 8 Aug 2012 09:21:55 +0300 Subject: [Public WebGL] ATC compressed format undocumented (?) In-Reply-To: References: <1544572941.6288944.1344376030457.JavaMail.root@mozilla.com> <398665525.6289151.1344376293017.JavaMail.root@mozilla.com> Message-ID: Hi, Do you actually mean ASTC, the new fancy texture compression? They have put up some sources yesterday: http://www.malideveloper.com/developer-resources/tools/astc-compressor.php --mikko On Wed, Aug 8, 2012 at 1:11 AM, Gregg Tavares (??) wrote: > That's my understanding as well. > > > On Tue, Aug 7, 2012 at 2:51 PM, Benoit Jacob wrote: >> >> >> Hi List, >> >> I was under the impression that we wanted to add support for ATC mobile >> compressed texture formats, and that we just needed to find the right >> formula for the number of bytes. >> >> But looking into the OpenGL ES extension spec, the lack of such a formula >> is only the tip of the iceberg: the format itself is explicitly undocumented >> and the spec says: >> >> >> http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt >> >> Quote: >> The details of these formats is not disclosed, so refer to AMD's >> Compressonator tool in order to encode your textures offline: >> http://ati.amd.com/developer/compressonator.html >> >> Is this text still up-to-date? If yes, that sounds like we won't be able >> to support it in WebGL. >> >> Benoit >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > -- Mikko Mononen, Co-founder & Principal Engineer http://tinkercad.com ? Give form to your dreams ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From geo...@ Tue Aug 7 23:54:27 2012 From: geo...@ (George Neil) Date: Wed, 8 Aug 2012 12:24:27 +0530 Subject: [Public WebGL] Does WebGL support Blend Equation Extensions ? Message-ID: Does WebGL support Blend Equation Extensions ? I would like to use the WebGL equivalent the openGL command, glBlendEquationEXT(GL_MAX_EXT) Is there any workaround. I would like to have a solution for my problem in the following link. http://stackoverflow.com/questions/11839993/how-to-do-maximum-intensity-projection-mip-in-webgl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jef...@ Wed Aug 8 08:09:29 2012 From: jef...@ (Jeff Russell) Date: Wed, 8 Aug 2012 09:09:29 -0600 Subject: [Public WebGL] MAX_VERTEX_UNIFORM_VECTORS Message-ID: What is the minimum value of GL_ MAX_VERTEX_UNIFORM_VECTORS in webgl? Is it as low as 128 as per the GLES 2.0 spec? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan...@ Wed Aug 8 11:44:21 2012 From: dan...@ (Daniel Koch) Date: Wed, 8 Aug 2012 14:44:21 -0400 Subject: [Public WebGL] ATC compressed format undocumented (?) In-Reply-To: References: <1544572941.6288944.1344376030457.JavaMail.root@mozilla.com> <398665525.6289151.1344376293017.JavaMail.root@mozilla.com> Message-ID: <1D6EDB64-A651-42AE-809F-C835C109084A@transgaming.com> No, that is completely different format. Daniel On 2012-08-08, at 2:21 AM, Mikko Mononen wrote: > > Hi, > > Do you actually mean ASTC, the new fancy texture compression? They > have put up some sources yesterday: > http://www.malideveloper.com/developer-resources/tools/astc-compressor.php > > > --mikko > > > On Wed, Aug 8, 2012 at 1:11 AM, Gregg Tavares (??) wrote: >> That's my understanding as well. >> >> >> On Tue, Aug 7, 2012 at 2:51 PM, Benoit Jacob wrote: >>> >>> >>> Hi List, >>> >>> I was under the impression that we wanted to add support for ATC mobile >>> compressed texture formats, and that we just needed to find the right >>> formula for the number of bytes. >>> >>> But looking into the OpenGL ES extension spec, the lack of such a formula >>> is only the tip of the iceberg: the format itself is explicitly undocumented >>> and the spec says: >>> >>> >>> http://www.khronos.org/registry/gles/extensions/AMD/AMD_compressed_ATC_texture.txt >>> >>> Quote: >>> The details of these formats is not disclosed, so refer to AMD's >>> Compressonator tool in order to encode your textures offline: >>> http://ati.amd.com/developer/compressonator.html >>> >>> Is this text still up-to-date? If yes, that sounds like we won't be able >>> to support it in WebGL. >>> >>> Benoit >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >> > > > > -- > Mikko Mononen, Co-founder & Principal Engineer > http://tinkercad.com ? Give form to your dreams > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Wed Aug 8 18:21:25 2012 From: bja...@ (Benoit Jacob) Date: Wed, 8 Aug 2012 18:21:25 -0700 (PDT) Subject: [Public WebGL] MAX_VERTEX_UNIFORM_VECTORS In-Reply-To: Message-ID: <1355103455.328580.1344475285673.JavaMail.root@mozilla.com> Yes: nothing specific is said about that in the WebGL spec, so by default it uses the OpenGL ES 2.0 spec's minimum value. Benoit ----- Original Message ----- > What is the minimum value of GL_ MAX_VERTEX_UNIFORM_VECTORS in webgl? > Is it as low as 128 as per the GLES 2.0 spec? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Aug 8 22:01:46 2012 From: jgi...@ (Jeff Gilbert) Date: Wed, 8 Aug 2012 22:01:46 -0700 (PDT) Subject: [Public WebGL] Does WebGL support Blend Equation Extensions ? In-Reply-To: Message-ID: <1126354159.1752829.1344488506715.JavaMail.root@mozilla.com> This behavior is core in GL 2.0+ and GLES 3, but is not in GLES 2 core. GLES 2 can expose this functionality with EXT_blend_minmax, though. We could potentially expose this, especially if EXT_blend_minmax support happens to be prevalent. If you aren't doing anything with the depth buffer, you can possibly use that to store your intensity, and rely on depth testing to get you what you want. I'm trying to think of why this might not work, but it seems like it should. If you need depth test to prevent sprites from appearing behind walls or something, though, it's more complicated. With the depth_texture extension, you should be able to render your main scene first, then in a new rendering pass for the sprites, discard fragments which are behind the depth you sample from the depth texture (which you rendered your previous scene to). -Jeff ----- Original Message ----- From: "George Neil" To: "public webgl" Sent: Tuesday, August 7, 2012 11:54:27 PM Subject: [Public WebGL] Does WebGL support Blend Equation Extensions ? Does WebGL support Blend Equation Extensions ? I would like to use the WebGL equivalent the openGL command, glBlendEquationEXT(GL_MAX_EXT) Is there any workaround. I would like to have a solution for my problem in the following link. http://stackoverflow.com/questions/11839993/how-to-do-maximum-intensity-projection-mip-in-webgl ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From geo...@ Thu Aug 9 01:45:47 2012 From: geo...@ (George Neil) Date: Thu, 9 Aug 2012 14:15:47 +0530 Subject: [Public WebGL] Does WebGL support Blend Equation Extensions ? In-Reply-To: <1126354159.1752829.1344488506715.JavaMail.root@mozilla.com> References: <1126354159.1752829.1344488506715.JavaMail.root@mozilla.com> Message-ID: It would be great if we could add EXT_blend_minmax support in GLES 2. Can you please provide sample code or update the jsfiddle to solve this issue using the depth buffer in the following link. http://stackoverflow.com/questions/11839993/how-to-do-maximum-intensity-projection-mip-in-webgl Thanks, -George Neil On Thu, Aug 9, 2012 at 10:31 AM, Jeff Gilbert wrote: > This behavior is core in GL 2.0+ and GLES 3, but is not in GLES 2 core. > GLES 2 can expose this functionality with EXT_blend_minmax, though. We > could potentially expose this, especially if EXT_blend_minmax support > happens to be prevalent. > > If you aren't doing anything with the depth buffer, you can possibly use > that to store your intensity, and rely on depth testing to get you what you > want. I'm trying to think of why this might not work, but it seems like it > should. > > If you need depth test to prevent sprites from appearing behind walls or > something, though, it's more complicated. With the depth_texture extension, > you should be able to render your main scene first, then in a new rendering > pass for the sprites, discard fragments which are behind the depth you > sample from the depth texture (which you rendered your previous scene to). > > -Jeff > > ----- Original Message ----- > From: "George Neil" > To: "public webgl" > Sent: Tuesday, August 7, 2012 11:54:27 PM > Subject: [Public WebGL] Does WebGL support Blend Equation Extensions ? > > > Does WebGL support Blend Equation Extensions ? > > > > I would like to use the WebGL equivalent the openGL command, > glBlendEquationEXT(GL_MAX_EXT) > > > Is there any workaround. I would like to have a solution for my problem in > the following link. > > > > http://stackoverflow.com/questions/11839993/how-to-do-maximum-intensity-projection-mip-in-webgl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Aug 11 03:43:10 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 11 Aug 2012 12:43:10 +0200 Subject: [Public WebGL] Oculus Rift In-Reply-To: References: <121276323.3327500.1344021698544.JavaMail.root@mozilla.com> Message-ID: Palmer Luckey has indicated interest to get zero day support in browsers and it looks like he's willing to get an early delivery into the hands of somebody capable of providing the plugin. I think there's a couple areas to work on to make this happen: - The correct 3D rendering: I'm currently working on some stub code/examples to show how that works in WebGL. - A plugin able to support the input. Regarding the plugin, would napi or ppapi a better choice? Anybody versed in writing plugins feel like setting up an input plugin stub? One area of possible improvement is GUI rendering with HTML that would need to be duplicated for each eye. Any idea how we can make that easier than building the markup two times? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 13 10:59:41 2012 From: cal...@ (Mark Callow) Date: Mon, 13 Aug 2012 10:59:41 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> Message-ID: <5029408D.1050509@hicorp.co.jp> On 12/08/07 18:44, Gregg Tavares (??) wrote: > > On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob > wrote: > > > Is it acceptable to copy text from other Khronos resources, such as: > > - OpenGL ES man pages > - OpenGL ES sprc > - WebGL spec > > > I don't know if it is acceptable copy from the OpenGL ES spec or man > pages. Honestly those pages often seem derived from OpenGL 1.0 and it > would be nice, where appropriate, to just write new docs. > I don't know about the legal position either but I worry about duplication of effort and divergence between the OpenGL ES and WebGL man pages. The vast majority of the information is the same for both. It would be nice to have at least the source in one place with page sections noting differences in WebGL where necessary. I also worry that using a Wiki for the reference pages creates an enormous amount of manual effort that could otherwise be automated such as making live references from one page to another. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Mon Aug 13 11:19:33 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Mon, 13 Aug 2012 11:19:33 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <5029408D.1050509@hicorp.co.jp> References: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> <5029408D.1050509@hicorp.co.jp> Message-ID: On Mon, Aug 13, 2012 at 10:59 AM, Mark Callow wrote: > On 12/08/07 18:44, Gregg Tavares (??) wrote: > > > On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob wrote: > >> >> Is it acceptable to copy text from other Khronos resources, such as: >> >> - OpenGL ES man pages >> - OpenGL ES sprc >> - WebGL spec >> >> > I don't know if it is acceptable copy from the OpenGL ES spec or man > pages. Honestly those pages often seem derived from OpenGL 1.0 and it would > be nice, where appropriate, to just write new docs. > > I don't know about the legal position either but I worry about > duplication of effort and divergence between the OpenGL ES and WebGL man > pages. The vast majority of the information is the same for both. It would > be nice to have at least the source in one place with page sections noting > differences in WebGL where necessary. > > I also worry that using a Wiki for the reference pages creates an enormous > amount of manual effort that could otherwise be automated such as making > live references from one page to another. > I totally agree with you. As an engineer I want shared docs, automated code snippets, docs generated from IDLs. etc, etc etc. But as a counter example, look how long the GL pages have had bad info. I filed bugs. They still aren't fixed. If they were a wiki I'd have fixed them myself. As something checked in somewhere I have no idea where they are or how to get access to their repo or if I'm even allowed to access that repo. I'm lucky I even had an idea where to file bugs. On a Wiki I just click [EDIT] and fix it. > > Regards > > -Mark > > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Aug 13 11:25:39 2012 From: bja...@ (Benoit Jacob) Date: Mon, 13 Aug 2012 11:25:39 -0700 (PDT) Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <5029408D.1050509@hicorp.co.jp> Message-ID: <312761189.1551055.1344882339881.JavaMail.root@mozilla.com> ----- Original Message ----- > On 12/08/07 18:44, Gregg Tavares (??) wrote: > > On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob < bjacob...@ > > > wrote: > > > > Is it acceptable to copy text from other Khronos resources, such > > > as: > > > > > > > - OpenGL ES man pages > > > > > > > > > > - OpenGL ES sprc > > > > > > > > > > - WebGL spec > > > > > > > > I don't know if it is acceptable copy from the OpenGL ES spec or > > man > > pages. Honestly those pages often seem derived from OpenGL 1.0 and > > it would be nice, where appropriate, to just write new docs. > > I don't know about the legal position either but I worry about > duplication of effort and divergence between the OpenGL ES and WebGL > man pages. The vast majority of the information is the same for > both. It would be nice to have at least the source in one place with > page sections noting differences in WebGL where necessary. I was worrying about duplication of effort too, but I can see the bright side of Gregg's proposed approach: it's a good occasion to start fresh and aim for (even) better results than the OpenGL ES man pages achieved. > I also worry that using a Wiki for the reference pages creates an > enormous amount of manual effort that could otherwise be automated > such as making live references from one page to another. Wikis offer tools for this, too. Mediawiki's "Categories" come to mind, but I don't have much experience with that. If one were to revert from using a wiki for this kind of reason, one would first have to think about what format to choose. For good handling of cross-references in large documents, LaTeX comes to mind. But if you ask me, the main problem we have to solve today is that man pages haven't been written yet, and this problem is more likely to be solved with the wiki lowering the barrier to entry, than with a more advanced but more technical document authoring system like LaTeX. Benoit > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > NOTE: This electronic mail message may contain confidential and > privileged information from HI Corporation. If you are not the > intended recipient, any disclosure, photocopying, distribution or > use of the contents of the received information is prohibited. If > you have received this e-mail in error, please notify the sender > immediately and permanently delete this message and all related > copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bag...@ Mon Aug 13 11:30:00 2012 From: bag...@ (Patrick Baggett) Date: Mon, 13 Aug 2012 13:30:00 -0500 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> <5029408D.1050509@hicorp.co.jp> Message-ID: Seconded about wiki vs bug filing. I've reported > 10 bugs to opengl.orgreference pages, of which most have been fixed in time, but it hasn't been a process that I would recommend to new sites. After double digit reports, I asked if I could have access to the repository to just fix them myself (i.e. I attempted to show good faith efforts in using the system available but offered to reduce the workload for them), but as a result of some politics, I would need to pay 10K / year for the privilege of fixing the reference pages, assuming my membership to Khronos was approved. Being able to "just do it" would have saved a lot of effort and a few of my friends who referred to the pages would have made a lot fewer mistakes! Patrick But as a counter example, look how long the GL pages have had bad info. I > filed bugs. They still aren't fixed. If they were a wiki I'd have fixed > them myself. As something checked in somewhere I have no idea where they > are or how to get access to their repo or if I'm even allowed to access > that repo. I'm lucky I even had an idea where to file bugs. On a Wiki I > just click [EDIT] and fix it. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Aug 13 15:35:19 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 13 Aug 2012 15:35:19 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> <5029408D.1050509@hicorp.co.jp> Message-ID: On Mon, Aug 13, 2012 at 11:19 AM, Gregg Tavares (??) wrote: > > > > On Mon, Aug 13, 2012 at 10:59 AM, Mark Callow > wrote: >> >> On 12/08/07 18:44, Gregg Tavares (??) wrote: >> >> >> On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob wrote: >>> >>> >>> Is it acceptable to copy text from other Khronos resources, such as: >>> >>> - OpenGL ES man pages >>> - OpenGL ES sprc >>> - WebGL spec >> >> >> I don't know if it is acceptable copy from the OpenGL ES spec or man >> pages. Honestly those pages often seem derived from OpenGL 1.0 and it would >> be nice, where appropriate, to just write new docs. >> >> I don't know about the legal position either but I worry about duplication >> of effort and divergence between the OpenGL ES and WebGL man pages. The vast >> majority of the information is the same for both. It would be nice to have >> at least the source in one place with page sections noting differences in >> WebGL where necessary. >> >> I also worry that using a Wiki for the reference pages creates an enormous >> amount of manual effort that could otherwise be automated such as making >> live references from one page to another. > > > I totally agree with you. As an engineer I want shared docs, automated code > snippets, docs generated from IDLs. etc, etc etc. > > But as a counter example, look how long the GL pages have had bad info. I > filed bugs. They still aren't fixed. If they were a wiki I'd have fixed them > myself. As something checked in somewhere I have no idea where they are or > how to get access to their repo or if I'm even allowed to access that repo. > I'm lucky I even had an idea where to file bugs. On a Wiki I just click > [EDIT] and fix it. The transition of the WebGL repo to Github should make incorporation of changes like this much easier and mostly automated. Would it be feasible to check in the sources to the reference pages, and postprocess them to generate wiki pages or HTML? I know there's already been discussion about the lower barrier to entry with a wiki, but the lack of automated tools for management seems really problematic in the long run. -Ken >> >> >> Regards >> >> -Mark >> >> >> -- >> ???????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????? ??? >> >> NOTE: This electronic mail message may contain confidential and privileged >> information from HI Corporation. If you are not the intended recipient, any >> disclosure, photocopying, distribution or use of the contents of the >> received information is prohibited. If you have received this e-mail in >> error, please notify the sender immediately and permanently delete this >> message and all related copies. > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Mon Aug 13 15:55:03 2012 From: bja...@ (Benoit Jacob) Date: Mon, 13 Aug 2012 15:55:03 -0700 (PDT) Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: Message-ID: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> ----- Original Message ----- > > On Mon, Aug 13, 2012 at 11:19 AM, Gregg Tavares (??) > wrote: > > > > > > > > On Mon, Aug 13, 2012 at 10:59 AM, Mark Callow > > > > wrote: > >> > >> On 12/08/07 18:44, Gregg Tavares (??) wrote: > >> > >> > >> On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob > >> wrote: > >>> > >>> > >>> Is it acceptable to copy text from other Khronos resources, such > >>> as: > >>> > >>> - OpenGL ES man pages > >>> - OpenGL ES sprc > >>> - WebGL spec > >> > >> > >> I don't know if it is acceptable copy from the OpenGL ES spec or > >> man > >> pages. Honestly those pages often seem derived from OpenGL 1.0 and > >> it would > >> be nice, where appropriate, to just write new docs. > >> > >> I don't know about the legal position either but I worry about > >> duplication > >> of effort and divergence between the OpenGL ES and WebGL man > >> pages. The vast > >> majority of the information is the same for both. It would be nice > >> to have > >> at least the source in one place with page sections noting > >> differences in > >> WebGL where necessary. > >> > >> I also worry that using a Wiki for the reference pages creates an > >> enormous > >> amount of manual effort that could otherwise be automated such as > >> making > >> live references from one page to another. > > > > > > I totally agree with you. As an engineer I want shared docs, > > automated code > > snippets, docs generated from IDLs. etc, etc etc. > > > > But as a counter example, look how long the GL pages have had bad > > info. I > > filed bugs. They still aren't fixed. If they were a wiki I'd have > > fixed them > > myself. As something checked in somewhere I have no idea where they > > are or > > how to get access to their repo or if I'm even allowed to access > > that repo. > > I'm lucky I even had an idea where to file bugs. On a Wiki I just > > click > > [EDIT] and fix it. > > The transition of the WebGL repo to Github should make incorporation > of changes like this much easier and mostly automated. Would it be > feasible to check in the sources to the reference pages, and > postprocess them to generate wiki pages or HTML? I know there's > already been discussion about the lower barrier to entry with a wiki, > but the lack of automated tools for management seems really > problematic in the long run. Again, I am not convinced that mediawiki really lacks such tools; one would need to be more specific here, to make progress. What's missing? If it's just "see also" lists, mediawiki does offer tools for that. Benoit > > -Ken > > > >> > >> > >> Regards > >> > >> -Mark > >> > >> > >> -- > >> ???????????????????????????????????????????????????????????????? > >> ???????????????????????????????????????????????????????????????? > >> ??? > >> > >> NOTE: This electronic mail message may contain confidential and > >> privileged > >> information from HI Corporation. If you are not the intended > >> recipient, any > >> disclosure, photocopying, distribution or use of the contents of > >> the > >> received information is prohibited. If you have received this > >> e-mail in > >> error, please notify the sender immediately and permanently delete > >> this > >> message and all related copies. > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kos...@ Mon Aug 13 15:54:51 2012 From: kos...@ (David Sheets) Date: Mon, 13 Aug 2012 15:54:51 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <1492728066.5823200.1344189735962.JavaMail.root@mozilla.com> <1781623615.50543.1344389100751.JavaMail.root@mozilla.com> <5029408D.1050509@hicorp.co.jp> Message-ID: On Mon, Aug 13, 2012 at 3:35 PM, Kenneth Russell wrote: > > On Mon, Aug 13, 2012 at 11:19 AM, Gregg Tavares (??) wrote: >> >> >> >> On Mon, Aug 13, 2012 at 10:59 AM, Mark Callow >> wrote: >>> >>> On 12/08/07 18:44, Gregg Tavares (??) wrote: >>> >>> >>> On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob wrote: >>>> >>>> >>>> Is it acceptable to copy text from other Khronos resources, such as: >>>> >>>> - OpenGL ES man pages >>>> - OpenGL ES sprc >>>> - WebGL spec >>> >>> >>> I don't know if it is acceptable copy from the OpenGL ES spec or man >>> pages. Honestly those pages often seem derived from OpenGL 1.0 and it would >>> be nice, where appropriate, to just write new docs. >>> >>> I don't know about the legal position either but I worry about duplication >>> of effort and divergence between the OpenGL ES and WebGL man pages. The vast >>> majority of the information is the same for both. It would be nice to have >>> at least the source in one place with page sections noting differences in >>> WebGL where necessary. >>> >>> I also worry that using a Wiki for the reference pages creates an enormous >>> amount of manual effort that could otherwise be automated such as making >>> live references from one page to another. >> >> >> I totally agree with you. As an engineer I want shared docs, automated code >> snippets, docs generated from IDLs. etc, etc etc. >> >> But as a counter example, look how long the GL pages have had bad info. I >> filed bugs. They still aren't fixed. If they were a wiki I'd have fixed them >> myself. As something checked in somewhere I have no idea where they are or >> how to get access to their repo or if I'm even allowed to access that repo. >> I'm lucky I even had an idea where to file bugs. On a Wiki I just click >> [EDIT] and fix it. > > The transition of the WebGL repo to Github should make incorporation > of changes like this much easier and mostly automated. Would it be > feasible to check in the sources to the reference pages, and > postprocess them to generate wiki pages or HTML? I know there's > already been discussion about the lower barrier to entry with a wiki, > but the lack of automated tools for management seems really > problematic in the long run. Does the khronos.org mediawiki install support bots? In what languages? Would Khronos be willing to run open source bots on our wiki in collaboration with the community? How difficult is automated exportation of wiki article source? David > -Ken > > >>> >>> >>> Regards >>> >>> -Mark >>> >>> >>> -- >>> ???????????????????????????????????????????????????????????????? >>> ???????????????????????????????????????????????????????????????? ??? >>> >>> NOTE: This electronic mail message may contain confidential and privileged >>> information from HI Corporation. If you are not the intended recipient, any >>> disclosure, photocopying, distribution or use of the contents of the >>> received information is prohibited. If you have received this e-mail in >>> error, please notify the sender immediately and permanently delete this >>> message and all related copies. >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Aug 13 16:21:03 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 13 Aug 2012 16:21:03 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> References: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> Message-ID: On Mon, Aug 13, 2012 at 3:55 PM, Benoit Jacob wrote: > > > ----- Original Message ----- >> >> On Mon, Aug 13, 2012 at 11:19 AM, Gregg Tavares (??) >> wrote: >> > >> > >> > >> > On Mon, Aug 13, 2012 at 10:59 AM, Mark Callow >> > >> > wrote: >> >> >> >> On 12/08/07 18:44, Gregg Tavares (??) wrote: >> >> >> >> >> >> On Tue, Aug 7, 2012 at 6:25 PM, Benoit Jacob >> >> wrote: >> >>> >> >>> >> >>> Is it acceptable to copy text from other Khronos resources, such >> >>> as: >> >>> >> >>> - OpenGL ES man pages >> >>> - OpenGL ES sprc >> >>> - WebGL spec >> >> >> >> >> >> I don't know if it is acceptable copy from the OpenGL ES spec or >> >> man >> >> pages. Honestly those pages often seem derived from OpenGL 1.0 and >> >> it would >> >> be nice, where appropriate, to just write new docs. >> >> >> >> I don't know about the legal position either but I worry about >> >> duplication >> >> of effort and divergence between the OpenGL ES and WebGL man >> >> pages. The vast >> >> majority of the information is the same for both. It would be nice >> >> to have >> >> at least the source in one place with page sections noting >> >> differences in >> >> WebGL where necessary. >> >> >> >> I also worry that using a Wiki for the reference pages creates an >> >> enormous >> >> amount of manual effort that could otherwise be automated such as >> >> making >> >> live references from one page to another. >> > >> > >> > I totally agree with you. As an engineer I want shared docs, >> > automated code >> > snippets, docs generated from IDLs. etc, etc etc. >> > >> > But as a counter example, look how long the GL pages have had bad >> > info. I >> > filed bugs. They still aren't fixed. If they were a wiki I'd have >> > fixed them >> > myself. As something checked in somewhere I have no idea where they >> > are or >> > how to get access to their repo or if I'm even allowed to access >> > that repo. >> > I'm lucky I even had an idea where to file bugs. On a Wiki I just >> > click >> > [EDIT] and fix it. >> >> The transition of the WebGL repo to Github should make incorporation >> of changes like this much easier and mostly automated. Would it be >> feasible to check in the sources to the reference pages, and >> postprocess them to generate wiki pages or HTML? I know there's >> already been discussion about the lower barrier to entry with a wiki, >> but the lack of automated tools for management seems really >> problematic in the long run. > > Again, I am not convinced that mediawiki really lacks such tools; one would need to be more specific here, to make progress. What's missing? If it's just "see also" lists, mediawiki does offer tools for that. I apologize but I don't have concrete examples of missing functionality. I can only say definitively from my experience that doing markup on wiki pages by hand is tedious. David Sheets' work to autogenerate the WebGL extension registry from XML files is a great example of a massive productivity improvement. I can't imagine maintaining the registry by hand any more. Similar productivity increases could surely be achieved for the creation and maintenance of WebGL reference pages by using some sort of template system rather than writing wiki pages for each API call by hand. -Ken > Benoit > > >> >> -Ken >> >> >> >> >> >> >> >> Regards >> >> >> >> -Mark >> >> >> >> >> >> -- >> >> ???????????????????????????????????????????????????????????????? >> >> ???????????????????????????????????????????????????????????????? >> >> ??? >> >> >> >> NOTE: This electronic mail message may contain confidential and >> >> privileged >> >> information from HI Corporation. If you are not the intended >> >> recipient, any >> >> disclosure, photocopying, distribution or use of the contents of >> >> the >> >> received information is prohibited. If you have received this >> >> e-mail in >> >> error, please notify the sender immediately and permanently delete >> >> this >> >> message and all related copies. >> > >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Mon Aug 13 19:15:18 2012 From: bja...@ (Benoit Jacob) Date: Mon, 13 Aug 2012 19:15:18 -0700 (PDT) Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: Message-ID: <474256934.1654200.1344910518821.JavaMail.root@mozilla.com> > I apologize but I don't have concrete examples of missing > functionality. I can only say definitively from my experience that > doing markup on wiki pages by hand is tedious. David Sheets' work to > autogenerate the WebGL extension registry from XML files is a great > example of a massive productivity improvement. I can't imagine > maintaining the registry by hand any more. Similar productivity > increases could surely be achieved for the creation and maintenance > of > WebGL reference pages by using some sort of template system rather > than writing wiki pages for each API call by hand. Oh, I see the concern now. I don't know. On the one hand, we have markup language that make it easy to write documents. On the other hand we have XML which gives automation but is a pain to write by hand. The only document writing system that combines convenient markup with good large-document-structuration-and-automation features, that I know of, is LaTeX. From the looks of the OpenGL [ES] PDF spec, it seems that it's made in LaTeX, for example (maybe someone can confirm). But compared to a wiki, this will increase the barrier to entry quite a bit. Benoit > > -Ken > > > > Benoit > > > > > >> > >> -Ken > >> > >> > >> >> > >> >> > >> >> Regards > >> >> > >> >> -Mark > >> >> > >> >> > >> >> -- > >> >> ???????????????????????????????????????????????????????????????? > >> >> ???????????????????????????????????????????????????????????????? > >> >> ??? > >> >> > >> >> NOTE: This electronic mail message may contain confidential and > >> >> privileged > >> >> information from HI Corporation. If you are not the intended > >> >> recipient, any > >> >> disclosure, photocopying, distribution or use of the contents > >> >> of > >> >> the > >> >> received information is prohibited. If you have received this > >> >> e-mail in > >> >> error, please notify the sender immediately and permanently > >> >> delete > >> >> this > >> >> message and all related copies. > >> > > >> > > >> > >> ----------------------------------------------------------- > >> You are currently subscribed to public_webgl...@ > >> To unsubscribe, send an email to majordomo...@ with > >> the following command in the body of your email: > >> unsubscribe public_webgl > >> ----------------------------------------------------------- > >> > >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Tue Aug 14 10:16:20 2012 From: cma...@ (Chris Marrin) Date: Tue, 14 Aug 2012 10:16:20 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> Message-ID: On Aug 13, 2012, at 4:21 PM, Kenneth Russell wrote: > > ... > I apologize but I don't have concrete examples of missing > functionality. I can only say definitively from my experience that > doing markup on wiki pages by hand is tedious. David Sheets' work to > autogenerate the WebGL extension registry from XML files is a great > example of a massive productivity improvement. I can't imagine > maintaining the registry by hand any more. Similar productivity > increases could surely be achieved for the creation and maintenance of > WebGL reference pages by using some sort of template system rather > than writing wiki pages for each API call by hand. Currently, the IDL file is extracted from the spec (see https://github.com/KhronosGroup/WebGL/blob/master/specs/latest/extract-idl.py). Seems like the text for man pages could be similarly extracted. This might involve tagging additional elements in the spec, or adding some hidden elements with additional data. Then maybe the simplest thing to do would be to add this text to the IDL in Doxygen format so we can use those tools to generate various formats of man pages? ----- ~Chris Marrin cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Aug 14 11:10:08 2012 From: cal...@ (Mark Callow) Date: Tue, 14 Aug 2012 11:10:08 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> Message-ID: <502A9480.6060706@hicorp.co.jp> > On 12/08/13 19:15, Benoit Jacob wrote: > On the one hand, we have markup language that make it easy to write documents. On the other hand we have XML which gives automation but is a pain to write by hand. The only document writing system that combines convenient markup with good large-document-structuration-and-automation features, that I know of, is LaTeX. From the looks of the OpenGL [ES] PDF spec, it seems that it's made in LaTeX, for example (maybe someone can confirm). But compared to a wiki, this will increase the barrier to entry quite a bit. I don't think enabling trivial modifications at the expense of creating an immense amount of manual labor is the right trade-off. The OpenGL {,ES} specifications are done in LaTeX. The man pages are done in docbook and writing or editing those is no harder than html. The entry barrier comes in previewing the result as you need various docbook tools and available Unix-like make and scripting to generate the xhtml output. But we could probably run a post-commit script that rebuilds the man pages either on github or khronos.org. It should also be possible to get the xml source to display directly in some (most) browsers. Currently the files do not reference the necessary xsl files though. Then we just need a server that allows the pages to be edited. "The Docbook XML source for the OpenGL man pages is available for anonymous checkout in Khronos' Subversion server, and you can build a man page distribution of your own using open source tools. See the OpenGL.org technical Wiki pages describing the XML Toolchain and Man Pages for more information. " says the intro page of the man pages on opengl.org. The URL is https://cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs If you look in e.g., man4 for example, you can see the source xml files. The output files are in, e.g., man4/xhtml. I expect we can persuade Khronos to make the OpenGL ES man page sources similarly available possibly even on github. On 12/08/14 10:16, Chris Marrin wrote: > > > Currently, the IDL file is extracted from the spec (see > https://github.com/KhronosGroup/WebGL/blob/master/specs/latest/extract-idl.py). > Seems like the text for man pages could be similarly extracted. This > might involve tagging additional elements in the spec, or adding some > hidden elements with additional data. Then maybe the simplest thing to > do would be to add this text to the IDL in Doxygen format so we can > use those tools to generate various formats of man pages? > > If it wasn't for the issue that a lot of information will be duplicated between this and the OpenGL ES man pages and the related issue that the WebGL spec is not a complete standalone specification, I'd say go for it. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Aug 14 11:56:08 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Tue, 14 Aug 2012 11:56:08 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: <502A9480.6060706@hicorp.co.jp> References: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> <502A9480.6060706@hicorp.co.jp> Message-ID: On Tue, Aug 14, 2012 at 11:10 AM, Mark Callow wrote: > On 12/08/13 19:15, Benoit Jacob wrote: > > On the one hand, we have markup language that make it easy to write documents. On the other hand we have XML which gives automation but is a pain to write by hand. The only document writing system that combines convenient markup with good large-document-structuration-and-automation features, that I know of, is LaTeX. From the looks of the OpenGL [ES] PDF spec, it seems that it's made in LaTeX, for example (maybe someone can confirm). But compared to a wiki, this will increase the barrier to entry quite a bit. > > I don't think enabling trivial modifications at the expense of creating > an immense amount of manual labor is the right trade-off. > The point of the pages is as information, not automation. Sure automation might save some work but as has been demonstrated with not only the OpenGL and OpenGL ES man pages but also with just about every other project that has docs in a repo vs a wiki, making it easier to edit leads to more and better info. > > The OpenGL {,ES} specifications are done in LaTeX. > > The man pages are done in docbook and writing or editing those is no > harder than html. The entry barrier comes in previewing the result as you > need various docbook tools and available Unix-like make and scripting to > generate the xhtml output. But we could probably run a post-commit script > that rebuilds the man pages either on github or khronos.org. > > It should also be possible to get the xml source to display directly in > some (most) browsers. Currently the files do not reference the necessary > xsl files though. Then we just need a server that allows the pages to be > edited. > > "The Docbook XML source for the OpenGL man pages is available for > anonymous checkout in Khronos' Subversion server, and you can build a man > page distribution of your own using open source tools. See the OpenGL.org > technical Wiki pages describing the XML Toolchain and Man Pagesfor more information. " says the intro page of the man pages on > opengl.org. > > The URL is > > https://cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs > > If you look in e.g., man4 for example, you can see the source xml files. > The output files are in, e.g., man4/xhtml. > > I expect we can persuade Khronos to make the OpenGL ES man page sources > similarly available possibly even on github. > > > > On 12/08/14 10:16, Chris Marrin wrote: > > > > Currently, the IDL file is extracted from the spec (see > https://github.com/KhronosGroup/WebGL/blob/master/specs/latest/extract-idl.py). > Seems like the text for man pages could be similarly extracted. This might > involve tagging additional elements in the spec, or adding some hidden > elements with additional data. Then maybe the simplest thing to do would be > to add this text to the IDL in Doxygen format so we can use those tools to > generate various formats of man pages? > > > If it wasn't for the issue that a lot of information will be duplicated > between this and the OpenGL ES man pages and the related issue that the > WebGL spec is not a complete standalone specification, I'd say go for it. > I don't believe sharing info with the OpenGL ES man pages is really going to be all that useful. OpenGL ES is a C library. WebGL is a JavaScript library. OpenGL ES has a different API. Some places take GLint or GLuint where WebGL takes objects glBindTexture(target, texture_id) vs bindTexture(target, WebGLTexture). Some functions have been changed, glGetIntegerv, glGetFloatv, glGetBooeanv -> getParameter. glGenTextures -> createTexture. Function names are different glUniform1fv vs uniform1fv. Some functions have different parameters. glTexImage2D(target, level, internal_format, width, height, border, format, type, data) vs texImage2D(target, level, internal_format, format, type, element). On top of that WebGL can be execute in the docs, OpenGL can't. WebGL comes with a large library of functions (HTML5) that makes examples easier to write vs C where except for stl and file i/o not much is standardized. In other words, --how to load a jpg in WebGL-- var img = new Image(); img.onload = function(img) { loadTexture(img); }(img); img.src = "http://somesite.com/someimage.jpg"; function loadTexture(img) { var texture = gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, myTexture); gl.texImage2D(gl.TEXURE_2D, 0, gl.RGB, gl.RGB, gl.UNSIGNED_BYTE, img); } --How to load a jpg in OpenGL-- // Load jpg file. j = loadJPGSomeFunctionLeftAsAnExerciseForTeReader(jpg); int width = getWidthSomeFunctionLeftAsAnExerciseForTheReader(jpg) int height = getHeightSomeFunctionLeftAsAnExerciseForTheReader(jpg); const void* data = getDataSomeFunctionLeftAsAnExercizeForTheReader(jpg); glBindTexture(GL_TEXTURE_2D, my_texture_id); glTexImage2D(GL_TEXURE_2D, 0, GL_RGB, width, height, 0, gl.RGB, UNSIGNED_BYTE, data); // need to free the image. freeJPGSomeFunctionLeftAsAnExerciseForTheReader(jpg); The WebGL code works. The OpenGL code is psuedo code. It seems like trying to share info will only make things more confusing and difficult. > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Tue Aug 14 12:21:13 2012 From: ben...@ (Ben Vanik) Date: Tue, 14 Aug 2012 12:21:13 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> <502A9480.6060706@hicorp.co.jp> Message-ID: I agree with Gregg - I don't see much value in sharing in the long term, as it'd never be a 1:1 and would never be in sync. Maybe an initial population step could be run to bring over the existing content which could then be hand-converted, but I'd never want to see the monstrosity of a python script that would attempt to keep the two in sync with all the differences Gregg pointed out. I'd also love to see much more rich content that would never exist in the non-WebGL docs, like live examples/CodeMirror-like interactive editing/etc. The sooner the cut is made between the old and the new, the better. On Tue, Aug 14, 2012 at 11:56 AM, Gregg Tavares (??) wrote: > > > > On Tue, Aug 14, 2012 at 11:10 AM, Mark Callow wrote: > >> On 12/08/13 19:15, Benoit Jacob wrote: >> >> On the one hand, we have markup language that make it easy to write documents. On the other hand we have XML which gives automation but is a pain to write by hand. The only document writing system that combines convenient markup with good large-document-structuration-and-automation features, that I know of, is LaTeX. From the looks of the OpenGL [ES] PDF spec, it seems that it's made in LaTeX, for example (maybe someone can confirm). But compared to a wiki, this will increase the barrier to entry quite a bit. >> >> I don't think enabling trivial modifications at the expense of creating >> an immense amount of manual labor is the right trade-off. >> > > The point of the pages is as information, not automation. Sure automation > might save some work but as has been demonstrated with not only the OpenGL > and OpenGL ES man pages but also with just about every other project that > has docs in a repo vs a wiki, making it easier to edit leads to more and > better info. > > >> >> The OpenGL {,ES} specifications are done in LaTeX. >> >> The man pages are done in docbook and writing or editing those is no >> harder than html. The entry barrier comes in previewing the result as you >> need various docbook tools and available Unix-like make and scripting to >> generate the xhtml output. But we could probably run a post-commit script >> that rebuilds the man pages either on github or khronos.org. >> >> It should also be possible to get the xml source to display directly in >> some (most) browsers. Currently the files do not reference the necessary >> xsl files though. Then we just need a server that allows the pages to be >> edited. >> >> "The Docbook XML source for the OpenGL man pages is available for >> anonymous checkout in Khronos' Subversion server, and you can build a man >> page distribution of your own using open source tools. See the OpenGL.org >> technical Wiki pages describing the XML Toolchain and Man Pagesfor more information. " says the intro page of the man pages on >> opengl.org. >> >> The URL is >> >> https://cvs.khronos.org/svn/repos/ogl/trunk/ecosystem/public/sdk/docs >> >> If you look in e.g., man4 for example, you can see the source xml files. >> The output files are in, e.g., man4/xhtml. >> >> I expect we can persuade Khronos to make the OpenGL ES man page sources >> similarly available possibly even on github. >> >> >> >> On 12/08/14 10:16, Chris Marrin wrote: >> >> >> >> Currently, the IDL file is extracted from the spec (see >> https://github.com/KhronosGroup/WebGL/blob/master/specs/latest/extract-idl.py). >> Seems like the text for man pages could be similarly extracted. This might >> involve tagging additional elements in the spec, or adding some hidden >> elements with additional data. Then maybe the simplest thing to do would be >> to add this text to the IDL in Doxygen format so we can use those tools to >> generate various formats of man pages? >> >> >> If it wasn't for the issue that a lot of information will be duplicated >> between this and the OpenGL ES man pages and the related issue that the >> WebGL spec is not a complete standalone specification, I'd say go for it. >> > > I don't believe sharing info with the OpenGL ES man pages is really going > to be all that useful. OpenGL ES is a C library. WebGL is a JavaScript > library. OpenGL ES has a different API. Some places take GLint or GLuint > where WebGL takes objects glBindTexture(target, texture_id) vs > bindTexture(target, WebGLTexture). Some functions have been changed, > glGetIntegerv, glGetFloatv, glGetBooeanv -> getParameter. glGenTextures -> > createTexture. Function names are different glUniform1fv vs uniform1fv. > Some functions have different parameters. glTexImage2D(target, level, > internal_format, width, height, border, format, type, data) vs > texImage2D(target, level, internal_format, format, type, element). On top > of that WebGL can be execute in the docs, OpenGL can't. WebGL comes with a > large library of functions (HTML5) that makes examples easier to write vs C > where except for stl and file i/o not much is standardized. In other words, > > --how to load a jpg in WebGL-- > > var img = new Image(); > img.onload = function(img) { > loadTexture(img); > }(img); > img.src = "http://somesite.com/someimage.jpg"; > > function loadTexture(img) { > var texture = gl.createTexture(); > gl.bindTexture(gl.TEXTURE_2D, myTexture); > gl.texImage2D(gl.TEXURE_2D, 0, gl.RGB, gl.RGB, gl.UNSIGNED_BYTE, img); > } > > --How to load a jpg in OpenGL-- > > // Load jpg file. > j = loadJPGSomeFunctionLeftAsAnExerciseForTeReader(jpg); > > int width = getWidthSomeFunctionLeftAsAnExerciseForTheReader(jpg) > int height = getHeightSomeFunctionLeftAsAnExerciseForTheReader(jpg); > const void* data = getDataSomeFunctionLeftAsAnExercizeForTheReader(jpg); > > glBindTexture(GL_TEXTURE_2D, my_texture_id); > glTexImage2D(GL_TEXURE_2D, 0, GL_RGB, width, height, 0, gl.RGB, > UNSIGNED_BYTE, data); > > // need to free the image. > freeJPGSomeFunctionLeftAsAnExerciseForTheReader(jpg); > > The WebGL code works. The OpenGL code is psuedo code. > > It seems like trying to share info will only make things more confusing > and difficult. > > >> Regards >> >> -Mark >> >> -- >> ???????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????? ??? >> >> NOTE: This electronic mail message may contain confidential and >> privileged information from HI Corporation. If you are not the intended >> recipient, any disclosure, photocopying, distribution or use of the >> contents of the received information is prohibited. If you have received >> this e-mail in error, please notify the sender immediately and permanently >> delete this message and all related copies. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Aug 14 12:45:12 2012 From: cal...@ (Mark Callow) Date: Tue, 14 Aug 2012 12:45:12 -0700 Subject: [Public WebGL] WebGL Reference Pages In-Reply-To: References: <50930231.1621058.1344898503787.JavaMail.root@mozilla.com> <502A9480.6060706@hicorp.co.jp> Message-ID: <502AAAC8.3050402@hicorp.co.jp> On 12/08/14 11:56, Gregg Tavares (??) wrote: > > > > On Tue, Aug 14, 2012 at 11:10 AM, Mark Callow > > wrote: > >> On 12/08/13 19:15, Benoit Jacob wrote: >> On the one hand, we have markup language that make it easy to write documents. On the other hand we have XML which gives automation but is a pain to write by hand. The only document writing system that combines convenient markup with good large-document-structuration-and-automation features, that I know of, is LaTeX. From the looks of the OpenGL [ES] PDF spec, it seems that it's made in LaTeX, for example (maybe someone can confirm). But compared to a wiki, this will increase the barrier to entry quite a bit. > I don't think enabling trivial modifications at the expense of > creating an immense amount of manual labor is the right trade-off. > > > The point of the pages is as information, not automation. Sure > automation might save some work but as has been demonstrated with not > only the OpenGL and OpenGL ES man pages but also with just about every > other project that has docs in a repo vs a wiki, making it easier to > edit leads to more and better info. Automation != docs in a repo. What it means is using a format that carries semantic information about the content. Such a format could easily be on a server that allows editing of the pages. Wiki's are just one type of web page that can be edited. Incidentally it is not hard to find examples of wiki-based crowd-sourced documentation with a lot of out-dated information. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Aug 17 17:44:15 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 17 Aug 2012 17:44:15 -0700 Subject: [Public WebGL] SIGGRAPH 2012 WebGL content available Message-ID: [cross-posted to webgl-dev-list] WebGL community, The content from the SIGGRAPH 2012 WebGL Birds of a Feather session is now available on the WebGL wiki. There were thirteen excellent presentations in the space of an hour (well, closer to an hour and ten minutes) -- the majority of which are now permanently archived for your viewing pleasure! http://www.khronos.org/webgl/wiki/Presentations#SIGGRAPH_2012_WebGL_BOF More content will be coming online, hopefully including the video soon, so please check back. There was also a course delivered at SIGGRAPH entitled "Graphics Programming for the Web" by Pushkar Joshi, Zhenyao Mo, Mikael Bourges-Sevenier, and myself. All of the content from that course is now available on line: http://www.khronos.org/webgl/wiki/Presentations#SIGGRAPH_2012_Course_.22Graphics_Programming_for_the_Web.22 Any feedback welcome! -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Tue Aug 21 10:15:50 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Tue, 21 Aug 2012 10:15:50 -0700 Subject: [Public WebGL] Just thought I'd pass this on Message-ID: http://lists.w3.org/Archives/Public/public-fx/2012JulSep/0074.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Aug 21 10:31:22 2012 From: bja...@ (Benoit Jacob) Date: Tue, 21 Aug 2012 10:31:22 -0700 (PDT) Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: Message-ID: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> If I had an involvement in CSS filters, I would fiercely oppose allowing multiple shading languages. If multiple shading languages are allowed, - either every browser will have to support every language, an unjustified maintenance burden; - or certain pages will work only in certain browsers, something that we normally try to prevent. Benoit ----- Original Message ----- > http://lists.w3.org/Archives/Public/public-fx/2012JulSep/0074.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Aug 21 10:45:47 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 21 Aug 2012 19:45:47 +0200 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> Message-ID: Ok, so let me get this straight: Everytime that the community of browser vendors comes up with a single standard to solve something, Microsoft comes up with a slightly different but incompatible flavor of it making web developers life a living hell. Previous examples include: - CSS alpha via filters - audio codecs - video codecs - spdy - WebRTC codecs They also steadfastly refuse to implement things like WebGL for reasons only they themselves can fathom. And now, they're just proposing to add another one to the list of web-sabotaging technologies: CSS shaders. And they don't just stop at the Web either, they extend this behavior to other standards (like word processor standards) as well. This is entirely unacceptable behavior. If they don't want to implement something they can just do that. There is no need to continuously sabotage the web with all these intentional incompatibilities. We've seen this behavior from Microsoft for a long time now. And need I remember anybody how Microsoft managed to sabotage 3D on the web in the first place in the 90ties at the time they developed DirectX and which lead to their retreat from the Khronos boards. At this time I would suggest to any standards body to: - Discard any input from Microsoft with prejudice - Do not try to appease to Microsoft as a "vendor" of web technologies because their sole intent is clearly to keep the web from becoming a feasable platform - Do not show tolerance for intentionally malicious behavior -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Aug 21 16:13:26 2012 From: cal...@ (Mark Callow) Date: Tue, 21 Aug 2012 16:13:26 -0700 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> Message-ID: <50341616.30500@hicorp.co.jp> On 12/08/21 10:31, Benoit Jacob wrote: > If I had an involvement in CSS filters, I would fiercely oppose > allowing multiple shading languages. If multiple shading languages are > allowed, > - either every browser will have to support every language, an > unjustified maintenance burden; > - or certain pages will work only in certain browsers, something that > we normally try to prevent. Won't the same choice arise when at some point in the future CSS filters wants to move to a new version of GLSL ES? It's very clever of MS to cite being able to change the GLSL version as the reason for their objection but it seems inevitable it will happen some day. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Tue Aug 21 16:53:36 2012 From: kos...@ (David Sheets) Date: Tue, 21 Aug 2012 16:53:36 -0700 Subject: [Public WebGL] Re: [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> Message-ID: On Tue, Aug 21, 2012 at 2:32 PM, Dirk Schulze wrote: > Hi, > > On Aug 21, 2012, at 2:03 PM, Dean Jackson wrote: > >> >> On 22/08/2012, at 2:52 AM, Sylvain Galineau wrote: >> >>> The normative prose of section 38.2 'Recommended shading language' recommends >>> GL SL ES [1]. Per RFC2119 this means implementers MUST support GL SL ES >>> unless there exist 'valid reasons in particular circumstances' to ignore this >>> recommendation. >>> >>> While Microsoft has no objection to defining how the feature works for UAs >>> that choose GL SL ES as defined by Web GL 1.0, we object to its normative >>> recommendation. >> >> Can you explain why you object? You mention below what you'd prefer, but don't >> provide reasoning. >> >> The informative section related to media codecs is there because there are >> well-known IP issues around that technology. As far as I am aware, this does >> not apply in the case of shading languages. >> >> Also, don't you (Microsoft) agree there is a significant penalty if we don't require >> a single shading language? What is it in particular about GLSL that you object >> to? > CSS Shaders as well as Filter Effects never required GLSL (on base of WebGL), but it is the recommended shading language. Therefore I don't share Sylvain's concerns that an implementation must support GLSL. > >> >> Dean >> >>> This was the reason for the note in the same section, note >>> which looks at best confusing if not contradictory given the normative >>> recommendation that precedes it. >>> >>> We would prefer to follow a pattern similar to the informative section 6.1 in >>> Media Source Extension[2]: "This section defines segment formats for >>> implementations that choose to support WebM". We think the ability to specify >>> multiple shading languages is important, as broadly suggested by the current >>> note. This allows sites to work with different user agents supporting different >>> shading languages. For example, a future version of GL SL ES with fallback to >>> the current version for user agents that don't yet support the new version. > I think it is a good idea to think about future versions of GLSL as well. Therefore adding a feature string that helps the UA to decide if a shader is supported or not, and provide a fullback shader doesn't sound like a bad idea. GLSL ES versions are self-describing. That is, all future versions of GLSL ES should contain a declaration like: #version 300 es which directs consumers as to the semiotics required for handling. The family of GLSL ES languages (including versions, shader stages, and per-vendor deviations) should be registered as a single IANA media type like every other legitimate web language. This problem of different resource representations has been encountered again and again on the net (and the Web). Media types are the solution that the platform has adopted. Publication of an RFC and registration of a media type helps keep WebGL and its shading language as the standard. MS can and will compete with whatever software it wishes. A single URI can identify a collection of equivalent resources through HTTP content negotiation and no new API is required. It is time for GLSL ES to come into the Open Web and compete in the marketplace of ideas. Khronos should register "application/webglsl" with an optional version parameter, open the GLSL ES WG completely to the public, and invite MS to attempt to compete. Stewardship and inclusion beats hegemony and exclusion in the Age of Knowledge. David > Greetings, > Dirk > >>> >>> >>> [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#recommendation >>> [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html >>> >>> >>> >> >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Aug 21 23:12:04 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Aug 2012 08:12:04 +0200 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: <50341616.30500@hicorp.co.jp> References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <50341616.30500@hicorp.co.jp> Message-ID: On Wed, Aug 22, 2012 at 1:13 AM, Mark Callow wrote: > Won't the same choice arise when at some point in the future CSS filters > wants to move to a new version of GLSL ES? It's very clever of MS to cite > being able to change the GLSL version as the reason for their objection but > it seems inevitable it will happen some day. > It's not clever. If their desire was to ensure that future revisions can be cleanly supported, they would propose to make the first version the only valid syntax, but have a mechanism to target future revisions. They did however not propose that, instead they proposed to just leave the syntax entirely open, ostensibly because they intend to break it for everybody, again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Aug 21 23:18:08 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Aug 2012 08:18:08 +0200 Subject: [Public WebGL] Re: [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> Message-ID: On Wed, Aug 22, 2012 at 1:53 AM, David Sheets wrote: > >>> While Microsoft has no objection to defining how the feature works for > UAs > >>> that choose GL SL ES as defined by Web GL 1.0, we object to its > normative > >>> recommendation. > >> > >> Can you explain why you object? You mention below what you'd prefer, > but don't > >> provide reasoning. > >> > >> The informative section related to media codecs is there because there > are > >> well-known IP issues around that technology. As far as I am aware, this > does > >> not apply in the case of shading languages. > >> > >> Also, don't you (Microsoft) agree there is a significant penalty if we > don't require > >> a single shading language? What is it in particular about GLSL that you > object > >> to? > > CSS Shaders as well as Filter Effects never required GLSL (on base of > WebGL), but it is the recommended shading language. Therefore I don't share > Sylvain's concerns that an implementation must support GLSL. > > I think it is a good idea to think about future versions of GLSL as > well. Therefore adding a feature string that helps the UA to decide if a > shader is supported or not, and provide a fullback shader doesn't sound > like a bad idea. > Thinking of future versions under the premise of one standardized syntax, and future standardized syntax [OK] because friendly to web authors. Proposing to keep syntax undefined and let everybody cook his own [NOT OK], because not friendly to web authors and just another way to break the web. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Aug 22 00:15:16 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Aug 2012 09:15:16 +0200 Subject: [Public WebGL] Re: [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> Message-ID: On Wed, Aug 22, 2012 at 9:01 AM, David Sheets wrote: > I don't believe anyone is proposing an undefined syntax (unless you > count the bugs in GLSL). > Microsoft is proposing to not to fix the syntax so they can do their own. > Given the choice between no support in IE and support with a different > shading language, the latter is highly preferable. > I disagree. Given a choice of a standard that *is* a standard in the sense that it specifies how something works, so developers can use it in a consistent fashion is highly preferable to a "standard" that works differently everywhere. If Microsoft does not agree to "standardize" something, they should just come out and say so instead of sabotaging a standard. Or perhaps you would like MS to implement something with the same > syntax as GLSL ES but with different semantics? That would be > absolutely terrible. > No, I don't want that. You're putting words in my mouth, I thought it is quite obvious, but what I (and absolutely *every* web author) wants is: - A single standard - With defined api/syntax - With defined semantics - Working everywhere the *same* I fiercely, strongly, absolutely, vehemently, angrily object to "standards" that are intentionally crafted to sabotage these goals. > Florian, we must assume we have no direct influence in the language > forking. It will happen. To win, we have to accept it and make it > irrelevant. To accept it and make it irrelevant, we have to convince > everyone involved to do it in the most straightforward/integrated way. > If MS can be convinced to load a different language under a different > name through a very standard interface, sanity will have prevailed. MS > will do this shit anyway. How would we like to respond? If Microsoft wants to do their own thing, they're free to do so. I am not in favor of sabotaging a standard (yet again) in order to appease Microsofts desire to claim to be "standards compatible" when in fact they perverted the purpose of the standard in the first place. If Microsoft/IE does not want to be standards compatible, that is *their* choice, and they should man up to stating "we don't care about that" instead of trying to look good by fooling us into giving into their maliciously scheming sabotaging of standards. Let standards be standards, be real standards. They do not "define" the web, however they define a spirit of collaboration. Microsoft does clearly not want to "collaborate" so I don't see why the discussion of this standard should concern itself with the opinion of Microsoft. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Aug 22 00:43:11 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Aug 2012 09:43:11 +0200 Subject: [Public WebGL] Re: [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> Message-ID: In the spirit of collaboration, Apple, Google, Microsoft, Mozilla, say hi to each other. Microsoft, you can't agree to GLSL The others, you can't agree to IESL Now everybody get together. Group hug. Great, now work something out, I don't care what, that works the same. If you need to invent some new shading language that appeals to everybody do so. You don't serve your internal politics, standards are not some intellectual game. Make it work for the world, your users and the web. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Aug 22 02:03:50 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Aug 2012 11:03:50 +0200 Subject: [Public WebGL] Re: [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> Message-ID: For posterity http://codeflow.org/entries/2012/aug/22/css-shaders-w3c-microsoft-and-broken-standards/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Wed Aug 22 07:28:47 2012 From: cma...@ (Chris Marrin) Date: Wed, 22 Aug 2012 07:28:47 -0700 Subject: [Public WebGL] [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> Message-ID: <16E9E3BC-E27C-4755-99A6-DFEF0F82DA5A@apple.com> On Aug 22, 2012, at 12:43 AM, Florian B?sch wrote: > In the spirit of collaboration, Apple, Google, Microsoft, Mozilla, say hi to each other. > > Microsoft, you can't agree to GLSL > The others, you can't agree to IESL > > Now everybody get together. Group hug. Great, now work something out, I don't care what, that works the same. If you need to invent some new shading language that appeals to everybody do so. You don't serve your internal politics, standards are not some intellectual game. Make it work for the world, your users and the web. Florian, your comments are completely inappropriate for this forum. You have every right to produce any rant you like on your personal website. But we are here to do work and not lambast one member because of perceived evil intent. Sylvain has raised a legitimate issue, which we are discussing in a civilized way. Please take your personal attacks and rants elsewhere. I'll respond to the legitimate issues raised in a separate post... ----- ~Chris Marrin cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Aug 22 09:20:56 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Aug 2012 18:20:56 +0200 Subject: [Public WebGL] [filters] Shading language recommendation In-Reply-To: <16E9E3BC-E27C-4755-99A6-DFEF0F82DA5A@apple.com> References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> <16E9E3BC-E27C-4755-99A6-DFEF0F82DA5A@apple.com> Message-ID: On Wed, Aug 22, 2012 at 4:28 PM, Chris Marrin wrote: > Florian, your comments are completely inappropriate for this forum. You > have every right to produce any rant you like on your personal website. But > we are here to do work and not lambast one member because of perceived evil > intent. Sylvain has raised a legitimate issue, which we are discussing in a > civilized way. Please take your personal attacks and rants elsewhere. > That may be true, the style may be questionable, but the message is not. I think I made that quite clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toj...@ Wed Aug 22 11:17:30 2012 From: toj...@ (Brandon Jones) Date: Wed, 22 Aug 2012 11:17:30 -0700 Subject: [Public WebGL] [filters] Shading language recommendation In-Reply-To: <16E9E3BC-E27C-4755-99A6-DFEF0F82DA5A@apple.com> References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> <16E9E3BC-E27C-4755-99A6-DFEF0F82DA5A@apple.com> Message-ID: On Wed, Aug 22, 2012 at 7:28 AM, Chris Marrin wrote: > Sylvain has raised a legitimate issue, which we are discussing in a > civilized way. > I feel like I'm missing out on part of this conversation. All I can see from Microsoft is: "While Microsoft has no objection to defining how the feature works for UAs that choose GL SL ES as defined by Web GL 1.0, we object to its normative recommendation. ... We think the ability to specify multiple shading languages is important, as broadly suggested by the current note. This allows sites to work with different user agents supporting different shading languages. For example, a future version of GL SL ES with fallback to the current version for user agents that don't yet support the new version." I'm not sure what the "legitimate issue" is here. It sounds very much to me as if Microsoft simply doesn't want to support GLSL and wishes to be given free reign to implement their own shading language instead (presumably a HLSL derivative). The only real reasoning provided is a vague concern about backwards compatibility for GLSL, which David Sheets identified as a non-issue. If there is really a legitimate concern here beyond Microsoft not wanting to support a shading language other than their own I'm very interested to hear it, but otherwise it's hard to see the suggestion of standardizing on a non-standard as anything but harmful to the web. That's not exactly "evil intent", but it's hard to justify nonetheless. --Brandon Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Wed Aug 22 12:04:26 2012 From: ste...@ (Steve Baker) Date: Wed, 22 Aug 2012 14:04:26 -0500 Subject: [Public WebGL] [filters] Shading language recommendation In-Reply-To: References: <3C4041FF83E1E04A986B6DC50F0178291BE2CBB5@TK5EX14MBXC227.redmond.corp.microsoft.com> <02ED79AA-682E-471D-88BF-CCCADAF7E41C@apple.com> <16E9E3BC-E27C-4755-99A6-DFEF0F82DA5A@apple.com> Message-ID: <06424cb5e9b225ac06325573ebd9da4b.squirrel@webmail.sjbaker.org> The crazy part is that WebGL doesn't permit anything other than GLSL - so a fully compliant/fully featured browser needs a GLSL implementation anyway. If you have GLSL for WebGL then why the heck wouldn't you just use it for CSS too? Ergo, the only possible reason you'd want anything other than GLSL for CSS is if you've decided that you're never going to support WebGL. So, this amounts to a veiled statement that IE will never support WebGL. Why are we even bothering to talk to Microsoft? They don't deserve a place at the table. -- Steve Brandon Jones wrote: > On Wed, Aug 22, 2012 at 7:28 AM, Chris Marrin wrote: > > >> Sylvain has raised a legitimate issue, which we are discussing in a >> civilized way. >> > > I feel like I'm missing out on part of this conversation. All I can see > from Microsoft is: > > "While Microsoft has no objection to defining how the feature works > for UAs that > choose GL SL ES as defined by Web GL 1.0, we object to its normative > recommendation. > ... We think the ability to specify multiple shading languages is > important, as broadly suggested by the current note. This allows sites to > work with different user agents supporting different shading languages. > For > example, a future version of GL SL ES with fallback to the current version > for user agents that don't yet support the new version." > > I'm not sure what the "legitimate issue" is here. It sounds very much to > me > as if Microsoft simply doesn't want to support GLSL and wishes to be given > free reign to implement their own shading language instead (presumably a > HLSL derivative). The only real reasoning provided is a vague concern > about > backwards compatibility for GLSL, which David Sheets identified as a > non-issue. > > If there is really a legitimate concern here beyond Microsoft not wanting > to support a shading language other than their own I'm very interested to > hear it, but otherwise it's hard to see the suggestion of standardizing on > a non-standard as anything but harmful to the web. That's not exactly > "evil > intent", but it's hard to justify nonetheless. > > --Brandon Jones > -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Thu Aug 23 08:51:13 2012 From: cma...@ (Chris Marrin) Date: Thu, 23 Aug 2012 08:51:13 -0700 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> Message-ID: <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> So posting all your bile on the fx list not enough is it? :-) On Aug 21, 2012, at 10:45 AM, Florian B?sch wrote: > Ok, so let me get this straight: > > Everytime that the community of browser vendors comes up with a single standard to solve something, Microsoft comes up with a slightly different but incompatible flavor of it making web developers life a living hell. Previous examples include: > > - CSS alpha via filters > - audio codecs > - video codecs > - spdy > - WebRTC codecs > > They also steadfastly refuse to implement things like WebGL for reasons only they themselves can fathom. And now, they're just proposing to add another one to the list of web-sabotaging technologies: CSS shaders. > And they don't just stop at the Web either, they extend this behavior to other standards (like word processor standards) as well. Sylvain, as a representative of Microsoft, has been extremely civil (unlike you) in his objection to the required shading language. He's raised the issue and now we're discussing it. As you can see from the thread, there are many of us arguing in favor of a required shading language and are now attempting to understand the nature of the objection. I don't think he is attempting to sabotage anything. And I think Microsoft is well aware of the fact that the days of going their own way with their web browser is a thing of the past. I'm sure they're struggling with the notion of having to support GLSL even now. By mentioning ANGLE and the fact that WebGL is running successfully on top of Direct3D, we're trying to help them understand that they can support GLSL in a non-threatening way. I don't know if that will change their minds. But I do know that your anti-Microsoft rants aren't helping anything. > > This is entirely unacceptable behavior. If they don't want to implement something they can just do that. There is no need to continuously sabotage the web with all these intentional incompatibilities. We've seen this behavior from Microsoft for a long time now. And need I remember anybody how Microsoft managed to sabotage 3D on the web in the first place in the 90ties at the time they developed DirectX and which lead to their retreat from the Khronos boards. There is certainly unacceptable behavior happening on the fx list, but it's not coming from Microsoft! > > At this time I would suggest to any standards body to: > - Discard any input from Microsoft with prejudice > - Do not try to appease to Microsoft as a "vendor" of web technologies because their sole intent is clearly to keep the web from becoming a feasable platform > - Do not show tolerance for intentionally malicious behavior Thank you for your suggestion. :-) ----- ~Chris Marrin cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Aug 23 08:53:46 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 23 Aug 2012 17:53:46 +0200 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> Message-ID: On Thu, Aug 23, 2012 at 5:51 PM, Chris Marrin wrote: > So posting all your bile on the fx list not enough is it? :-) > > On Aug 21, 2012, at 10:45 AM, Florian B?sch wrote: > > Ok, so let me get this straight: > > Everytime that the community of browser vendors comes up with a single > standard to solve something, Microsoft comes up with a slightly different > but incompatible flavor of it making web developers life a living hell. > Previous examples include: > > - CSS alpha via filters > - audio codecs > - video codecs > - spdy > - WebRTC codecs > > They also steadfastly refuse to implement things like WebGL for reasons > only they themselves can fathom. And now, they're just proposing to add > another one to the list of web-sabotaging technologies: CSS shaders. > And they don't just stop at the Web either, they extend this behavior to > other standards (like word processor standards) as well. > > > Sylvain, as a representative of Microsoft, has been extremely civil > (unlike you) in his objection to the required shading language. He's raised > the issue and now we're discussing it. As you can see from the thread, > there are many of us arguing in favor of a required shading language and > are now attempting to understand the nature of the objection. > > I don't think he is attempting to sabotage anything. And I think Microsoft > is well aware of the fact that the days of going their own way with their > web browser is a thing of the past. I'm sure they're struggling with the > notion of having to support GLSL even now. By mentioning ANGLE and the fact > that WebGL is running successfully on top of Direct3D, we're trying to help > them understand that they can support GLSL in a non-threatening way. > > I don't know if that will change their minds. But I do know that your > anti-Microsoft rants aren't helping anything. > > > This is entirely unacceptable behavior. If they don't want to implement > something they can just do that. There is no need to continuously sabotage > the web with all these intentional incompatibilities. We've seen this > behavior from Microsoft for a long time now. And need I remember anybody > how Microsoft managed to sabotage 3D on the web in the first place in the > 90ties at the time they developed DirectX and which lead to their retreat > from the Khronos boards. > > > There is certainly unacceptable behavior happening on the fx list, but > it's not coming from Microsoft! > Spare me, you're reacting to tone, I'm reacting to content. I'm not civil. I don't see civility required when I see an approaching trainwreck. Appropriate response: panic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmg...@ Thu Aug 23 10:51:01 2012 From: cmg...@ (Fabrice Robinet) Date: Thu, 23 Aug 2012 10:51:01 -0700 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> Message-ID: As stated many times by Chris, It's legitimate from Microsoft to raise concern, this is a place for discussion. But if Microsoft concern only state that GLSL should not be the only one shader language for CSS Shader. Then it is not clear where that leaves us. It looks like it is high time to stop speculating / inferring about what Sylvain means, but this requires some of this help. Without elaborating on clear/concrete reasons/use cases to have CSS Shader support something else than GLSL it's hard to refrain from thinking that the root reason is not something like "not invented by microsoft". I believe the discussion would get more constructive if the focus was more about features/use cases than formalism (and rhetoric...). Fabrice. On Thu, Aug 23, 2012 at 8:53 AM, Florian B?sch wrote: > > > On Thu, Aug 23, 2012 at 5:51 PM, Chris Marrin wrote: > >> So posting all your bile on the fx list not enough is it? :-) >> >> On Aug 21, 2012, at 10:45 AM, Florian B?sch wrote: >> >> Ok, so let me get this straight: >> >> Everytime that the community of browser vendors comes up with a single >> standard to solve something, Microsoft comes up with a slightly different >> but incompatible flavor of it making web developers life a living hell. >> Previous examples include: >> >> - CSS alpha via filters >> - audio codecs >> - video codecs >> - spdy >> - WebRTC codecs >> >> They also steadfastly refuse to implement things like WebGL for reasons >> only they themselves can fathom. And now, they're just proposing to add >> another one to the list of web-sabotaging technologies: CSS shaders. >> And they don't just stop at the Web either, they extend this behavior to >> other standards (like word processor standards) as well. >> >> >> Sylvain, as a representative of Microsoft, has been extremely civil >> (unlike you) in his objection to the required shading language. He's raised >> the issue and now we're discussing it. As you can see from the thread, >> there are many of us arguing in favor of a required shading language and >> are now attempting to understand the nature of the objection. >> >> I don't think he is attempting to sabotage anything. And I think >> Microsoft is well aware of the fact that the days of going their own way >> with their web browser is a thing of the past. I'm sure they're struggling >> with the notion of having to support GLSL even now. By mentioning ANGLE and >> the fact that WebGL is running successfully on top of Direct3D, we're >> trying to help them understand that they can support GLSL in a >> non-threatening way. >> >> I don't know if that will change their minds. But I do know that your >> anti-Microsoft rants aren't helping anything. >> >> >> This is entirely unacceptable behavior. If they don't want to implement >> something they can just do that. There is no need to continuously sabotage >> the web with all these intentional incompatibilities. We've seen this >> behavior from Microsoft for a long time now. And need I remember anybody >> how Microsoft managed to sabotage 3D on the web in the first place in the >> 90ties at the time they developed DirectX and which lead to their retreat >> from the Khronos boards. >> >> >> There is certainly unacceptable behavior happening on the fx list, but >> it's not coming from Microsoft! >> > Spare me, you're reacting to tone, I'm reacting to content. I'm not civil. > I don't see civility required when I see an approaching trainwreck. > Appropriate response: panic. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Aug 23 11:12:50 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 23 Aug 2012 20:12:50 +0200 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> Message-ID: On Thu, Aug 23, 2012 at 7:51 PM, Fabrice Robinet wrote: > I believe the discussion would get more constructive if the focus was more > about features/use cases than formalism (and rhetoric...). > Insisting that a single shading language be defined by the standard is hardly rhetoric, it's common sense. I'm not particularly attached to GLSL. If Microsoft has a better idea that they would like to convince everybody of to use that's fine by me. I'll leave the hashing out of whose idea gets to make the new CSS Shading Shading Language up to the experts. I'm not interested in giving any comment on that and not qualified. I do insist however that this be discussed under the premises that the outcome is a *single* shading language everybody agrees on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toj...@ Thu Aug 23 11:54:00 2012 From: toj...@ (Brandon Jones) Date: Thu, 23 Aug 2012 11:54:00 -0700 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> Message-ID: You know, it's a little absurd that we're getting so worked up about a single comment from Microsoft. What's happened, in essence, is that Sylvain jumped on the mailing list and said: "We don't want to support GLSL and we don't really want to explain why" And everyone else goes a little nutty because of it. Isn't it reasonable to respond with "Great, we'll discuss legitimate issues as they are raised but until you provide us with some specific problems we're going to ignore you?" On Thu, Aug 23, 2012 at 11:12 AM, Florian B?sch wrote: > On Thu, Aug 23, 2012 at 7:51 PM, Fabrice Robinet wrote: > >> I believe the discussion would get more constructive if the focus was >> more about features/use cases than formalism (and rhetoric...). >> > Insisting that a single shading language be defined by the standard is > hardly rhetoric, it's common sense. I'm not particularly attached to GLSL. > If Microsoft has a better idea that they would like to convince everybody > of to use that's fine by me. I'll leave the hashing out of whose idea gets > to make the new CSS Shading Shading Language up to the experts. I'm not > interested in giving any comment on that and not qualified. I do insist > however that this be discussed under the premises that the outcome is a > *single* shading language everybody agrees on. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Thu Aug 23 11:56:31 2012 From: kos...@ (David Sheets) Date: Thu, 23 Aug 2012 11:56:31 -0700 Subject: [Public WebGL] Universal Shading Language Governance Message-ID: If Khronos members are truly interested in promulgating GLSL ES as the One True Web Shading Language for Universal Adoption: 1. Why is the GLSL ES WG private? 2. Why is the GLSL ES 1.0 spec so out of date? 3. Why is the GLSL ES spec source still unavailable? 4. Why is the GLSL ES shader source media type still undefined? Languages developed in secret by committees don't have a great track record. Developers do not appreciate unnecessary obstructions. Khronos has had significant implementation quality control problems with its 'conformant' member implementations. Stewardship and inclusion beat hegemony and exclusion in the Age of Knowledge. Your reasoned response is appreciated. Love, David W. W. Sheets P.S. Plan ahead. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Thu Aug 23 12:30:08 2012 From: ste...@ (Steve Baker) Date: Thu, 23 Aug 2012 14:30:08 -0500 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> Message-ID: There are really two clear cases here: 1) That MS are saying that IN ADDITION TO supporting GLSL, browsers should be allowed to support additional shader language(s). Implying that you can choose to do all of your website design using only GLSL if you choose to do so. 2) That MS are saying that INSTEAD OF supporting GLSL, browsers should be allowed to support something else. Implying that to develop a true cross-platform website, you'd have to write and test your shaders in two or more different shader languages. If it's (1) then we have to ask why we need these additional languages if every browser already has to support GLSL? Can't whatever fancy features that these languages have be better supported as GLSL extensions? If it's (2) (which I believe is MS's current position) then why can't they support GLSL using the same implementation that they'll use to support WebGL? The clear implication of this position is that they aren't going to implement GLSL in the browser at all - which has obvious ramifications for WebGL support in IE. Subtly different requirements...very different consequences. -- Steve Fabrice Robinet wrote: > As stated many times by Chris, It's legitimate from Microsoft to raise > concern, this is a place for discussion. > > But if Microsoft concern only state that GLSL should not be the only one > shader language for CSS Shader. > Then it is not clear where that leaves us. > > It looks like it is high time to stop speculating / inferring about what > Sylvain means, but this requires some of this help. > Without elaborating on clear/concrete reasons/use cases to have CSS > Shader > support something else than GLSL it's hard to refrain from thinking that > the root reason is not something like "not invented by microsoft". > > I believe the discussion would get more constructive if the focus was more > about features/use cases than formalism (and rhetoric...). > > Fabrice. > > On Thu, Aug 23, 2012 at 8:53 AM, Florian B?sch wrote: > >> >> >> On Thu, Aug 23, 2012 at 5:51 PM, Chris Marrin wrote: >> >>> So posting all your bile on the fx list not enough is it? :-) >>> >>> On Aug 21, 2012, at 10:45 AM, Florian B?sch wrote: >>> >>> Ok, so let me get this straight: >>> >>> Everytime that the community of browser vendors comes up with a single >>> standard to solve something, Microsoft comes up with a slightly >>> different >>> but incompatible flavor of it making web developers life a living hell. >>> Previous examples include: >>> >>> - CSS alpha via filters >>> - audio codecs >>> - video codecs >>> - spdy >>> - WebRTC codecs >>> >>> They also steadfastly refuse to implement things like WebGL for reasons >>> only they themselves can fathom. And now, they're just proposing to add >>> another one to the list of web-sabotaging technologies: CSS shaders. >>> And they don't just stop at the Web either, they extend this behavior >>> to >>> other standards (like word processor standards) as well. >>> >>> >>> Sylvain, as a representative of Microsoft, has been extremely civil >>> (unlike you) in his objection to the required shading language. He's >>> raised >>> the issue and now we're discussing it. As you can see from the thread, >>> there are many of us arguing in favor of a required shading language >>> and >>> are now attempting to understand the nature of the objection. >>> >>> I don't think he is attempting to sabotage anything. And I think >>> Microsoft is well aware of the fact that the days of going their own >>> way >>> with their web browser is a thing of the past. I'm sure they're >>> struggling >>> with the notion of having to support GLSL even now. By mentioning ANGLE >>> and >>> the fact that WebGL is running successfully on top of Direct3D, we're >>> trying to help them understand that they can support GLSL in a >>> non-threatening way. >>> >>> I don't know if that will change their minds. But I do know that your >>> anti-Microsoft rants aren't helping anything. >>> >>> >>> This is entirely unacceptable behavior. If they don't want to implement >>> something they can just do that. There is no need to continuously >>> sabotage >>> the web with all these intentional incompatibilities. We've seen this >>> behavior from Microsoft for a long time now. And need I remember >>> anybody >>> how Microsoft managed to sabotage 3D on the web in the first place in >>> the >>> 90ties at the time they developed DirectX and which lead to their >>> retreat >>> from the Khronos boards. >>> >>> >>> There is certainly unacceptable behavior happening on the fx list, but >>> it's not coming from Microsoft! >>> >> Spare me, you're reacting to tone, I'm reacting to content. I'm not >> civil. >> I don't see civility required when I see an approaching trainwreck. >> Appropriate response: panic. >> > -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Thu Aug 23 12:42:51 2012 From: ste...@ (Steve Baker) Date: Thu, 23 Aug 2012 14:42:51 -0500 Subject: [Public WebGL] Just thought I'd pass this on In-Reply-To: References: <1455469389.2587291.1345570282429.JavaMail.root@mozilla.com> <7D1E9ED4-A8D7-4D51-843A-76EDD1B057A9@apple.com> Message-ID: Florian B?sch wrote: > On Thu, Aug 23, 2012 at 7:51 PM, Fabrice Robinet > wrote: > >> I believe the discussion would get more constructive if the focus was >> more >> about features/use cases than formalism (and rhetoric...). >> > Insisting that a single shading language be defined by the standard is > hardly rhetoric, it's common sense. I'm not particularly attached to GLSL. > If Microsoft has a better idea that they would like to convince everybody > of to use that's fine by me. I'll leave the hashing out of whose idea gets > to make the new CSS Shading Shading Language up to the experts. I'm not > interested in giving any comment on that and not qualified. I do insist > however that this be discussed under the premises that the outcome is a > *single* shading language everybody agrees on. It's at least plausible that one could argue that GLSL is unsuitable as "The One True Shader Language" for CSS - maybe there are things that CSS needs that GLSL can't cope with. I have no problem with debating that position if there are strong technical reasons why GLSL is unsuitable for CSS. The issue is whether we'll wind up with some browsers that only support GLSL and others that only support IESL (or whatever it's called). That's just nasty. If GLSL is somehow unsuitable for CSS (I don't see why that would be...but then I could be wrong) then it's unsuitable for everyone and we need to figure out a common standard that will work and have every browser support it rather than a patchwork quilt of support for different languages. -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu Aug 23 14:42:59 2012 From: bja...@ (Benoit Jacob) Date: Thu, 23 Aug 2012 14:42:59 -0700 (PDT) Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: Message-ID: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> I, too, would like more public-ness. But right now is a difficult time to argue for that: after the rants posted on this list and on public-fx over the past few days, it is harder than usual to argue for public mailing lists as places for getting work done. Benoit ----- Original Message ----- > > If Khronos members are truly interested in promulgating GLSL ES as > the > One True Web Shading Language for Universal Adoption: > > 1. Why is the GLSL ES WG private? > 2. Why is the GLSL ES 1.0 spec so out of date? > 3. Why is the GLSL ES spec source still unavailable? > 4. Why is the GLSL ES shader source media type still undefined? > > Languages developed in secret by committees don't have a great track > record. Developers do not appreciate unnecessary obstructions. > > Khronos has had significant implementation quality control problems > with its 'conformant' member implementations. > > Stewardship and inclusion beat hegemony and exclusion in the Age of > Knowledge. > > Your reasoned response is appreciated. > > Love, > > David W. W. Sheets > > P.S. Plan ahead. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Aug 23 14:56:35 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 23 Aug 2012 23:56:35 +0200 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: On Thu, Aug 23, 2012 at 11:42 PM, Benoit Jacob wrote: > But right now is a difficult time to argue for that: after the rants > posted on this list and on public-fx over the past few days, it is harder > than usual to argue for public mailing lists as places for getting work > done. There's no work done here in the first place, at all. Zip, zilch, nada. We have colorful exchanges and throw around ideas, but far as "work" goes, the height is if any of us proposes an extension, which happens about once or twice a year. That's not work. I don't know where you get your "work" done, but it's not here, not before any rants, not a year ago, not two years ago, and not now. But this isn't about "getting work done", you've got your channels to do that. This is about transparency, not work. And transparency, quite frankly, is abysmal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu Aug 23 15:23:24 2012 From: bja...@ (Benoit Jacob) Date: Thu, 23 Aug 2012 15:23:24 -0700 (PDT) Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: Message-ID: <2138308229.3294731.1345760604475.JavaMail.root@mozilla.com> ----- Original Message ----- > On Thu, Aug 23, 2012 at 11:42 PM, Benoit Jacob < bjacob...@ > > wrote: > > But right now is a difficult time to argue for that: after the > > rants > > posted on this list and on public-fx over the past few days, it is > > harder than usual to argue for public mailing lists as places for > > getting work done. > > There's no work done here in the first place, at all. Zip, zilch, > nada. We have colorful exchanges and throw around ideas, but far as > "work" goes, the height is if any of us proposes an extension, which > happens about once or twice a year. That's not work. I don't know > where you get your "work" done, but it's not here, not before any > rants, not a year ago, not two years ago, and not now. > But this isn't about "getting work done", you've got your channels to > do that. This is about transparency, not work. And transparency, > quite frankly, is abysmal. A look at the archives of this mailing list will show you that work does get done here. https://www.khronos.org/webgl/public-mailing-list/archives/1206/ https://www.khronos.org/webgl/public-mailing-list/archives/1207/ https://www.khronos.org/webgl/public-mailing-list/archives/1208/ I don't know where you got the opposite impression from. This public_webgl mailing list is the central communication channel of this Working Group. Earlier this year, on the private list, we agreed on an informal rule that we should use it except when we have a specific reason to use a private channel, and that even then, any private spec decision must at least be reported on public_webgl. I believe that the above public archive links show that we have done a reasonably good job at that. You are always welcome to point out any specific decision for which you believe that no appropriate public discussion, or explanation for private-ness, happened on this list. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Aug 23 15:27:26 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Thu, 23 Aug 2012 15:27:26 -0700 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: The private WebGL list is rarely used at this point. About the only thing that gets discussed there is security issues and driver bugs that we'd rather not make public until they're fixed or worked around On Thu, Aug 23, 2012 at 2:56 PM, Florian B?sch wrote: > On Thu, Aug 23, 2012 at 11:42 PM, Benoit Jacob wrote: > >> But right now is a difficult time to argue for that: after the rants >> posted on this list and on public-fx over the past few days, it is harder >> than usual to argue for public mailing lists as places for getting work >> done. > > There's no work done here in the first place, at all. Zip, zilch, nada. We > have colorful exchanges and throw around ideas, but far as "work" goes, the > height is if any of us proposes an extension, which happens about once or > twice a year. That's not work. I don't know where you get your "work" done, > but it's not here, not before any rants, not a year ago, not two years ago, > and not now. > > But this isn't about "getting work done", you've got your channels to do > that. This is about transparency, not work. And transparency, quite > frankly, is abysmal. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Aug 23 15:36:27 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Aug 2012 00:36:27 +0200 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: <2138308229.3294731.1345760604475.JavaMail.root@mozilla.com> References: <2138308229.3294731.1345760604475.JavaMail.root@mozilla.com> Message-ID: On Fri, Aug 24, 2012 at 12:23 AM, Benoit Jacob wrote: > You are always welcome to point out any specific decision for which you > believe that no appropriate public discussion, or explanation for > private-ness, happened on this list. > - WebGL 2.0 - WebGL on iOS - WebGL on android builtin chrome - MRT extension - VAO extension - depth texture extension - uint32 indices Those are topics which I find "unsatisfactorily" either communicated or resolved (or lack thereof). I've been in these discussions and some of the stuff was shut down as "convenience", others was announced as "nothing to announce at this time" and still others just seems to have run into sand somewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Aug 23 15:46:14 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Thu, 23 Aug 2012 15:46:14 -0700 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: References: <2138308229.3294731.1345760604475.JavaMail.root@mozilla.com> Message-ID: On Thu, Aug 23, 2012 at 3:36 PM, Florian B?sch wrote: > On Fri, Aug 24, 2012 at 12:23 AM, Benoit Jacob wrote: > >> You are always welcome to point out any specific decision for which you >> believe that no appropriate public discussion, or explanation for >> private-ness, happened on this list. >> > - WebGL 2.0 > There's been no discussion > - WebGL on iOS > This is up to Apple. There is no reason I can fathom that they should be forced to make their plans public. Of course I'd like to know. I'd also like to know what features will be in iPhone5 or when a Retina Display Air will ship but I don't expect Apple will share that info > - WebGL on android builtin chrome > Same as above. I'd like to know as well but even though I work at Google I don't know what the plans are > - MRT extension > No discussion has happened off the public list > - VAO extension > No discussion has happened off the public list. Thought I did see some public patches go by on the webkit project recently > - depth texture extension > No discussion has happened off the public list. This is shipping in Chrome BTW > - uint32 indices > No discussions has happened off the public list. > > Those are topics which I find "unsatisfactorily" either communicated or > resolved (or lack thereof). I've been in these discussions and some of the > stuff was shut down as "convenience", others was announced as "nothing to > announce at this time" and still others just seems to have run into sand > somewhere. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu Aug 23 15:47:35 2012 From: bja...@ (Benoit Jacob) Date: Thu, 23 Aug 2012 15:47:35 -0700 (PDT) Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: Message-ID: <1884883218.3298886.1345762055078.JavaMail.root@mozilla.com> ----- Original Message ----- > On Fri, Aug 24, 2012 at 12:23 AM, Benoit Jacob < bjacob...@ > > wrote: > > You are always welcome to point out any specific decision for which > > you believe that no appropriate public discussion, or explanation > > for private-ness, happened on this list. > > - WebGL 2.0 Has not been discussed recently on private WebGL channels, aside from agreeing that we'd want to start work on it soon. > - WebGL on iOS > - WebGL on android builtin chrome > - MRT extension > - VAO extension > - depth texture extension > - uint32 indices Nor have any of these been discussed recenty on private WebGL channels, as far as I recall. (Some have been alluded to, but not in any noteworthy kind of way). Please, just because something is interesting and is not discussed publicly, does not imply that it has been discussed privately. Benoit > Those are topics which I find "unsatisfactorily" either communicated > or resolved (or lack thereof). I've been in these discussions and > some of the stuff was shut down as "convenience", others was > announced as "nothing to announce at this time" and still others > just seems to have run into sand somewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Aug 23 16:21:44 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Aug 2012 01:21:44 +0200 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: On Fri, Aug 24, 2012 at 12:58 AM, Marco Di Benedetto wrote: > Above all, on my mind it is the long requests for multiple render > targets: ignoring all the complains was not a great move. > I think we have a proposal for this on which Gregg did a bang up job to iron it out the issues between desktop and ES. https://github.com/KhronosGroup/WebGL/blob/master/extensions/proposals/WEBGL_fbo_color_attachments/extension.xml It's a topic for another thread what happens to this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Aug 23 18:15:00 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Thu, 23 Aug 2012 18:15:00 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> Message-ID: So I've been taking a look at getting something working. My first thought was doing a kind of auto sync. If you bind a resource and it has been modified by a different context since you last modified it I'd do a glFinish or glFlush/glWaitSync If you try to use a resource and it's been modified by another context and you haven't bound it since then you'd get INVALID_OPERATION I was hoping that would be the simplest way to make it work but unfortunately, to get that to work across workers requires too much locking. Every function that touches a shared resource has to lock the resource the entire time it's dealing with it. So, that suggests the acquire/release method is probably a better way to go. Then locks are only needed during acquire and release. I'd still track modifications and generate INVALID_OPERATION if you haven't bound the resources in your context if has been modified by another context. Similarly I can auto insert the appropriate glFinish or glFlush/glWaitSync or similar synchronization. Some questions come up about acquireResource though. How should it fail (gl ERROR? Exception?) Should it fail at all, maybe it should be async as in gl.acquireResource(resource, flags, *callback*); You then have the issue though of multiple callbacks, on multiple threads (workers and the main thread). It's one of those things that seems like I need to implement it before I know if it sucks or not but I suppose we can write some pseudo code. --main-page-- gl = canvas.getContext("webgl"); // make a texture to share. texture = gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, texture); gl.texImage2D(gl.TEXTURE_2D, ....., width, height); worker = new Worker("renderscene.js"); // Write a dispatch function for messages received from the worker. worker.onmessage = function(oEvent) { switch (oEvent.data.cmd) { case 'initialized': requestFrame(); case 'rendered': render(); } }; // Tell the worker to startup. Give it our shared // texture and the shareGroup. worker.postMessage({ cmd: 'start', data: { texture:texture, shareGroup: gl.getContextAttributes().shareGrouo } }); // Ask the worker to render a frame. function requestFrame() { worker.postMessage({cmd: 'render'}); } // Called by the worker when a frame is ready. function render() // Draw to canvas with texture that worker rendered to gl.acquireResource(texture, gl.READ_ONLY); // must bind to see the changes. gl.bindTexture(gl.TEXTURE_2D, texture); gl.useProgram(drawQuadProgram); gl.drawArrays(gl.TRIANGLES, 0, 4); gl.releaseResource(texture); // Request a new frame using RAF. requestAnimationFrame(requestFrame); } --renderscene.js-- self.onmessage = function (oEvent) { switch (oEvent.data.cmd) { case 'start': init(oEvent.data.data); break; case 'render': render(oEvent.data.data); break; } }; function init(data) { gl = createWebGLContextInWorkerMagic({ shareGroup: data.shareGroup; }); texture = data.texture; // Even though framebufferTexture2D does not modify or read // the texture to make sure it's not deleted when we try // to attach it to or our FBO we need to acquire it. gl.acquireResource(texture, gl.READ_ONLY); // Make an FBO to use the texture. fbo = gl.createFramebuffer(); gl.bindFramebuffer(gl.FRAMEBUFFER, fbo); gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.TEXTURE_2D, texture, 0); gl.releaseResource(texture); // Load all our scene data. ... self.postMessage({cmd: "initialized"}); }; function render(data) { gl.acquireResource(texture, gl.WRITE); // This is not needed if we never write to this texture from // the main thread. gl.bindTexture(gl.TEXTURE_2D, texture); renderSceneToTextureThoughFBO(fbo); gl.releaseResource(texture); self.postMessage({cmd: "rendered"}); }; Note: I'm not saying the code above is how you'd actually write this. At a minimum you'd probably want to double buffer 'texture' and figure out a more performant way of getting parallelization. But, after writing this it seems like a non-async acquireResource that throws an exception if it can't acquire would be best? It would be easiest to use and you'd get an error immediately if you make a mistake. One interesting question this brings up is when do you need to start using acquireResource/releaseResource. Meaning, right now, with 1 context you don't need to call it at all. It almost seems like we'd need a 'shareResource(resource)' function to mark those resources that are shared and therefore require calling acquireResource before being used vs those resources that don't. And if you don't call shareResource on an object you'd get an error if you tried to use it in another context. Thoughts? I'm thinking out loud here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Aug 23 18:18:58 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Thu, 23 Aug 2012 18:18:58 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> Message-ID: Actually, hmmm, I take this back. It sounds like workers require a different solution than 2+ contexts in the same page. Ideally, if you have 2 contexts in the same page you shouldn't have to call acquire/release at all. Otherwise, the simple case of a 3D editor with multiple views, each view having a different canvas, would really suck as you'd have to acquire/release hundreds of resources. Well, more food for thought. On Thu, Aug 23, 2012 at 6:15 PM, Gregg Tavares (??) wrote: > So I've been taking a look at getting something working. My first thought > was doing a kind of auto sync. > > If you bind a resource and it has been modified by a different context > since you last modified it I'd do a glFinish or glFlush/glWaitSync > If you try to use a resource and it's been modified by another context and > you haven't bound it since then you'd get INVALID_OPERATION > > I was hoping that would be the simplest way to make it work but > unfortunately, to get that to work across workers requires too much > locking. Every function that touches a shared resource has to lock the > resource the entire time it's dealing with it. > > So, that suggests the acquire/release method is probably a better way to > go. Then locks are only needed during acquire and release. I'd still track > modifications and generate INVALID_OPERATION if you haven't bound the > resources in your context if has been modified by another context. > Similarly I can auto insert the appropriate glFinish or glFlush/glWaitSync > or similar synchronization. > > Some questions come up about acquireResource though. > > How should it fail (gl ERROR? Exception?) > Should it fail at all, maybe it should be async as in > gl.acquireResource(resource, flags, *callback*); > > You then have the issue though of multiple callbacks, on multiple threads > (workers and the main thread). > > It's one of those things that seems like I need to implement it before I > know if it sucks or not but I suppose we can write some pseudo code. > > --main-page-- > gl = canvas.getContext("webgl"); > > // make a texture to share. > texture = gl.createTexture(); > gl.bindTexture(gl.TEXTURE_2D, texture); > gl.texImage2D(gl.TEXTURE_2D, ....., width, height); > > worker = new Worker("renderscene.js"); > > // Write a dispatch function for messages received from the worker. > worker.onmessage = function(oEvent) { > switch (oEvent.data.cmd) { > case 'initialized': > requestFrame(); > case 'rendered': > render(); > } > }; > > // Tell the worker to startup. Give it our shared > // texture and the shareGroup. > worker.postMessage({ > cmd: 'start', > data: { > texture:texture, > shareGroup: gl.getContextAttributes().shareGrouo > } > }); > > // Ask the worker to render a frame. > function requestFrame() { > worker.postMessage({cmd: 'render'}); > } > > // Called by the worker when a frame is ready. > function render() > // Draw to canvas with texture that worker rendered to > gl.acquireResource(texture, gl.READ_ONLY); > > // must bind to see the changes. > gl.bindTexture(gl.TEXTURE_2D, texture); > > gl.useProgram(drawQuadProgram); > gl.drawArrays(gl.TRIANGLES, 0, 4); > > gl.releaseResource(texture); > > // Request a new frame using RAF. > requestAnimationFrame(requestFrame); > } > > --renderscene.js-- > > self.onmessage = function (oEvent) { > switch (oEvent.data.cmd) { > case 'start': > init(oEvent.data.data); > break; > case 'render': > render(oEvent.data.data); > break; > } > }; > > function init(data) { > gl = createWebGLContextInWorkerMagic({ > shareGroup: data.shareGroup; > }); > > texture = data.texture; > > // Even though framebufferTexture2D does not modify or read > // the texture to make sure it's not deleted when we try > // to attach it to or our FBO we need to acquire it. > gl.acquireResource(texture, gl.READ_ONLY); > > // Make an FBO to use the texture. > fbo = gl.createFramebuffer(); > gl.bindFramebuffer(gl.FRAMEBUFFER, fbo); > gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.TEXTURE_2D, texture, 0); > > gl.releaseResource(texture); > > // Load all our scene data. > ... > > self.postMessage({cmd: "initialized"}); > }; > > function render(data) { > gl.acquireResource(texture, gl.WRITE); > > // This is not needed if we never write to this texture from > // the main thread. > gl.bindTexture(gl.TEXTURE_2D, texture); > > renderSceneToTextureThoughFBO(fbo); > > gl.releaseResource(texture); > > self.postMessage({cmd: "rendered"}); > }; > > Note: I'm not saying the code above is how you'd actually write this. At a > minimum you'd probably want to double buffer 'texture' and figure out a > more performant way of getting parallelization. > > But, after writing this it seems like a non-async acquireResource that > throws an exception if it can't acquire would be best? It would be easiest > to use and you'd get an error immediately if you make a mistake. > > One interesting question this brings up is when do you need to start using > acquireResource/releaseResource. Meaning, right now, with 1 context you > don't need to call it at all. It almost seems like we'd need a > 'shareResource(resource)' function to mark those resources that are shared > and therefore require calling acquireResource before being used vs those > resources that don't. And if you don't call shareResource on an object > you'd get an error if you tried to use it in another context. > > Thoughts? I'm thinking out loud here. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Aug 23 19:11:28 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 23 Aug 2012 19:11:28 -0700 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: On Thu, Aug 23, 2012 at 4:21 PM, Florian B?sch wrote: > On Fri, Aug 24, 2012 at 12:58 AM, Marco Di Benedetto > wrote: >> >> Above all, on my mind it is the long requests for multiple render >> targets: ignoring all the complains was not a great move. > > I think we have a proposal for this on which Gregg did a bang up job to iron > it out the issues between desktop and ES. > https://github.com/KhronosGroup/WebGL/blob/master/extensions/proposals/WEBGL_fbo_color_attachments/extension.xml > > It's a topic for another thread what happens to this. Now that OpenGL ES 3.0 is out, it can be said publicly that the reason for deferring work on this WebGL extension was to avoid introducing behavior that would be incompatible with OpenGL ES 3.0. If someone would like to revise that extension to pull its language *and semantics* from the OpenGL ES 3.0 specification, that would be great. However, I am personally in favor of moving in the direction of upgrading the WebGL specification to incorporate all of the OpenGL ES 3.0 functionality, not just this part. There are a lot of new capabilities in ES 3.0 and I imagine that they all have subtle interactions, so adding them as individual extensions to WebGL would be more work than it's worth. I've personally been too swamped recently to initiate email threads on public_webgl regarding the status of the WebGL 1.0.1 spec snapshot and passing of the 1.0.1 conformance suite, but any of the other WG members (Benoit, for example) should feel free to discuss the current state of things. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From toj...@ Thu Aug 23 20:56:12 2012 From: toj...@ (Brandon Jones) Date: Thu, 23 Aug 2012 20:56:12 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> Message-ID: I agree that when dealing with two contexts on the same page it feels incredibly cumbersome to always be acquiring and releasing resources. I'm not sure what it would take to make that happen cleanly on the backend. In any case, I personally find the worker scenario more interesting/useful so I'll focus on that. Since we're in a worker that is most likely explicitly created for the purposes of managing these shared resources having a callback-centric API feels like overkill. I'd rather have it be a blocking call, since it lends to cleaner code and less garbage creation. As a blocking call I imagine it would return a success/fail code of some sort (boolean is probably sufficient), which the user can detect and query gl.getError for more information (did it timeout, is the resource invalid, etc?) So your worker code from above now looks like this: function render(data) { if(!gl.acquireResource(texture, gl.WRITE)) { // Query error info and do something with it self.postMessage({cmd: "Failed"}); return; } gl.bindTexture(gl.TEXTURE_2D, texture); // And so on... }; That does feel slightly non-GL-ish to me, however. A more natural feeling API would be one where acquireResource actually returns the resource in question on success or null on failure, allowing it to mimic the behavior of createTexture/createBuffer/createFramebuffer/etc. This has the nice side effect of unhandled errors producing behavior that is already well defined. (We all know what gl.bindTexture(gl.TEXTURE_2D, null) should do.) Of course, for such an API to make sense the data passed between workers would no longer be the resource itself but instead some sort of shared resource id. That could play nicely into your concept of explicitly flagging shared resources, however: //-- Main Thread -- function requestFrame() { var textureShareId = gl.shareResource(texture); worker.postMessage({cmd: 'render', resourceId: textureShareId}); } //-- Worker -- function render(data) { texture = gl.acquireResource(data.resourceId, gl.WRITE); // Obviously I can check for null and query gl.getError here if I care... gl.bindTexture(gl.TEXTURE_2D, texture); // And so on... }; Now you are required to flag resources as shared in order to expose them (good for internal optimization) to other workers, and the API on the other end has more familiar behavior. Just a thought! --Brandon On Thu, Aug 23, 2012 at 6:18 PM, Gregg Tavares (??) wrote: > Actually, hmmm, I take this back. > > It sounds like workers require a different solution than 2+ contexts in > the same page. Ideally, if you have 2 contexts in the same page you > shouldn't have to call acquire/release at all. Otherwise, the simple case > of a 3D editor with multiple views, each view having a different canvas, > would really suck as you'd have to acquire/release hundreds of resources. > > Well, more food for thought. > > > On Thu, Aug 23, 2012 at 6:15 PM, Gregg Tavares (??) wrote: > >> So I've been taking a look at getting something working. My first thought >> was doing a kind of auto sync. >> >> If you bind a resource and it has been modified by a different context >> since you last modified it I'd do a glFinish or glFlush/glWaitSync >> If you try to use a resource and it's been modified by another context >> and you haven't bound it since then you'd get INVALID_OPERATION >> >> I was hoping that would be the simplest way to make it work but >> unfortunately, to get that to work across workers requires too much >> locking. Every function that touches a shared resource has to lock the >> resource the entire time it's dealing with it. >> >> So, that suggests the acquire/release method is probably a better way to >> go. Then locks are only needed during acquire and release. I'd still track >> modifications and generate INVALID_OPERATION if you haven't bound the >> resources in your context if has been modified by another context. >> Similarly I can auto insert the appropriate glFinish or glFlush/glWaitSync >> or similar synchronization. >> >> Some questions come up about acquireResource though. >> >> How should it fail (gl ERROR? Exception?) >> Should it fail at all, maybe it should be async as in >> gl.acquireResource(resource, flags, *callback*); >> >> You then have the issue though of multiple callbacks, on multiple threads >> (workers and the main thread). >> >> It's one of those things that seems like I need to implement it before I >> know if it sucks or not but I suppose we can write some pseudo code. >> >> --main-page-- >> gl = canvas.getContext("webgl"); >> >> // make a texture to share. >> texture = gl.createTexture(); >> gl.bindTexture(gl.TEXTURE_2D, texture); >> gl.texImage2D(gl.TEXTURE_2D, ....., width, height); >> >> worker = new Worker("renderscene.js"); >> >> // Write a dispatch function for messages received from the worker. >> worker.onmessage = function(oEvent) { >> switch (oEvent.data.cmd) { >> case 'initialized': >> requestFrame(); >> case 'rendered': >> render(); >> } >> }; >> >> // Tell the worker to startup. Give it our shared >> // texture and the shareGroup. >> worker.postMessage({ >> cmd: 'start', >> data: { >> texture:texture, >> shareGroup: gl.getContextAttributes().shareGrouo >> } >> }); >> >> // Ask the worker to render a frame. >> function requestFrame() { >> worker.postMessage({cmd: 'render'}); >> } >> >> // Called by the worker when a frame is ready. >> function render() >> // Draw to canvas with texture that worker rendered to >> gl.acquireResource(texture, gl.READ_ONLY); >> >> // must bind to see the changes. >> gl.bindTexture(gl.TEXTURE_2D, texture); >> >> gl.useProgram(drawQuadProgram); >> gl.drawArrays(gl.TRIANGLES, 0, 4); >> >> gl.releaseResource(texture); >> >> // Request a new frame using RAF. >> requestAnimationFrame(requestFrame); >> } >> >> --renderscene.js-- >> >> self.onmessage = function (oEvent) { >> switch (oEvent.data.cmd) { >> case 'start': >> init(oEvent.data.data); >> break; >> case 'render': >> render(oEvent.data.data); >> break; >> } >> }; >> >> function init(data) { >> gl = createWebGLContextInWorkerMagic({ >> shareGroup: data.shareGroup; >> }); >> >> texture = data.texture; >> >> // Even though framebufferTexture2D does not modify or read >> // the texture to make sure it's not deleted when we try >> // to attach it to or our FBO we need to acquire it. >> gl.acquireResource(texture, gl.READ_ONLY); >> >> // Make an FBO to use the texture. >> fbo = gl.createFramebuffer(); >> gl.bindFramebuffer(gl.FRAMEBUFFER, fbo); >> gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.TEXTURE_2D, texture, 0); >> >> gl.releaseResource(texture); >> >> // Load all our scene data. >> ... >> >> self.postMessage({cmd: "initialized"}); >> }; >> >> function render(data) { >> gl.acquireResource(texture, gl.WRITE); >> >> // This is not needed if we never write to this texture from >> // the main thread. >> gl.bindTexture(gl.TEXTURE_2D, texture); >> >> renderSceneToTextureThoughFBO(fbo); >> >> gl.releaseResource(texture); >> >> self.postMessage({cmd: "rendered"}); >> }; >> >> Note: I'm not saying the code above is how you'd actually write this. At >> a minimum you'd probably want to double buffer 'texture' and figure out a >> more performant way of getting parallelization. >> >> But, after writing this it seems like a non-async acquireResource that >> throws an exception if it can't acquire would be best? It would be easiest >> to use and you'd get an error immediately if you make a mistake. >> >> One interesting question this brings up is when do you need to start >> using acquireResource/releaseResource. Meaning, right now, with 1 context >> you don't need to call it at all. It almost seems like we'd need a >> 'shareResource(resource)' function to mark those resources that are shared >> and therefore require calling acquireResource before being used vs those >> resources that don't. And if you don't call shareResource on an object >> you'd get an error if you tried to use it in another context. >> >> Thoughts? I'm thinking out loud here. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 24 00:40:54 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Aug 2012 09:40:54 +0200 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> Message-ID: On Fri, Aug 24, 2012 at 3:18 AM, Gregg Tavares (??) wrote: > Actually, hmmm, I take this back. > > It sounds like workers require a different solution than 2+ contexts in > the same page. Ideally, if you have 2 contexts in the same page you > shouldn't have to call acquire/release at all. Otherwise, the simple case > of a 3D editor with multiple views, each view having a different canvas, > would really suck as you'd have to acquire/release hundreds of resources. > > Well, more food for thought. > The worker<->mainthread interaction is an interesting usecase. But I agree that a complicated synchronization pattern would make multi-view coding very hard. I think that maybe we should come up with two separate solutions to do each: - worker<->mainthread API/interaction - multi-view compositing where a "canvas" is just a proxy stand in for an RTT target that the compositor picks up to paste into the page and the user is responsible for filling the attached/associated texture upon animation frame callback. That could be solved elegantly by specifying that you can pass a canvas as color attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From car...@ Fri Aug 24 08:18:04 2012 From: car...@ (Carlos Scheidegger) Date: Fri, 24 Aug 2012 11:18:04 -0400 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> Message-ID: <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> AM, Florian B?sch wrote: > On Fri, Aug 24, 2012 at 3:18 AM, Gregg Tavares (??) wrote: > Actually, hmmm, I take this back. > > It sounds like workers require a different solution than 2+ contexts in the same page. Ideally, if you have 2 contexts in the same page you shouldn't have to call acquire/release at all. Otherwise, the simple case of a 3D editor with multiple views, each view having a different canvas, would really suck as you'd have to acquire/release hundreds of resources. > > Well, more food for thought. > The worker<->mainthread interaction is an interesting usecase. But I agree that a complicated synchronization pattern would make multi-view coding very hard. I think that maybe we should come up with two separate solutions to do each: > - worker<->mainthread API/interaction > - multi-view compositing where a "canvas" is just a proxy stand in for an RTT target that the compositor picks up to paste into the page and the user is responsible for filling the attached/associated texture upon animation frame callback. That could be solved elegantly by specifying that you can pass a canvas as color attachment. Speaking as someone who's developing an application where an arbitrary large number of WebGL canvas could be created, I want to strongly support this second suggestion. How hard would it be to somehow specify that a "detached" WebGL context can be created, one for which drawing calls with a null framebuffer always fail? Then, gl.bindFramebufer(gl.FRAMEBUFFER, framebuffer_with_attached_canvas) would behave like Florian described. The only change I would suggest is that instead of overloading framebufferTexture2D, the elegant solution would be to add a framebufferCanvas entry point. This way, it would be possible to eliminate the confusion that would arise from having to pass a texture target. One possible minimal entry point would be something like void framebufferCanvas(GLenum target, HTMLCanvasElement element) This would make it clear that none of the possible parameters in framebufferTexture2D (texture target, attachments, and mipmap levels) are applicable for canvas targets. This call should behave roughly equivalently to creating a plain RTT texture with the right size and attach it to COLOR_ATTACHMENT0. This is a big change for the spec, so I understand if it would be non-trivial to get right. But it would be absolutely fantastic if you do get it right. I routinely use ~100MB attribute buffers, and guaranteeing that different canvas elements share those attribute buffers would be a huge win. -carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Aug 24 10:04:34 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 24 Aug 2012 10:04:34 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: Vladimir above mentioned the case of rendering to a canvas from a worker. I think we should look at their proposal once they make it public. But that specific use case is orthogonal to the issues of shared resources among multiple canvases and shared resources with workers. So, back to the shared resources issues. Others have suggested passing the objects. So, worker.postMessage({ texture: someTexture, }); would pass ownership of the WebGLTexture referenced by 'someTexture' to the worker. At that point using 'someTexture' in the main page would start generating INVALID_OPERATION just like a WebGLTexture created in another context does now. That sounds simpler. Basically you dont' have to designate which objects are shared. You can just only use them in one thread (main or worker) at a time. On Fri, Aug 24, 2012 at 8:18 AM, Carlos Scheidegger < carlos.scheidegger...@> wrote: > AM, Florian B?sch wrote: > > On Fri, Aug 24, 2012 at 3:18 AM, Gregg Tavares (??) wrote: > >> Actually, hmmm, I take this back. >> >> It sounds like workers require a different solution than 2+ contexts in >> the same page. Ideally, if you have 2 contexts in the same page you >> shouldn't have to call acquire/release at all. Otherwise, the simple case >> of a 3D editor with multiple views, each view having a different canvas, >> would really suck as you'd have to acquire/release hundreds of resources. >> >> Well, more food for thought. >> > The worker<->mainthread interaction is an interesting usecase. But I agree > that a complicated synchronization pattern would make multi-view coding > very hard. I think that maybe we should come up with two separate solutions > to do each: > - worker<->mainthread API/interaction > - multi-view compositing where a "canvas" is just a proxy stand in for an > RTT target that the compositor picks up to paste into the page and the user > is responsible for filling the attached/associated texture upon animation > frame callback. That could be solved elegantly by specifying that you can > pass a canvas as color attachment. > > > Speaking as someone who's developing an application where an arbitrary > large number of WebGL canvas could be created, I want to strongly support > this second suggestion. > > How hard would it be to somehow specify that a "detached" WebGL context > can be created, one for which drawing calls with a null framebuffer always > fail? Then, gl.bindFramebufer(gl.FRAMEBUFFER, > framebuffer_with_attached_canvas) would behave like Florian described. > > The only change I would suggest is that instead of overloading > framebufferTexture2D, the elegant solution would be to add a > framebufferCanvas entry point. This way, it would be possible to eliminate > the confusion that would arise from having to pass a texture target. > > One possible minimal entry point would be something like > > void framebufferCanvas(GLenum target, HTMLCanvasElement element) > > This would make it clear that none of the possible parameters in > framebufferTexture2D (texture target, attachments, and mipmap levels) are > applicable for canvas targets. This call should behave roughly equivalently > to creating a plain RTT texture with the right size and attach it to > COLOR_ATTACHMENT0. > > This is a big change for the spec, so I understand if it would be > non-trivial to get right. But it would be absolutely fantastic if you do > get it right. I routinely use ~100MB attribute buffers, and guaranteeing > that different canvas elements share those attribute buffers would be a > huge win. > > -carlos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Aug 24 10:10:08 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 24 Aug 2012 10:10:08 -0700 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: There's a lot of work involved in designing WebGL2.0 based off ES 3.0. On top of that, many of the features of ES 3.0 are not available on mobile at this point in time. On the other hand, MRT is available in most places and it's a much smaller issue to tackle and seems more likely to get done. Of all the ES 3.0 features, I feel like it would be best to add MRT as an extension asap rather than wait for us to figure out all of ES 3.0 before we can get any of its functionality exposed. On Thu, Aug 23, 2012 at 7:11 PM, Kenneth Russell wrote: > > On Thu, Aug 23, 2012 at 4:21 PM, Florian B?sch wrote: > > On Fri, Aug 24, 2012 at 12:58 AM, Marco Di Benedetto > > > wrote: > >> > >> Above all, on my mind it is the long requests for multiple render > >> targets: ignoring all the complains was not a great move. > > > > I think we have a proposal for this on which Gregg did a bang up job to > iron > > it out the issues between desktop and ES. > > > https://github.com/KhronosGroup/WebGL/blob/master/extensions/proposals/WEBGL_fbo_color_attachments/extension.xml > > > > It's a topic for another thread what happens to this. > > Now that OpenGL ES 3.0 is out, it can be said publicly that the reason > for deferring work on this WebGL extension was to avoid introducing > behavior that would be incompatible with OpenGL ES 3.0. > > If someone would like to revise that extension to pull its language > *and semantics* from the OpenGL ES 3.0 specification, that would be > great. > > However, I am personally in favor of moving in the direction of > upgrading the WebGL specification to incorporate all of the OpenGL ES > 3.0 functionality, not just this part. There are a lot of new > capabilities in ES 3.0 and I imagine that they all have subtle > interactions, so adding them as individual extensions to WebGL would > be more work than it's worth. > > I've personally been too swamped recently to initiate email threads on > public_webgl regarding the status of the WebGL 1.0.1 spec snapshot and > passing of the 1.0.1 conformance suite, but any of the other WG > members (Benoit, for example) should feel free to discuss the current > state of things. > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Aug 24 10:19:24 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Aug 2012 10:19:24 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: That works for some scenarios, but having the ability to share read-only resources is also important - for example, virtual texturing, gpgpu physics simulations/particle systems, tiled gpu raytracing, etc all require the ability to share textures/buffers across multiple threads. Otherwise, each thread must load/upload/consume the GPU memory for shared resources, which is *really* bad. That's why I mentioned the potential for acquire-for-read vs acquire-for-write semantics before. Transferring resources would be fine for ping-ponging textures for readback/etc, but wouldn't solve many of these other cases. On Fri, Aug 24, 2012 at 10:04 AM, Gregg Tavares (??) wrote: > Vladimir above mentioned the case of rendering to a canvas from a worker. > I think we should look at their proposal once they make it public. But that > specific use case is orthogonal to the issues of shared resources among > multiple canvases and shared resources with workers. > > So, back to the shared resources issues. Others have suggested passing the > objects. So, > > worker.postMessage({ > texture: someTexture, > }); > > would pass ownership of the WebGLTexture referenced by 'someTexture' to > the worker. At that point using 'someTexture' in the main page would start > generating INVALID_OPERATION just like a WebGLTexture created in another > context does now. > > That sounds simpler. Basically you dont' have to designate which objects > are shared. You can just only use them in one thread (main or worker) at a > time. > > > > > On Fri, Aug 24, 2012 at 8:18 AM, Carlos Scheidegger < > carlos.scheidegger...@> wrote: > >> AM, Florian B?sch wrote: >> >> On Fri, Aug 24, 2012 at 3:18 AM, Gregg Tavares (??) wrote: >> >>> Actually, hmmm, I take this back. >>> >>> It sounds like workers require a different solution than 2+ contexts in >>> the same page. Ideally, if you have 2 contexts in the same page you >>> shouldn't have to call acquire/release at all. Otherwise, the simple case >>> of a 3D editor with multiple views, each view having a different canvas, >>> would really suck as you'd have to acquire/release hundreds of resources. >>> >>> Well, more food for thought. >>> >> The worker<->mainthread interaction is an interesting usecase. But I >> agree that a complicated synchronization pattern would make multi-view >> coding very hard. I think that maybe we should come up with two separate >> solutions to do each: >> - worker<->mainthread API/interaction >> - multi-view compositing where a "canvas" is just a proxy stand in for an >> RTT target that the compositor picks up to paste into the page and the user >> is responsible for filling the attached/associated texture upon animation >> frame callback. That could be solved elegantly by specifying that you can >> pass a canvas as color attachment. >> >> >> Speaking as someone who's developing an application where an arbitrary >> large number of WebGL canvas could be created, I want to strongly support >> this second suggestion. >> >> How hard would it be to somehow specify that a "detached" WebGL context >> can be created, one for which drawing calls with a null framebuffer always >> fail? Then, gl.bindFramebufer(gl.FRAMEBUFFER, >> framebuffer_with_attached_canvas) would behave like Florian described. >> >> The only change I would suggest is that instead of overloading >> framebufferTexture2D, the elegant solution would be to add a >> framebufferCanvas entry point. This way, it would be possible to eliminate >> the confusion that would arise from having to pass a texture target. >> >> One possible minimal entry point would be something like >> >> void framebufferCanvas(GLenum target, HTMLCanvasElement element) >> >> This would make it clear that none of the possible parameters in >> framebufferTexture2D (texture target, attachments, and mipmap levels) are >> applicable for canvas targets. This call should behave roughly equivalently >> to creating a plain RTT texture with the right size and attach it to >> COLOR_ATTACHMENT0. >> >> This is a big change for the spec, so I understand if it would be >> non-trivial to get right. But it would be absolutely fantastic if you do >> get it right. I routinely use ~100MB attribute buffers, and guaranteeing >> that different canvas elements share those attribute buffers would be a >> huge win. >> >> -carlos >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 24 10:30:50 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Aug 2012 19:30:50 +0200 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: On Fri, Aug 24, 2012 at 7:04 PM, Gregg Tavares (??) wrote: > Vladimir above mentioned the case of rendering to a canvas from a worker. > I think we should look at their proposal once they make it public. But that > specific use case is orthogonal to the issues of shared resources among > multiple canvases and shared resources with workers. > > So, back to the shared resources issues. Others have suggested passing the > objects. So, > > worker.postMessage({ > texture: someTexture, > }); > > would pass ownership of the WebGLTexture referenced by 'someTexture' to > the worker. At that point using 'someTexture' in the main page would start > generating INVALID_OPERATION just like a WebGLTexture created in another > context does now. > > That sounds simpler. Basically you dont' have to designate which objects > are shared. You can just only use them in one thread (main or worker) at a > time. > I think the "shared resources between canvasii" idea is superfluos. The only reason you want a second canvas is in order to display something. If you just want to display something, you can take all the complexity entirely out of that so you don't have to mangle it together with cross thread/process sharing and just do that, display something. We already know how to make off-screen rendering with FBOs. The compositor already uses textures to composit the page, and texturing is used in the compositor to avoid readbacks for hardware accelerated canvasii. In order to render a second view of our data we'd just like to be able to bind a "surface", emit our drawing commands and then be done. The canvas (singular, bound to a single context) is so far the only "front" buffer we have. But given that it's all texturing underneath, there isn't a logical reason why such an exceedingly simple idea as using as many "front" surfaces as you want bound to an FBO should be in any way be impacted by complex things like resource sharing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Aug 24 10:52:42 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 24 Aug 2012 10:52:42 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: On Fri, Aug 24, 2012 at 10:30 AM, Florian B?sch wrote: > On Fri, Aug 24, 2012 at 7:04 PM, Gregg Tavares (??) wrote: > >> Vladimir above mentioned the case of rendering to a canvas from a worker. >> I think we should look at their proposal once they make it public. But that >> specific use case is orthogonal to the issues of shared resources among >> multiple canvases and shared resources with workers. >> >> So, back to the shared resources issues. Others have suggested passing >> the objects. So, >> >> worker.postMessage({ >> texture: someTexture, >> }); >> >> would pass ownership of the WebGLTexture referenced by 'someTexture' to >> the worker. At that point using 'someTexture' in the main page would start >> generating INVALID_OPERATION just like a WebGLTexture created in another >> context does now. >> >> That sounds simpler. Basically you dont' have to designate which objects >> are shared. You can just only use them in one thread (main or worker) at a >> time. >> > I think the "shared resources between canvasii" idea is superfluos. The > only reason you want a second canvas is in order to display something. If > you just want to display something, you can take all the complexity > entirely out of that so you don't have to mangle it together with cross > thread/process sharing and just do that, display something. We already know > how to make off-screen rendering with FBOs. The compositor already uses > textures to composit the page, and texturing is used in the compositor to > avoid readbacks for hardware accelerated canvasii. In order to render a > second view of our data we'd just like to be able to bind a "surface", emit > our drawing commands and then be done. The canvas (singular, bound to a > single context) is so far the only "front" buffer we have. But given that > it's all texturing underneath, there isn't a logical reason why such an > exceedingly simple idea as using as many "front" surfaces as you want bound > to an FBO should be in any way be impacted by complex things like resource > sharing. > That's a really good idea! if you could call gl.bindFramebuffer(gl.FRAMEBUFFER, someCanvas); or similar that would mean sharing resources on the main page is not needed. You'd still arguably need a way to mark a canvas as using WebGL although maybe it could happen automagically on bind. Would this work var canvas1 = document.createElement("canvas"); var canvas2 = document.createElement("canvas"); var gl1 = canvas1.getContext("webgl"); var gl2 = canvas2.getContext("webgl"); //now both canvases are webgl canvases // swap them just for fun gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2); gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1); It seems like a little bit of a waste to have to create the second context just so the canvas is a WebGL canvas Also, ti seems like overloading the meaning of bindFramebuffer might not be the best method since there all various operations you can do to currently bound framebuffer. So maybe it should be something like gl.bindBackbuffer(canvas) or gl.bindCanvas(canvas) and then like normal, calling gl.bindFramebuffer(gl.FRAMEBUFFER,null) renders to the current backbuffer/canvas with all the limits that normally entails (can't call framebufferRenderbuffer or framebufrferTexture2D on it) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 24 11:15:23 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Aug 2012 20:15:23 +0200 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: On Fri, Aug 24, 2012 at 7:52 PM, Gregg Tavares (??) wrote: > or similar that would mean sharing resources on the main page is not > needed. > That's exactly my thinking, it would simplify the design of the resource sharing because you wouldn't have to consider main page canvasii compositing. > Would this work > > var canvas1 = document.createElement("canvas"); > var canvas2 = document.createElement("canvas"); > var gl1 = canvas1.getContext("webgl"); > var gl2 = canvas2.getContext("webgl"); > > //now both canvases are webgl canvases > > // swap them just for fun > gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2); > gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1); > > It seems like a little bit of a waste to have to create the second context > just so the canvas is a WebGL canvas > > Also, ti seems like overloading the meaning of bindFramebuffer might not > be the best method since there all various operations you can do to > currently bound framebuffer. So maybe it should be something like > > gl.bindBackbuffer(canvas) > > or > > gl.bindCanvas(canvas) > > and then like normal, calling > > gl.bindFramebuffer(gl.FRAMEBUFFER,null) > > renders to the current backbuffer/canvas with all the limits that normally > entails (can't call framebufferRenderbuffer or framebufrferTexture2D on it) > Semantically that all works for me, I find I wouldn't have a preference if we call this attaching a buffer to an FBO or binding a different frontbuffer. There's one area where the FBO semantic does have an advantage though. If you display partials (like say albedo of a scene) and then re-use the filled depth buffer to render something else (like say deferred lighting) and you have, for some reason, the desire to show both on the page (It's not contrieved, I promise, I have such an example right now, releasing it in the next few days). Since there isn't a way to attach (or even explicitly obtain) the depth buffer for use on the front, you couldn't wire your rendering together to share it. So what you'd end up doing would be to render to an FBO and then sample that FBO to blit to the canvas. It's still way better than the alternatives, just slightly inelegant (if you could do it more directly). On the other hand, if you feel the API is much cleaner with the bind frontbuffer semantic, I don't think that's a big drawback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Fri Aug 24 11:23:41 2012 From: cal...@ (Mark Callow) Date: Fri, 24 Aug 2012 11:23:41 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: <5037C6AD.30402@hicorp.co.jp> On 12/08/24 10:30, Florian B?sch wrote: > I think the "shared resources between canvasii" idea is superfluos. > The only reason you want a second canvas is in order to display > something. I agree. In particular using multiple contexts for multiple views in a 3D modeling tool is overkill, almost certainly slower than using a single context and unnecessary. For that use case we need a way bind a context to different canvas surfaces. Of course you can also do it in a single canvas by simply changing the viewport as well as the projection matrix as you render the different views. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From car...@ Fri Aug 24 11:45:25 2012 From: car...@ (Carlos Scheidegger) Date: Fri, 24 Aug 2012 14:45:25 -0400 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: <20E0B512-72BD-411C-BA14-C30AC4E4EA83@gmail.com> On Aug 24, 2012, at 1:52 PM, Gregg Tavares (??) wrote: > > > > On Fri, Aug 24, 2012 at 10:30 AM, Florian B?sch wrote: > On Fri, Aug 24, 2012 at 7:04 PM, Gregg Tavares (??) wrote: > Vladimir above mentioned the case of rendering to a canvas from a worker. I think we should look at their proposal once they make it public. But that specific use case is orthogonal to the issues of shared resources among multiple canvases and shared resources with workers. > > So, back to the shared resources issues. Others have suggested passing the objects. So, > > worker.postMessage({ > texture: someTexture, > }); > > would pass ownership of the WebGLTexture referenced by 'someTexture' to the worker. At that point using 'someTexture' in the main page would start generating INVALID_OPERATION just like a WebGLTexture created in another context does now. > > That sounds simpler. Basically you dont' have to designate which objects are shared. You can just only use them in one thread (main or worker) at a time. > I think the "shared resources between canvasii" idea is superfluos. The only reason you want a second canvas is in order to display something. If you just want to display something, you can take all the complexity entirely out of that so you don't have to mangle it together with cross thread/process sharing and just do that, display something. We already know how to make off-screen rendering with FBOs. The compositor already uses textures to composit the page, and texturing is used in the compositor to avoid readbacks for hardware accelerated canvasii. In order to render a second view of our data we'd just like to be able to bind a "surface", emit our drawing commands and then be done. The canvas (singular, bound to a single context) is so far the only "front" buffer we have. But given that it's all texturing underneath, there isn't a logical reason why such an exceedingly simple idea as using as many "front" surfaces as you want bound to an FBO should be in any way be impacted by complex things like resource sharing. > > > That's a really good idea! > > if you could call > > gl.bindFramebuffer(gl.FRAMEBUFFER, someCanvas); > > or similar that would mean sharing resources on the main page is not needed. > > You'd still arguably need a way to mark a canvas as using WebGL although maybe it could happen automagically on bind. > > Would this work > > var canvas1 = document.createElement("canvas"); > var canvas2 = document.createElement("canvas"); > var gl1 = canvas1.getContext("webgl"); > var gl2 = canvas2.getContext("webgl"); > > //now both canvases are webgl canvases > > // swap them just for fun > gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2); > gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1); > > It seems like a little bit of a waste to have to create the second context just so the canvas is a WebGL canvas > > Also, ti seems like overloading the meaning of bindFramebuffer might not be the best method since there all various operations you can do to currently bound framebuffer. So maybe it should be something like > > gl.bindBackbuffer(canvas) > > or > > gl.bindCanvas(canvas) > > and then like normal, calling > > gl.bindFramebuffer(gl.FRAMEBUFFER,null) > > renders to the current backbuffer/canvas with all the limits that normally entails (can't call framebufferRenderbuffer or framebufrferTexture2D on it) gl.bindCanvas(canvas) seems the clear winner to me. Concretely speaking, though, in that case what would have created the first webgl context? Would the first webgl context come from some specific canvas, and then it could be bound to other canvases? Out of an aesthetic preference for symmetry (why is context creation coming from one canvas element and not the other?), I think it would be more elegant to allow WebGL context creation to happen outside any canvases, and that the current var canvas1 = document.createElement("canvas"); var canvas2 = document.createElement("canvas"); var gl = canvas1.getContext("webgl") ; gl.bindCanvas(canvas2); // this line feels arbitrarily asymmetric to me would then become synonymous with ? var canvas1 = document.createElement("canvas"); var gl = document.createWebGLContext(); // or something like that gl.bindCanvas(canvas1); var canvas2 = document.createElement("canvas"); gl.bindCanvas(canvas2); Without this, I think people will end up creating hidden canvas elements just so they get a WebGL context. If you don't know exactly when a canvas will be created, you will need to check whether a context exists. This is really minor, but it would be nice to get right. I also like how this ends up feeling similar to your earlier proposal with share groups, but now the "share groups" happen automatically simply by using the methods from that context: var gl1 = document.createWebGLContext(); // everything called in gl1 is shared. var gl2 = document.createWebGLContext(); // everything called in gl2 is shared. gl1.bindCanvas(canvas1); // draw on canvas1 using resources from gl1, gl2.bindCanvas(canvas1); // draw on canvas1 using resources from gl2, gl1.bindCanvas(canvas2); // draw on canvas2 using resources from gl1, gl2.bindCanvas(canvas2); // draw on canvas2 using resources from gl2, etc. The API is really clear, and things like accidentally binding textures from one share group in another context will signal an error exactly how it happens currently. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Fri Aug 24 13:57:00 2012 From: kos...@ (David Sheets) Date: Fri, 24 Aug 2012 13:57:00 -0700 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: On Thu, Aug 23, 2012 at 2:42 PM, Benoit Jacob wrote: > I, too, would like more public-ness. > > But right now is a difficult time to argue for that: after the rants posted on this list and on public-fx over the past few days, it is harder than usual to argue for public mailing lists as places for getting work done. Benoit, Your feeding of the troll in a branch of this thread only serves to demonstrate your own inability to ignore trolls. Please, as a member of the WG, observe the topic of this thread and answer these standards-work-related questions to the best of your knowledge and ability: 1. Why is the GLSL ES WG private? 2. Why is the GLSL ES 1.0 spec so out of date? 3. Why is the GLSL ES spec source still unavailable? 4. Why is the GLSL ES shader source media type still undefined? Thank you for your cooperation, David > Benoit > > ----- Original Message ----- >> >> If Khronos members are truly interested in promulgating GLSL ES as >> the >> One True Web Shading Language for Universal Adoption: >> >> 1. Why is the GLSL ES WG private? >> 2. Why is the GLSL ES 1.0 spec so out of date? >> 3. Why is the GLSL ES spec source still unavailable? >> 4. Why is the GLSL ES shader source media type still undefined? >> >> Languages developed in secret by committees don't have a great track >> record. Developers do not appreciate unnecessary obstructions. >> >> Khronos has had significant implementation quality control problems >> with its 'conformant' member implementations. >> >> Stewardship and inclusion beat hegemony and exclusion in the Age of >> Knowledge. >> >> Your reasoned response is appreciated. >> >> Love, >> >> David W. W. Sheets >> >> P.S. Plan ahead. >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Aug 24 14:08:07 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Aug 2012 14:08:07 -0700 Subject: [Public WebGL] Universal Shading Language Governance In-Reply-To: References: <1741679592.3292727.1345758179417.JavaMail.root@mozilla.com> Message-ID: I agree that adding MRTs to the current WebGL spec is the single biggest "bang for the buck" feature that could be added. Let's resurrect the old email thread on this topic. I will take the action item to create the desired ANGLE extension based on the wording in the ES 3.0 spec. -Ken On Fri, Aug 24, 2012 at 10:10 AM, Gregg Tavares (??) wrote: > There's a lot of work involved in designing WebGL2.0 based off ES 3.0. On > top of that, many of the features of ES 3.0 are not available on mobile at > this point in time. > > On the other hand, MRT is available in most places and it's a much smaller > issue to tackle and seems more likely to get done. Of all the ES 3.0 > features, I feel like it would be best to add MRT as an extension asap > rather than wait for us to figure out all of ES 3.0 before we can get any of > its functionality exposed. > > > > > On Thu, Aug 23, 2012 at 7:11 PM, Kenneth Russell wrote: >> >> >> On Thu, Aug 23, 2012 at 4:21 PM, Florian B?sch wrote: >> > On Fri, Aug 24, 2012 at 12:58 AM, Marco Di Benedetto >> > >> > wrote: >> >> >> >> Above all, on my mind it is the long requests for multiple render >> >> targets: ignoring all the complains was not a great move. >> > >> > I think we have a proposal for this on which Gregg did a bang up job to >> > iron >> > it out the issues between desktop and ES. >> > >> > https://github.com/KhronosGroup/WebGL/blob/master/extensions/proposals/WEBGL_fbo_color_attachments/extension.xml >> > >> > It's a topic for another thread what happens to this. >> >> Now that OpenGL ES 3.0 is out, it can be said publicly that the reason >> for deferring work on this WebGL extension was to avoid introducing >> behavior that would be incompatible with OpenGL ES 3.0. >> >> If someone would like to revise that extension to pull its language >> *and semantics* from the OpenGL ES 3.0 specification, that would be >> great. >> >> However, I am personally in favor of moving in the direction of >> upgrading the WebGL specification to incorporate all of the OpenGL ES >> 3.0 functionality, not just this part. There are a lot of new >> capabilities in ES 3.0 and I imagine that they all have subtle >> interactions, so adding them as individual extensions to WebGL would >> be more work than it's worth. >> >> I've personally been too swamped recently to initiate email threads on >> public_webgl regarding the status of the WebGL 1.0.1 spec snapshot and >> passing of the 1.0.1 conformance suite, but any of the other WG >> members (Benoit, for example) should feel free to discuss the current >> state of things. >> >> -Ken >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Aug 24 14:48:30 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Aug 2012 14:48:30 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: On Fri, Aug 24, 2012 at 11:15 AM, Florian B?sch wrote: > On Fri, Aug 24, 2012 at 7:52 PM, Gregg Tavares (??) wrote: >> >> or similar that would mean sharing resources on the main page is not >> needed. > > That's exactly my thinking, it would simplify the design of the resource > sharing because you wouldn't have to consider main page canvasii > compositing. > >> >> Would this work >> >> var canvas1 = document.createElement("canvas"); >> var canvas2 = document.createElement("canvas"); >> var gl1 = canvas1.getContext("webgl"); >> var gl2 = canvas2.getContext("webgl"); >> >> //now both canvases are webgl canvases >> >> // swap them just for fun >> gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2); >> gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1); >> >> It seems like a little bit of a waste to have to create the second context >> just so the canvas is a WebGL canvas >> >> Also, ti seems like overloading the meaning of bindFramebuffer might not >> be the best method since there all various operations you can do to >> currently bound framebuffer. So maybe it should be something like >> >> gl.bindBackbuffer(canvas) >> >> or >> >> gl.bindCanvas(canvas) >> >> and then like normal, calling >> >> gl.bindFramebuffer(gl.FRAMEBUFFER,null) >> >> renders to the current backbuffer/canvas with all the limits that normally >> entails (can't call framebufferRenderbuffer or framebufrferTexture2D on it) > > Semantically that all works for me, I find I wouldn't have a preference if > we call this attaching a buffer to an FBO or binding a different > frontbuffer. > > There's one area where the FBO semantic does have an advantage though. If > you display partials (like say albedo of a scene) and then re-use the filled > depth buffer to render something else (like say deferred lighting) and you > have, for some reason, the desire to show both on the page (It's not > contrieved, I promise, I have such an example right now, releasing it in the > next few days). Since there isn't a way to attach (or even explicitly > obtain) the depth buffer for use on the front, you couldn't wire your > rendering together to share it. So what you'd end up doing would be to > render to an FBO and then sample that FBO to blit to the canvas. It's still > way better than the alternatives, just slightly inelegant (if you could do > it more directly). On the other hand, if you feel the API is much cleaner > with the bind frontbuffer semantic, I don't think that's a big drawback. This is an interesting direction and for some use cases would eliminate the need for share groups. However, I'm concerned that it isn't an extensible path to go down for at least a couple of reasons: 1) It isn't compatible with using WebGL in a worker. At present there is no way to use HTMLCanvasElements, or any other DOM element, from a worker, and it seems that enabling that is a very long road to go down with the HTML5 standards groups. 2) As Florian points out, it only supports use of the canvas as an output surface. I think there are likely to be a lot of use cases where it's desirable to use the rendered output as a texture for another rendering stage. 3) It doesn't address all of the use cases that share groups do, and if share groups were introduced later, they might make this API obsolete. Here is a suggestion toward resolving the problems of using OpenGL / WebGL resources shared between multiple contexts. What if, in WebGL, it were only legal to bind a given OpenGL object to a single context at once? This would essentially implement the acquire/release semantics proposed above, but without adding any new APIs. As an example, if a texture was bound to context 1, attempting to bind it to context 2 would produce an OpenGL error, and the bind would fail. This would mean that each object essentially would have a context which is its "owner". By and large, this can be implemented with a single compare-and-swap operation. It's similar to how "fast locking" schemes work in multithreaded virtual machines for languages like Java. Binding a container object that refers to other objects would have to obey the same rule. If fbo1 had texture1 as its color attachment, and context2 bound texture1 to one of its texture units, then it would be illegal for context1 to bind fbo1 until context2 unbound texture1. Same for program objects which refer to shader objects. This is a little more difficult to implement (not a simple compare-and-exchange per object any more) but I think still feasible within the WebGL implementation without too high a cost. This wouldn't address all of the problems associated with resource sharing. In particular, since the ES 2.0 spec requires a glFinish() in context1 before its rendering results into textures are guaranteed to be visible by context2, I'm not sure how it could be guaranteed that all of context1's work was visible in context2. If context2 bound an object that was most recently "dirtied" by context1, what would really be required is a glFinish() issued in context1, which could be difficult for the WebGL implementation to enforce. Any thoughts on this general idea? I don't think it would impose too many compatibility issues when porting multithreaded or multi-context code to WebGL, and would at least provide consistent and testable behavior for more situations. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Fri Aug 24 14:53:40 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 24 Aug 2012 14:53:40 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: This doesn't solve the cases Ben brought up. Namely the ability to read from the same texture at the same time in multiple workers. The Acquire/Release does solve that problem since more than one context can do a READ_ONLY acquire at the same time. On Fri, Aug 24, 2012 at 2:48 PM, Kenneth Russell wrote: > On Fri, Aug 24, 2012 at 11:15 AM, Florian B?sch wrote: > > On Fri, Aug 24, 2012 at 7:52 PM, Gregg Tavares (??) > wrote: > >> > >> or similar that would mean sharing resources on the main page is not > >> needed. > > > > That's exactly my thinking, it would simplify the design of the resource > > sharing because you wouldn't have to consider main page canvasii > > compositing. > > > >> > >> Would this work > >> > >> var canvas1 = document.createElement("canvas"); > >> var canvas2 = document.createElement("canvas"); > >> var gl1 = canvas1.getContext("webgl"); > >> var gl2 = canvas2.getContext("webgl"); > >> > >> //now both canvases are webgl canvases > >> > >> // swap them just for fun > >> gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2); > >> gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1); > >> > >> It seems like a little bit of a waste to have to create the second > context > >> just so the canvas is a WebGL canvas > >> > >> Also, ti seems like overloading the meaning of bindFramebuffer might not > >> be the best method since there all various operations you can do to > >> currently bound framebuffer. So maybe it should be something like > >> > >> gl.bindBackbuffer(canvas) > >> > >> or > >> > >> gl.bindCanvas(canvas) > >> > >> and then like normal, calling > >> > >> gl.bindFramebuffer(gl.FRAMEBUFFER,null) > >> > >> renders to the current backbuffer/canvas with all the limits that > normally > >> entails (can't call framebufferRenderbuffer or framebufrferTexture2D on > it) > > > > Semantically that all works for me, I find I wouldn't have a preference > if > > we call this attaching a buffer to an FBO or binding a different > > frontbuffer. > > > > There's one area where the FBO semantic does have an advantage though. If > > you display partials (like say albedo of a scene) and then re-use the > filled > > depth buffer to render something else (like say deferred lighting) and > you > > have, for some reason, the desire to show both on the page (It's not > > contrieved, I promise, I have such an example right now, releasing it in > the > > next few days). Since there isn't a way to attach (or even explicitly > > obtain) the depth buffer for use on the front, you couldn't wire your > > rendering together to share it. So what you'd end up doing would be to > > render to an FBO and then sample that FBO to blit to the canvas. It's > still > > way better than the alternatives, just slightly inelegant (if you could > do > > it more directly). On the other hand, if you feel the API is much cleaner > > with the bind frontbuffer semantic, I don't think that's a big drawback. > > This is an interesting direction and for some use cases would > eliminate the need for share groups. However, I'm concerned that it > isn't an extensible path to go down for at least a couple of reasons: > > 1) It isn't compatible with using WebGL in a worker. At present there > is no way to use HTMLCanvasElements, or any other DOM element, from a > worker, and it seems that enabling that is a very long road to go down > with the HTML5 standards groups. > 2) As Florian points out, it only supports use of the canvas as an > output surface. I think there are likely to be a lot of use cases > where it's desirable to use the rendered output as a texture for > another rendering stage. > 3) It doesn't address all of the use cases that share groups do, and > if share groups were introduced later, they might make this API > obsolete. > > Here is a suggestion toward resolving the problems of using OpenGL / > WebGL resources shared between multiple contexts. What if, in WebGL, > it were only legal to bind a given OpenGL object to a single context > at once? This would essentially implement the acquire/release > semantics proposed above, but without adding any new APIs. As an > example, if a texture was bound to context 1, attempting to bind it to > context 2 would produce an OpenGL error, and the bind would fail. This > would mean that each object essentially would have a context which is > its "owner". By and large, this can be implemented with a single > compare-and-swap operation. It's similar to how "fast locking" schemes > work in multithreaded virtual machines for languages like Java. > > Binding a container object that refers to other objects would have to > obey the same rule. If fbo1 had texture1 as its color attachment, and > context2 bound texture1 to one of its texture units, then it would be > illegal for context1 to bind fbo1 until context2 unbound texture1. > Same for program objects which refer to shader objects. This is a > little more difficult to implement (not a simple compare-and-exchange > per object any more) but I think still feasible within the WebGL > implementation without too high a cost. > > This wouldn't address all of the problems associated with resource > sharing. In particular, since the ES 2.0 spec requires a glFinish() in > context1 before its rendering results into textures are guaranteed to > be visible by context2, I'm not sure how it could be guaranteed that > all of context1's work was visible in context2. If context2 bound an > object that was most recently "dirtied" by context1, what would really > be required is a glFinish() issued in context1, which could be > difficult for the WebGL implementation to enforce. > > Any thoughts on this general idea? I don't think it would impose too > many compatibility issues when porting multithreaded or multi-context > code to WebGL, and would at least provide consistent and testable > behavior for more situations. > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 24 15:03:17 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 25 Aug 2012 00:03:17 +0200 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: On Fri, Aug 24, 2012 at 11:48 PM, Kenneth Russell wrote: > 1) It isn't compatible with using WebGL in a worker. At present there > is no way to use HTMLCanvasElements, or any other DOM element, from a > worker, and it seems that enabling that is a very long road to go down > with the HTML5 standards groups. I don't think it does have to solve it. Being able to address different addressable front-surfaces and being able to render to front surfaces from workers and being able to share resources between workers and main thread are actually 3 separate problems with almost no overlap. Main thread and workers would benefit from being able to address multiple front surfaces. Regardless of addressed front surface, workers would benefit from being able to use front surfaces at all. And regardless of workers capability to address front surfaces, or the amount of surfaces addressable, resource sharing would be useful when workers or main threads interact. > 2) As Florian points out, it only supports use of the canvas as an > output surface. I think there are likely to be a lot of use cases > where it's desirable to use the rendered output as a texture for > another rendering stage. > That's true, but I also said it's not a big deal long as we don't have to 1) deal with some complex/convoluted locking/synchronization/semaphoring/aquire/release/pray scheme. Not that this isn't required, it is, for other usecases, it just isn't required for the need to address multiple front surfaces. 2) not have to multiplex resource buildup across multiple canvases (as we would currently do) 3) or perform readbacks to blit to canvas 2d (as we also currently do) > 3) It doesn't address all of the use cases that share groups do, and > if share groups were introduced later, they might make this API > obsolete. > Like I said, I see front surface addressability and resource sharing as two completely different and fundamentally orthogonal aspects of rendering. One does not preclude the other, and a design shouldn't imply that imo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Aug 24 15:15:36 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Aug 2012 15:15:36 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: Before we discard this idea for this reason: I suspect that the biggest improvements in animation smoothness on the main thread will come from introducing one, not many, worker threads which can access WebGL. GPUs today are batch processors; better scalability won't be achieved by splitting up and issuing work from multiple CPU threads and multiple OpenGL contexts. The primary improvement for current WebGL apps would be to populate objects like textures without blocking CPU execution on the main thread. Therefore it might be a better idea to introduce a small semantic change like this one, instead of a more complex readers/writer locking API. However, I do believe that a readers/writer lock could be added in a backward compatible manner, where if only one context were in the share group, calls to acquire would not be mandatory. -Ken On Fri, Aug 24, 2012 at 2:53 PM, Gregg Tavares (??) wrote: > This doesn't solve the cases Ben brought up. Namely the ability to read from > the same texture at the same time in multiple workers. > > The Acquire/Release does solve that problem since more than one context can > do a READ_ONLY acquire at the same time. > > > > > On Fri, Aug 24, 2012 at 2:48 PM, Kenneth Russell wrote: >> >> On Fri, Aug 24, 2012 at 11:15 AM, Florian B?sch wrote: >> > On Fri, Aug 24, 2012 at 7:52 PM, Gregg Tavares (??) >> > wrote: >> >> >> >> or similar that would mean sharing resources on the main page is not >> >> needed. >> > >> > That's exactly my thinking, it would simplify the design of the resource >> > sharing because you wouldn't have to consider main page canvasii >> > compositing. >> > >> >> >> >> Would this work >> >> >> >> var canvas1 = document.createElement("canvas"); >> >> var canvas2 = document.createElement("canvas"); >> >> var gl1 = canvas1.getContext("webgl"); >> >> var gl2 = canvas2.getContext("webgl"); >> >> >> >> //now both canvases are webgl canvases >> >> >> >> // swap them just for fun >> >> gl1.bindFramebuffer(gl.FRAMEBUFFER, canvas2); >> >> gl2.bindFramebuffer(gl.FRAMEBUFFER, canvas1); >> >> >> >> It seems like a little bit of a waste to have to create the second >> >> context >> >> just so the canvas is a WebGL canvas >> >> >> >> Also, ti seems like overloading the meaning of bindFramebuffer might >> >> not >> >> be the best method since there all various operations you can do to >> >> currently bound framebuffer. So maybe it should be something like >> >> >> >> gl.bindBackbuffer(canvas) >> >> >> >> or >> >> >> >> gl.bindCanvas(canvas) >> >> >> >> and then like normal, calling >> >> >> >> gl.bindFramebuffer(gl.FRAMEBUFFER,null) >> >> >> >> renders to the current backbuffer/canvas with all the limits that >> >> normally >> >> entails (can't call framebufferRenderbuffer or framebufrferTexture2D on >> >> it) >> > >> > Semantically that all works for me, I find I wouldn't have a preference >> > if >> > we call this attaching a buffer to an FBO or binding a different >> > frontbuffer. >> > >> > There's one area where the FBO semantic does have an advantage though. >> > If >> > you display partials (like say albedo of a scene) and then re-use the >> > filled >> > depth buffer to render something else (like say deferred lighting) and >> > you >> > have, for some reason, the desire to show both on the page (It's not >> > contrieved, I promise, I have such an example right now, releasing it in >> > the >> > next few days). Since there isn't a way to attach (or even explicitly >> > obtain) the depth buffer for use on the front, you couldn't wire your >> > rendering together to share it. So what you'd end up doing would be to >> > render to an FBO and then sample that FBO to blit to the canvas. It's >> > still >> > way better than the alternatives, just slightly inelegant (if you could >> > do >> > it more directly). On the other hand, if you feel the API is much >> > cleaner >> > with the bind frontbuffer semantic, I don't think that's a big drawback. >> >> This is an interesting direction and for some use cases would >> eliminate the need for share groups. However, I'm concerned that it >> isn't an extensible path to go down for at least a couple of reasons: >> >> 1) It isn't compatible with using WebGL in a worker. At present there >> is no way to use HTMLCanvasElements, or any other DOM element, from a >> worker, and it seems that enabling that is a very long road to go down >> with the HTML5 standards groups. >> 2) As Florian points out, it only supports use of the canvas as an >> output surface. I think there are likely to be a lot of use cases >> where it's desirable to use the rendered output as a texture for >> another rendering stage. >> 3) It doesn't address all of the use cases that share groups do, and >> if share groups were introduced later, they might make this API >> obsolete. >> >> Here is a suggestion toward resolving the problems of using OpenGL / >> WebGL resources shared between multiple contexts. What if, in WebGL, >> it were only legal to bind a given OpenGL object to a single context >> at once? This would essentially implement the acquire/release >> semantics proposed above, but without adding any new APIs. As an >> example, if a texture was bound to context 1, attempting to bind it to >> context 2 would produce an OpenGL error, and the bind would fail. This >> would mean that each object essentially would have a context which is >> its "owner". By and large, this can be implemented with a single >> compare-and-swap operation. It's similar to how "fast locking" schemes >> work in multithreaded virtual machines for languages like Java. >> >> Binding a container object that refers to other objects would have to >> obey the same rule. If fbo1 had texture1 as its color attachment, and >> context2 bound texture1 to one of its texture units, then it would be >> illegal for context1 to bind fbo1 until context2 unbound texture1. >> Same for program objects which refer to shader objects. This is a >> little more difficult to implement (not a simple compare-and-exchange >> per object any more) but I think still feasible within the WebGL >> implementation without too high a cost. >> >> This wouldn't address all of the problems associated with resource >> sharing. In particular, since the ES 2.0 spec requires a glFinish() in >> context1 before its rendering results into textures are guaranteed to >> be visible by context2, I'm not sure how it could be guaranteed that >> all of context1's work was visible in context2. If context2 bound an >> object that was most recently "dirtied" by context1, what would really >> be required is a glFinish() issued in context1, which could be >> difficult for the WebGL implementation to enforce. >> >> Any thoughts on this general idea? I don't think it would impose too >> many compatibility issues when porting multithreaded or multi-context >> code to WebGL, and would at least provide consistent and testable >> behavior for more situations. >> >> -Ken > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Aug 24 15:18:02 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 25 Aug 2012 00:18:02 +0200 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: Let's make an example, this is how I want to deal with the problem: gl = createContext(); gl.bindFront(canvas1); gl.uniform4fv(view); gl.drawArrays(...); gl.bindFront(null) mat4rotatex(90, view); gl.bindFront(canvas2); gl.uniform4vf(view); gl.drawArrays(...) gl.bindFront(null) This is how I do not want to have to deal with it: ctx1 = canvas1.getContext() ctx2 = canvas2.getContext() shader = ctx1.createShader(); ... ctx1.use(shader) ctx1.acquire(shader) ctx1.acquire(buffer) ctx1.uniform4fv(mat4) ctx1.drawArrays(...) ctx1.unuse(shader) release(shader) release(buffer) ctx2.acquire(shader) ctx2.acquire(buffer) ctx2.useShader(shader) rotatex(90, view) ctx2.drawArrays() ctx2.unbind(buffer) ctx2.unuse(shader) ctx2.release(shader) ctx2.release(buffer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Aug 24 15:25:28 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Fri, 24 Aug 2012 15:25:28 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: We agree 100%. As you pointed out we're talking about several different problems here 1) how to render to more than 1 canvas 2) how to share resources across contexts in the same page 3) how to share resources across contexts in workers. The acquire/release thing is only suggested for #3 #1 and #2 used to be just #2 but as you pointed out there's a better solution for most if not all cases. On Fri, Aug 24, 2012 at 3:18 PM, Florian B?sch wrote: > Let's make an example, this is how I want to deal with the problem: > > gl = createContext(); > > gl.bindFront(canvas1); > gl.uniform4fv(view); > gl.drawArrays(...); > gl.bindFront(null) > > mat4rotatex(90, view); > gl.bindFront(canvas2); > gl.uniform4vf(view); > gl.drawArrays(...) > gl.bindFront(null) > > This is how I do not want to have to deal with it: > > ctx1 = canvas1.getContext() > ctx2 = canvas2.getContext() > shader = ctx1.createShader(); ... > ctx1.use(shader) > ctx1.acquire(shader) > ctx1.acquire(buffer) > ctx1.uniform4fv(mat4) > ctx1.drawArrays(...) > ctx1.unuse(shader) > release(shader) > release(buffer) > > ctx2.acquire(shader) > ctx2.acquire(buffer) > ctx2.useShader(shader) > rotatex(90, view) > ctx2.drawArrays() > ctx2.unbind(buffer) > ctx2.unuse(shader) > ctx2.release(shader) > ctx2.release(buffer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Aug 24 15:25:02 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Aug 2012 15:25:02 -0700 Subject: [Public WebGL] Issues with sharing resources across contexts In-Reply-To: References: <446321983.2876249.1342722844745.JavaMail.root@mozilla.com> <9CD44A3C-77C4-4E1E-8DAB-8160C8E4EC6F@transgaming.com> <6DD51677-31CD-4286-80EE-81F6288EDA0F@gmail.com> Message-ID: Ken: I'd hate to see the tradeoff go so far in the way of 'just make it faster for the simple cases'. The single worker populating textures is something I'd argue doesn't need any of this work, anyway - if the browsers weren't so horrible at decoding images (so move network and decode and upload off the main thread, etc) it largely wouldn't matter. It's something much better left in native browser code and as an implementation detail to apps. If the goal was just this decoding case, I'd say ignore any user-app level API changes and fix the browser code instead. Save the API changes for the interesting bits. Those interesting bits of off-thread access are all ones where either multiple workers or main/worker in conjunction are touching resources in non-trivial (read: dynamic) ways. On Fri, Aug 24, 2012 at 3:18 PM, Florian B?sch wrote: > Let's make an example, this is how I want to deal with the problem: > > gl = createContext(); > > gl.bindFront(canvas1); > gl.uniform4fv(view); > gl.drawArrays(...); > gl.bindFront(null) > > mat4rotatex(90, view); > gl.bindFront(canvas2); > gl.uniform4vf(view); > gl.drawArrays(...) > gl.bindFront(null) > > This is how I do not want to have to deal with it: > > ctx1 = canvas1.getContext() > ctx2 = canvas2.getContext() > shader = ctx1.createShader(); ... > ctx1.use(shader) > ctx1.acquire(shader) > ctx1.acquire(buffer) > ctx1.uniform4fv(mat4) > ctx1.drawArrays(...) > ctx1.unuse(shader) > release(shader) > release(buffer) > > ctx2.acquire(shader) > ctx2.acquire(buffer) > ctx2.useShader(shader) > rotatex(90, view) > ctx2.drawArrays() > ctx2.unbind(buffer) > ctx2.unuse(shader) > ctx2.release(shader) > ctx2.release(buffer) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 06:14:49 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 15:14:49 +0200 Subject: [Public WebGL] Issues while doing my last demo Message-ID: I've released my latest demo (global illumination via deferred irradiance volumes) http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/ During development (2 1/2 weeks) I discovered a few issues. Bugs: - Firefox preserve drawing buffer false clear bug https://bugzilla.mozilla.org/show_bug.cgi?id=785838 - unrolling in angle for d3d gives trouble (2 minute compile time until error): https://bugzilla.mozilla.org/show_bug.cgi?id=785848 - preprocessor issue with FXAA 3.11 (works fine on linux/osx but fails on angle d3d, no bug ticket yet, still waiting for feedback): http://codeflow.org/issues/preprocessor-problem/ Slowness: - gl.clear on front is very slow - Shader compile times are very long (a simple shader takes 11ms to compile, FXAA takes 66ms to compile, times go up significantly on windows) - early-Z does not seem to work (things got faster *after* adding discard, which disables early-Z) which would be rather important for deferred shading. API Issues: - gl.clear is clamped to the range 0-1, which does not allow you to clear an FBO attached floating point texture, and instead you'll have to create a shader and splat a quad and set the desired color by passing in a uniform to be passed on to gl_FragColor - Working with packed image data (dozens or hundreds of images intended to upload into webgl) is very cumbersome, see code below: // Assuming some large source buffer in data: var data = new ArrayBuffer(...); // comes from an XHR var storage = new ArrayBuffer(desired_size); // ArrayBufferView.set to read beyond the desired size var dst = new Uint8Array(storage); // can't call set on array buffer var src = new Uint8Array(data, desired_offset, desired_size); // can't pass array buffer to set dst.set(src); // copy dst = dst.buffer; // can't pass view to blob builder, also need to prevent BlobBuilder to read the entire buffer var builder = new BlobBuilder(); // using (deprecated) blob builder because neither FF nor chrome accepts either arrybuffer or arrayview in new Blob() constructor builder.append(dst); var blob = builder.getBlob('image/jpg'); var url = URL.createObjectURL(blob); var image = new Image(); image.src = url; var texture = gl.createTexture(); image.onload = function(){ gl.activeTexture(0); gl.bindTexture(gl.TEXTURE_2D, texture); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image); } Ideally that should work more like: var data = Image.decodeBytes('image/jpg', array_buffer_view); // array buffer gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, width, height, 0, gl.RGBA, gl.UNSIGNED_BYTE, data); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 06:41:24 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 15:41:24 +0200 Subject: [Public WebGL] Re: Issues while doing my last demo In-Reply-To: References: Message-ID: Got feedback on the preprocessor issue: https://bugzilla.mozilla.org/show_bug.cgi?id=785855 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 08:24:22 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 17:24:22 +0200 Subject: [Public WebGL] Re: Issues while doing my last demo In-Reply-To: References: Message-ID: On Mon, Aug 27, 2012 at 3:41 PM, Florian B?sch wrote: > Got feedback on the preprocessor issue: > https://bugzilla.mozilla.org/show_bug.cgi?id=785855 Created a conformance test for this issue: https://github.com/KhronosGroup/WebGL/pull/18 Using reserved macro names should produce an error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toj...@ Mon Aug 27 08:36:51 2012 From: toj...@ (Brandon Jones) Date: Mon, 27 Aug 2012 08:36:51 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: Message-ID: <6225778062757885072@unknownmsgid> I just wanted to drop in and say thanks for doing this demo! It's probably the most technically impressive WebGL usage I've seen to date, and the presentation of the different stages in addition to the very informative blog post make it a wonderful educational resource! Again, thank you! I am curious about one performance point that you didn't mention, though: many of us (yourself included) have been bemoaning the lack of MRTs to enable advanced effects such as this. Do you have any measure of how much time in your demo is spent re-rendering the same view? I'm interested to hear what the real-world benefit of MRTs would be for a technique like this. --Brandon Sent from my iPhone On Aug 27, 2012, at 6:18 AM, "Florian B?sch" wrote: I've released my latest demo (global illumination via deferred irradiance volumes) http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/ During development (2 1/2 weeks) I discovered a few issues. Bugs: - Firefox preserve drawing buffer false clear bug https://bugzilla.mozilla.org/show_bug.cgi?id=785838 - unrolling in angle for d3d gives trouble (2 minute compile time until error): https://bugzilla.mozilla.org/show_bug.cgi?id=785848 - preprocessor issue with FXAA 3.11 (works fine on linux/osx but fails on angle d3d, no bug ticket yet, still waiting for feedback): http://codeflow.org/issues/preprocessor-problem/ Slowness: - gl.clear on front is very slow - Shader compile times are very long (a simple shader takes 11ms to compile, FXAA takes 66ms to compile, times go up significantly on windows) - early-Z does not seem to work (things got faster *after* adding discard, which disables early-Z) which would be rather important for deferred shading. API Issues: - gl.clear is clamped to the range 0-1, which does not allow you to clear an FBO attached floating point texture, and instead you'll have to create a shader and splat a quad and set the desired color by passing in a uniform to be passed on to gl_FragColor - Working with packed image data (dozens or hundreds of images intended to upload into webgl) is very cumbersome, see code below: // Assuming some large source buffer in data: var data = new ArrayBuffer(...); // comes from an XHR var storage = new ArrayBuffer(desired_size); // ArrayBufferView.set to read beyond the desired size var dst = new Uint8Array(storage); // can't call set on array buffer var src = new Uint8Array(data, desired_offset, desired_size); // can't pass array buffer to set dst.set(src); // copy dst = dst.buffer; // can't pass view to blob builder, also need to prevent BlobBuilder to read the entire buffer var builder = new BlobBuilder(); // using (deprecated) blob builder because neither FF nor chrome accepts either arrybuffer or arrayview in new Blob() constructor builder.append(dst); var blob = builder.getBlob('image/jpg'); var url = URL.createObjectURL(blob); var image = new Image(); image.src = url; var texture = gl.createTexture(); image.onload = function(){ gl.activeTexture(0); gl.bindTexture(gl.TEXTURE_2D, texture); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image); } Ideally that should work more like: var data = Image.decodeBytes('image/jpg', array_buffer_view); // array buffer gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, width, height, 0, gl.RGBA, gl.UNSIGNED_BYTE, data); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 08:51:47 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 17:51:47 +0200 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: <6225778062757885072@unknownmsgid> References: <6225778062757885072@unknownmsgid> Message-ID: On Mon, Aug 27, 2012 at 5:36 PM, Brandon Jones wrote: > I just wanted to drop in and say thanks for doing this demo! It's probably > the most technically impressive WebGL usage I've seen to date, and the > presentation of the different stages in addition to the very informative > blog post make it a wonderful educational resource! Again, thank you! > Thanks :) > I am curious about one performance point that you didn't mention, though: > many of us (yourself included) have been bemoaning the lack of MRTs to > enable advanced effects such as this. Do you have any measure of how much > time in your demo is spent re-rendering the same view? I'm interested to > hear what the real-world benefit of MRTs would be for a technique like this. > I don't think the lack of MRTs in this demo is a big bottleneck for reasons unique to the demo: - I only capture Albedo, Normal and Depth which can be done in 2 Passes. - The scene is a flat, unchanging array buffer of some 60k triangles, which isn't very demanding. - The overhead of rendering the simple scene twice is dwarfed by the performance issue of transferring the GI to the rendered scene (deferred shading with lots of overdraw) which isn't helped by the apparent lack of early-z. If I find a way to reduce the deferred shading overhead (tiled-shading or something) and if the scene would be more expensive to draw, things would be different. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 27 11:26:06 2012 From: cal...@ (Mark Callow) Date: Mon, 27 Aug 2012 11:26:06 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: Message-ID: <503BBBBE.90403@hicorp.co.jp> On 12/08/27 6:14, Florian B?sch wrote: > API Issues: > - gl.clear is clamped to the range 0-1, which does not allow you to > clear an FBO attached floating point texture, and instead you'll have > to create a shader and splat a quad and set the desired color by > passing in a uniform to be passed on to gl_FragColor This is because this group did not do a complete extension specification for rendering to floating point buffers. OES_texture_float was never intended to support such rendering so does not include necessary changes to the Open GL ES 2.0 specification. The issue was pointed out at the time the WebGL version of OES_texture_float was hacked to allow rendering to FP buffers. EXT_color_buffer_half_float probably describes all the changes necessary. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 11:41:00 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 20:41:00 +0200 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: <503BBBBE.90403@hicorp.co.jp> References: <503BBBBE.90403@hicorp.co.jp> Message-ID: On Mon, Aug 27, 2012 at 8:26 PM, Mark Callow wrote: > This is because this group did not do a complete extension specification > for rendering to floating point buffers. OES_texture_float was never > intended to support such rendering so does not include necessary changes to > the Open GL ES 2.0 specification. The issue was pointed out at the time the > WebGL version of OES_texture_float was hacked to allow rendering to FP > buffers. > I see. I just consulted the ES 3.0 specification and while it does include texture float in the core without an extension, the clear specification in ES 3.0 still clamps clear values to the 0-1 range. So in that regard the ES 3.0 specification is equally incomplete. The framebuffer and texture float extensions defined for ES and none of them clarifies/defines this behavior. I think this will call for something like OES_clear_themissingfeatures or something as an extension. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 27 11:54:16 2012 From: cal...@ (Mark Callow) Date: Mon, 27 Aug 2012 11:54:16 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: <503BBBBE.90403@hicorp.co.jp> Message-ID: <503BC258.9040503@hicorp.co.jp> On 12/08/27 11:41, Florian B?sch wrote: > > I see. I just consulted the ES 3.0 specification and while it does > include texture float in the core without an extension, the clear > specification in ES 3.0 still clamps clear values to the 0-1 range. So > in that regard the ES 3.0 specification is equally incomplete. > > The framebuffer and texture float extensions defined for ES and none > of them clarifies/defines this behavior. I think this will call for > something like OES_clear_the missing features or something as an > extension. It is not incomplete. Read it carefully. The clampf type has been removed so by default no clamping is done. The spec for ClearColor says that the values are clamped for unsigned normalized fixed-point buffers. EXT_color_buffer_float also changes the language of ClearColor to something very similar to what is in 3.0 except that unsigned is missing. This extension does indeed cover most of the changes needed to ES 2.0 language to support full float color buffers. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 12:21:50 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 21:21:50 +0200 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: <503BC258.9040503@hicorp.co.jp> References: <503BBBBE.90403@hicorp.co.jp> <503BC258.9040503@hicorp.co.jp> Message-ID: On Mon, Aug 27, 2012 at 8:54 PM, Mark Callow wrote: > EXT_color_buffer_float also changes the language of ClearColor to > something very similar to what is in 3.0 except that unsigned is missing. > This extension does indeed cover most of the changes needed to ES 2.0 > language to support full float color buffers. > Right, so EXT_color_buffer_half_float is our clear_withthemissingfeatures. There's one snag though. Out of 948 devices 3 support this extension which are the iPad2, iPad3 and iPhone 4S. darnit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Aug 27 12:27:22 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Aug 2012 12:27:22 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: Message-ID: On Mon, Aug 27, 2012 at 6:14 AM, Florian B?sch wrote: > I've released my latest demo (global illumination via deferred irradiance > volumes) > http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/ > > During development (2 1/2 weeks) I discovered a few issues. > > Bugs: > - Firefox preserve drawing buffer false clear bug > https://bugzilla.mozilla.org/show_bug.cgi?id=785838 > - unrolling in angle for d3d gives trouble (2 minute compile time until > error): https://bugzilla.mozilla.org/show_bug.cgi?id=785848 > - preprocessor issue with FXAA 3.11 (works fine on linux/osx but fails on > angle d3d, no bug ticket yet, still waiting for feedback): > http://codeflow.org/issues/preprocessor-problem/ > > Slowness: > - gl.clear on front is very slow > - Shader compile times are very long (a simple shader takes 11ms to compile, > FXAA takes 66ms to compile, times go up significantly on windows) > - early-Z does not seem to work (things got faster *after* adding discard, > which disables early-Z) which would be rather important for deferred > shading. > > API Issues: > - gl.clear is clamped to the range 0-1, which does not allow you to clear an > FBO attached floating point texture, and instead you'll have to create a > shader and splat a quad and set the desired color by passing in a uniform to > be passed on to gl_FragColor > > - Working with packed image data (dozens or hundreds of images intended to > upload into webgl) is very cumbersome, see code below: > > // Assuming some large source buffer in data: > var data = new ArrayBuffer(...); // comes from an XHR > var storage = new ArrayBuffer(desired_size); // ArrayBufferView.set to read > beyond the desired size > var dst = new Uint8Array(storage); // can't call set on array buffer > var src = new Uint8Array(data, desired_offset, desired_size); // can't pass > array buffer to set > dst.set(src); // copy > dst = dst.buffer; // can't pass view to blob builder, also need to prevent > BlobBuilder to read the entire buffer > var builder = new BlobBuilder(); // using (deprecated) blob builder because > neither FF nor chrome accepts either arrybuffer or arrayview in new Blob() > constructor > builder.append(dst); > var blob = builder.getBlob('image/jpg'); > var url = URL.createObjectURL(blob); > var image = new Image(); > image.src = url; > var texture = gl.createTexture(); > image.onload = function(){ > gl.activeTexture(0); > gl.bindTexture(gl.TEXTURE_2D, texture); > gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, > image); > } > > Ideally that should work more like: > > var data = Image.decodeBytes('image/jpg', array_buffer_view); // array > buffer > gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, width, height, 0, gl.RGBA, > gl.UNSIGNED_BYTE, data); Nice demo and writeup! Kudos for making the source code available. Thanks also for the conformance test covering the reserved identifier issue in the shader preprocessor. Could you not use ArrayBuffer.slice() to simplify your blob construction code above? I only tested Chrome and Firefox but it looks like it is implemented in both. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Mon Aug 27 12:30:46 2012 From: cal...@ (Mark Callow) Date: Mon, 27 Aug 2012 12:30:46 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: <503BBBBE.90403@hicorp.co.jp> <503BC258.9040503@hicorp.co.jp> Message-ID: <503BCAE6.3080002@hicorp.co.jp> On 12/08/27 12:21, Florian B?sch wrote: > > Right, so EXT_color_buffer_half_float is our > clear_withthemissingfeatures. There's one snag though. Out of 948 > devices 3 support this extension which are the iPad2, iPad3 and iPhone > 4S. darnit. I'm surprised; it was made EXT because other companies said they would support it. Anyway it's not particularly relevant. The point is it has the language that could be copied to WebGL's version of OES_texture_float to make it properly support floating point color buffers or used to create a new WebGL_color_buffer_float extension that could replace the egregious hack in WebGL's OES_texture_float. Such an extension would likely only be able to run on desktop. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 27 12:47:19 2012 From: cal...@ (Mark Callow) Date: Mon, 27 Aug 2012 12:47:19 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: Message-ID: <503BCEC7.2030207@hicorp.co.jp> On 12/08/27 6:14, Florian B?sch wrote: > I've released my latest demo (global illumination via deferred > irradiance > volumes) http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/ > > > During development (2 1/2 weeks) I discovered a few issues. > > Bugs: > - Firefox preserve drawing buffer false clear > bug https://bugzilla.mozilla.org/show_bug.cgi?id=785838 > - unrolling in angle for d3d gives trouble (2 minute compile time > until error): https://bugzilla.mozilla.org/show_bug.cgi?id=785848 > - preprocessor issue with FXAA 3.11 (works fine on linux/osx but fails > on angle d3d, no bug ticket yet, still waiting for > feedback): http://codeflow.org/issues/preprocessor-problem/ There is no anti-aliasing happening in Firefox 14 on OS X. Presumably this is because FF is not yet supporting the antialias: true attribute on the drawing buffer though it is not clear to me how FXAA and anti-alias: true play together. Also the structure's shape appears to change as I look around. It's like the perspective is changing along with the view. It gives one an unsettled feeling. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 27 13:15:40 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 27 Aug 2012 22:15:40 +0200 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: <503BCEC7.2030207@hicorp.co.jp> References: <503BCEC7.2030207@hicorp.co.jp> Message-ID: On Mon, Aug 27, 2012 at 9:47 PM, Mark Callow wrote: > There is no anti-aliasing happening in Firefox 14 on OS X. Presumably this > is because FF is not yet supporting the antialias: true attribute on the > drawing buffer though it is not clear to me how FXAA and anti-alias: true > play together. > You wouldn't get antialiasing via the drawing buffer as all views are rendered trough FBOs. FXAA is applied after the last composit and gamma adjustment. However due to performance reasons everything is rendered at half-size, on any account FXAA cannot deal as well with temporal aliasing as MSAA can, but supersampling is not an option due to performance. As it is, FXAA serves to limit some of the worst aliasing you can see, but it won't get all. > Also the structure's shape appears to change as I look around. It's like > the perspective is changing along with the view. It gives one an unsettled > feeling. > That sounds weird, I use a fairly wide opening angle (75?) is that what you mean? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 27 13:49:19 2012 From: cal...@ (Mark Callow) Date: Mon, 27 Aug 2012 13:49:19 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: References: <503BCEC7.2030207@hicorp.co.jp> Message-ID: <503BDD4F.4070906@hicorp.co.jp> On 12/08/27 13:15, Florian B?sch wrote: > On Mon, Aug 27, 2012 at 9:47 PM, Mark Callow > wrote: > > There is no anti-aliasing happening in Firefox 14 on OS X. > Presumably this is because FF is not yet supporting the antialias: > true attribute on the drawing buffer though it is not clear to me > how FXAA and anti-alias: true play together. > > You wouldn't get antialiasing via the drawing buffer as all views are > rendered trough FBOs. FXAA is applied after the last composit and > gamma adjustment. However due to performance reasons everything is > rendered at half-size, on any account FXAA cannot deal as well with > temporal aliasing as MSAA can, but supersampling is not an option due > to performance. As it is, FXAA serves to limit some of the worst > aliasing you can see, but it won't get all. > > > Also the structure's shape appears to change as I look around. > It's like the perspective is changing along with the view. It > gives one an unsettled feeling. > > That sounds weird, I use a fairly wide opening angle (75?) is that > what you mean? Yes. That might be it. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Aug 27 14:22:58 2012 From: bja...@ (Benoit Jacob) Date: Mon, 27 Aug 2012 14:22:58 -0700 (PDT) Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: <503BCEC7.2030207@hicorp.co.jp> Message-ID: <652620194.3902752.1346102578254.JavaMail.root@mozilla.com> ----- Original Message ----- > On 12/08/27 6:14, Florian B?sch wrote: > > I've released my latest demo (global illumination via deferred > > irradiance volumes) > > http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/ > > > During development (2 1/2 weeks) I discovered a few issues. > > > Bugs: > > > - Firefox preserve drawing buffer false clear bug > > https://bugzilla.mozilla.org/show_bug.cgi?id=785838 > > > - unrolling in angle for d3d gives trouble (2 minute compile time > > until error): https://bugzilla.mozilla.org/show_bug.cgi?id=785848 > > > - preprocessor issue with FXAA 3.11 (works fine on linux/osx but > > fails on angle d3d, no bug ticket yet, still waiting for feedback): > > http://codeflow.org/issues/preprocessor-problem/ > > There is no anti-aliasing happening in Firefox 14 on OS X. Presumably > this is because FF is not yet supporting the antialias: true > attribute on the drawing buffer though it is not clear to me how > FXAA and anti-alias: true play together. Firefox does support antialias:true. Some AMD GPUs are blacklisted for antialiasing on OSX. Maybe that's what you are running into? Does setting webgl.msaa-force=true make a difference? Benoit > Also the structure's shape appears to change as I look around. It's > like the perspective is changing along with the view. It gives one > an unsettled feeling. > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??? > NOTE: This electronic mail message may contain confidential and > privileged information from HI Corporation. If you are not the > intended recipient, any disclosure, photocopying, distribution or > use of the contents of the received information is prohibited. If > you have received this e-mail in error, please notify the sender > immediately and permanently delete this message and all related > copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Aug 27 15:14:02 2012 From: cal...@ (Mark Callow) Date: Mon, 27 Aug 2012 15:14:02 -0700 Subject: [Public WebGL] Issues while doing my last demo In-Reply-To: <652620194.3902752.1346102578254.JavaMail.root@mozilla.com> References: <652620194.3902752.1346102578254.JavaMail.root@mozilla.com> Message-ID: <503BF12A.3020307@hicorp.co.jp> On 12/08/27 14:22, Benoit Jacob wrote: > > There is no anti-aliasing happening in Firefox 14 on OS X. > Presumably this is because FF is not yet supporting the antialias: > true attribute on the drawing buffer though it is not clear to me > how FXAA and anti-alias: true play together. > > Firefox does support antialias:true. Some AMD GPUs are blacklisted > for antialiasing on OSX. Maybe that's what you are running into? Does > setting webgl.msaa-force=true make a difference? No it does not. But it wouldn't, in light of Florian's explanation. What I am seeing is temporal aliasing and the effects of the half-size rendering. Regards -Mark P.S. Maybe you shoud consider more verbose output in about:support that lists which features are enabled and which are blocked. -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Aug 28 09:23:00 2012 From: bja...@ (Benoit Jacob) Date: Tue, 28 Aug 2012 09:23:00 -0700 (PDT) Subject: [Public WebGL] Emscripten now able to port a whole OpenGL FPS game to WebGL In-Reply-To: <1092915605.4231115.1346170781889.JavaMail.root@mozilla.com> Message-ID: <1044842925.4232333.1346170980417.JavaMail.root@mozilla.com> Hi List, This link may be of interest, https://hacks.mozilla.org/2012/08/mozilla-and-games-pushing-the-limits-of-whats-possible/ as it demonstrates the viability of WebGL as a target for porting existing C++/OpenGL applications. Kudos to the Emscripten team --- to achieve that, Emscripten was extended to convert OpenGL calls to WebGL; in addition to the OpenGL ES 2.0 subset, this also includes partial support for OpenGL 1 calls. Note that all of this is open source so this could benefit anyone interesting in porting games to WebGL. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Aug 28 10:13:57 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 28 Aug 2012 10:13:57 -0700 Subject: [Public WebGL] Re: display the proposed extensions below draft? In-Reply-To: References: <5017A14E.80605@hicorp.co.jp> Message-ID: My apologies for the long delay, but this has now been implemented -- the proposed extensions show up on the WebGL extension registry front page. Note that they are only sorted by name, since they don't have numbers assigned yet. http://www.khronos.org/registry/webgl/extensions/ -Ken On Tue, Jul 31, 2012 at 9:16 AM, Kenneth Russell wrote: > The rationale was probably to avoid making them appear official. It's > not a problem to add them. > > Gregg's been driving the Github migration, which is almost done. Let's > hold off for a couple more days until he gives the all-clear. > > -Ken > > > On Tue, Jul 31, 2012 at 2:11 AM, Mark Callow wrote: >> On 31/07/2012 17:19, Florian B?sch wrote: >> >> Any comment? >> >> When I was getting started on WEBGL_dynamic_texture, I found it strange that >> the proposed extensions didn't show up. I don't know why it was done that >> way. >> >> Regards >> >> -Mark >> >> -- >> ???????????????????????????????????????????????????????????????? >> ???????????????????????????????????????????????????????????????? ??? >> >> NOTE: This electronic mail message may contain confidential and privileged >> information from HI Corporation. If you are not the intended recipient, any >> disclosure, photocopying, distribution or use of the contents of the >> received information is prohibited. If you have received this e-mail in >> error, please notify the sender immediately and permanently delete this >> message and all related copies. From pya...@ Tue Aug 28 10:35:51 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 28 Aug 2012 19:35:51 +0200 Subject: [Public WebGL] Re: display the proposed extensions below draft? In-Reply-To: References: <5017A14E.80605@hicorp.co.jp> Message-ID: On Tue, Aug 28, 2012 at 7:13 PM, Kenneth Russell wrote: > My apologies for the long delay, but this has now been implemented -- > the proposed extensions show up on the WebGL extension registry front > page. Note that they are only sorted by name, since they don't have > numbers assigned yet. > > http://www.khronos.org/registry/webgl/extensions/ Cool, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Aug 28 10:56:25 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 28 Aug 2012 10:56:25 -0700 Subject: [Public WebGL] Emscripten now able to port a whole OpenGL FPS game to WebGL In-Reply-To: <1044842925.4232333.1346170980417.JavaMail.root@mozilla.com> References: <1092915605.4231115.1346170781889.JavaMail.root@mozilla.com> <1044842925.4232333.1346170980417.JavaMail.root@mozilla.com> Message-ID: Nice work! Performance is good, and the visual effects look nice. It's pretty scary to jump off the top of the towers into nothingness. :) Everything worked great in Firefox Aurora on a mid-2010 MacBook Pro, but I ran into a couple of issues with a couple of the levels in Chrome. I'll follow up about these offline. -Ken On Tue, Aug 28, 2012 at 9:23 AM, Benoit Jacob wrote: > > Hi List, > > This link may be of interest, > > https://hacks.mozilla.org/2012/08/mozilla-and-games-pushing-the-limits-of-whats-possible/ > > as it demonstrates the viability of WebGL as a target for porting existing C++/OpenGL applications. > > Kudos to the Emscripten team --- to achieve that, Emscripten was extended to convert OpenGL calls to WebGL; in addition to the OpenGL ES 2.0 subset, this also includes partial support for OpenGL 1 calls. > > Note that all of this is open source so this could benefit anyone interesting in porting games to WebGL. > > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Tue Aug 28 11:43:58 2012 From: cal...@ (Mark Callow) Date: Tue, 28 Aug 2012 11:43:58 -0700 Subject: [Public WebGL] Emscripten now able to port a whole OpenGL FPS game to WebGL In-Reply-To: <1044842925.4232333.1346170980417.JavaMail.root@mozilla.com> References: <1044842925.4232333.1346170980417.JavaMail.root@mozilla.com> Message-ID: <503D116E.60301@hicorp.co.jp> On 12/08/28 9:23, Benoit Jacob wrote: > Hi List, > > This link may be of interest, > > https://hacks.mozilla.org/2012/08/mozilla-and-games-pushing-the-limits-of-whats-possible/ > Since when do robots have blood? Seriously, nice work. Runs well and sound is nicely in sync. A note for those who read " The latest Firefox release includes all of the JavaScript and WebGL updates needed to produce this demo." and are on the release channel like me. You need Firefox 15 which has only just been released. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??? NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kri...@ Wed Aug 29 14:27:49 2012 From: kri...@ (Kristian Sons) Date: Wed, 29 Aug 2012 23:27:49 +0200 Subject: [Public WebGL] Bufferdata behavior Message-ID: <503E8955.9070301@dfki.de> Hi, just found following inconsistent behavior in my (buggy) code :) bufferData(GLenum target, ArrayBufferView data, GLenum usage) If data is null Firefox and Chrome on Windows have the specified behavior: INVALID_VALUE. If data is undefined, it seems that Firefox creates a zero sized buffer, while Chrome seems to just ignore that call. I'm not sure if I missed something in the spec. For the user, it would be nice to have the same behavior as in the null case: there is very likely a bug in the call that is hard to find with the current behaviors. Kristian -- ________________________________________________________ Kristian Sons Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realit?t Campus, Geb. D 3 2, Raum 0.77 66123 Saarbr?cken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775--2235 kristian.sons...@ http://www.xml3d.org Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzb...@ Wed Aug 29 14:49:56 2012 From: bzb...@ (Boris Zbarsky) Date: Wed, 29 Aug 2012 17:49:56 -0400 Subject: [Public WebGL] Bufferdata behavior In-Reply-To: <503E8955.9070301@dfki.de> References: <503E8955.9070301@dfki.de> Message-ID: <503E8E84.9010509@mit.edu> On 8/29/12 5:27 PM, Kristian Sons wrote: > just found following inconsistent behavior in my (buggy) code :) > > bufferData(GLenum target, ArrayBufferView data, GLenum usage) > > If data is null Firefox and Chrome on Windows have the specified > behavior: INVALID_VALUE. > If data is undefined, it seems that Firefox creates a zero sized buffer, > while Chrome seems to just ignore that call. Just to check, which version of Firefox were you testing? Firefox 15 switched the WebGLRenderingContext to WebIDL, so if you're testing an earlier version the behavior may be different from Firefox 15 and later. In any case, per spec as it currently stands (and in Firefox 15 and later, based on code inspection), null and undefined should do the same thing. In particular, if you pass either one, you will call this overload: void bufferData(GLenum target, ArrayBuffer? data, GLenum usage); and null will be passed for the data to the underlying implementation. -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kri...@ Thu Aug 30 00:12:28 2012 From: kri...@ (Kristian Sons) Date: Thu, 30 Aug 2012 09:12:28 +0200 Subject: [Public WebGL] Bufferdata behavior In-Reply-To: <503E8E84.9010509@mit.edu> References: <503E8955.9070301@dfki.de> <503E8E84.9010509@mit.edu> Message-ID: <503F125C.3040304@dfki.de> Hi, the described behavior was in Firefox 14, I tested the same code on Firefox 15 and it's as you said and as I would expect: Same behavior for null and undefined (INVALID_VALUE) Using Chrome 21.0.1180.83, I don't get INVALID_VALUE with undefined. Kristian > > On 8/29/12 5:27 PM, Kristian Sons wrote: >> just found following inconsistent behavior in my (buggy) code :) >> >> bufferData(GLenum target, ArrayBufferView data, GLenum usage) >> >> If data is null Firefox and Chrome on Windows have the specified >> behavior: INVALID_VALUE. >> If data is undefined, it seems that Firefox creates a zero sized buffer, >> while Chrome seems to just ignore that call. > > Just to check, which version of Firefox were you testing? Firefox 15 > switched the WebGLRenderingContext to WebIDL, so if you're testing an > earlier version the behavior may be different from Firefox 15 and later. > > In any case, per spec as it currently stands (and in Firefox 15 and > later, based on code inspection), null and undefined should do the > same thing. In particular, if you pass either one, you will call this > overload: > > void bufferData(GLenum target, ArrayBuffer? data, GLenum usage); > > and null will be passed for the data to the underlying implementation. > > -Boris > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > -- ________________________________________________________ Kristian Sons Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realit?t Campus, Geb. D 3 2, Raum 0.77 66123 Saarbr?cken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775?2235 kristian.sons...@ http://www.xml3d.org Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ________________________________________________________ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Aug 30 02:10:58 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 30 Aug 2012 11:10:58 +0200 Subject: [Public WebGL] Bufferdata behavior In-Reply-To: <503F125C.3040304@dfki.de> References: <503E8955.9070301@dfki.de> <503E8E84.9010509@mit.edu> <503F125C.3040304@dfki.de> Message-ID: Proposing new conformance test for null and undefined data https://github.com/KhronosGroup/WebGL/pull/21 On Thu, Aug 30, 2012 at 9:12 AM, Kristian Sons wrote: > > Hi, > > the described behavior was in Firefox 14, I tested the same code on > Firefox 15 and it's as you said and as I would expect: Same behavior for > null and undefined (INVALID_VALUE) > > Using Chrome 21.0.1180.83, I don't get INVALID_VALUE with undefined. > > Kristian > > > >> On 8/29/12 5:27 PM, Kristian Sons wrote: >> >>> just found following inconsistent behavior in my (buggy) code :) >>> >>> bufferData(GLenum target, ArrayBufferView data, GLenum usage) >>> >>> If data is null Firefox and Chrome on Windows have the specified >>> behavior: INVALID_VALUE. >>> If data is undefined, it seems that Firefox creates a zero sized buffer, >>> while Chrome seems to just ignore that call. >>> >> >> Just to check, which version of Firefox were you testing? Firefox 15 >> switched the WebGLRenderingContext to WebIDL, so if you're testing an >> earlier version the behavior may be different from Firefox 15 and later. >> >> In any case, per spec as it currently stands (and in Firefox 15 and >> later, based on code inspection), null and undefined should do the same >> thing. In particular, if you pass either one, you will call this overload: >> >> void bufferData(GLenum target, ArrayBuffer? data, GLenum usage); >> >> and null will be passed for the data to the underlying implementation. >> >> -Boris >> >> ------------------------------**----------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ------------------------------**----------------------------- >> >> > > -- > ______________________________**__________________________ > > Kristian Sons > Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI > Agenten und Simulierte Realit?t > Campus, Geb. D 3 2, Raum 0.77 > 66123 Saarbr?cken, Germany > > Phone: +49 681 85775-3833 > Phone: +49 681 302-3833 > Fax: +49 681 85775?2235 > kristian.sons...@ > http://www.xml3d.org > > Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > > Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes > Amtsgericht Kaiserslautern, HRB 2313 > ______________________________**__________________________ > > > ------------------------------**----------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ------------------------------**----------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: