From jda...@  Sat Jul  4 14:33:23 2015
From: jda...@ (John Davis)
Date: Sat, 4 Jul 2015 17:33:23 -0400
Subject: [Public WebGL] Webgl2
Message-ID: <CAMx_cqa16omw6XzTwbrKyd1o8aqkG_rtW6kZOG1D8C7Ncs90Bg@mail.gmail.com>

we getting close to finalizing the spec?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150704/8a284283/attachment.html>

From ash...@  Mon Jul  6 09:32:01 2015
From: ash...@ (Ashley Gullen)
Date: Mon, 6 Jul 2015 17:32:01 +0100
Subject: [Public WebGL] Encoding compressed texture formats
Message-ID: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com>

I think this may have been discussed briefly on this list a year or two
ago, but I wanted to bring it up again now WebGL 2 is in the works with a
mandatory supported ETC2/EAC.

While compressed textures are good for saving GPU memory and improving
rendering performance, they are less suitable for delivery over the web.
PNG/JPEG can get much higher compression ratios and can considerably reduce
the download size of a web app. While delivering the compressed textures
over the web is one solution, it would be nice for web apps to have the
option of delivering PNG/JPEG content and encoding to ETC2/EAC on startup.

The obvious solution might be to allow passing HTMLImageElement etc.
directly to compressedTexImage2D etc. However for a large app (or even a
small/medium one on a slow device) the startup time may be significantly
increased by the encoding work to be done. I think it would be better if we
had a way to encode images to a Blob or ArrayBuffer representing the image
in a compressed format, so that this can be cached with IndexedDB or some
other local storage mechanism, and retrieved more quickly on subsequent
loads. So perhaps there could be a method like:

Promise<ArrayBuffer> encodeCompressedTexture(image, format);

Perhaps this could be a static method on the WebGL context, since I don't
see why it needs a context to be created to work.

I can't find many sources but it doesn't look like there are any patents
covering the ETC2/EAC texture formats, so it seems browsers should be able
to ship encoders. An alternative is to compile an encoder with
asm.js/WebAssembly and run it in a worker. I'm not sure how implementors
feel about whether features like this should be in frameworks or
implemented natively, but I wanted to raise the suggestion. Implementing
natively would guarantee maximum performance and avoid having to ship extra
code with the web app for the encoder. Even if it is left to be implemented
in a JS library, it would be nice to have an official open-source reference
implementation to work with.

Ashley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150706/22d37582/attachment.html>

From din...@  Mon Jul  6 12:21:12 2015
From: din...@ (Dean Jackson)
Date: Tue, 7 Jul 2015 05:21:12 +1000
Subject: [Public WebGL] Webgl2
In-Reply-To: <CAMx_cqa16omw6XzTwbrKyd1o8aqkG_rtW6kZOG1D8C7Ncs90Bg@mail.gmail.com>
References: <CAMx_cqa16omw6XzTwbrKyd1o8aqkG_rtW6kZOG1D8C7Ncs90Bg@mail.gmail.com>
Message-ID: <7C532649-6D75-4BBE-9624-B108D213F20C@apple.com>



> On 5 Jul 2015, at 7:33 AM, John Davis <jdavis...@> wrote:
> 
> we getting close to finalizing the spec?

There are a few prototype implementations:

- Mozilla (fairly comprehensive)
- Google (started recently)
- Apple (bare bones)
- maybe others that I've forgotten!

Once there is interoperability there the spec will finalize. It's not a spec problem at the moment. The implementations need to improve.

If you want to push things along, test the implementations, file bugs, write content, submit tests, etc.

Dean


-----------------------------------------------------------
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 Jul  6 12:59:01 2015
From: kbr...@ (Kenneth Russell)
Date: Mon, 6 Jul 2015 12:59:01 -0700
Subject: [Public WebGL] Encoding compressed texture formats
In-Reply-To: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com>
References: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com>
Message-ID: <CAMYvS2ebfzhJcZ_ift=J2UjeeapkOdq5ri41Ln4oTCTv0-f6ug@mail.gmail.com>


It's much more flexible for applications to implement this sort of
functionality in a library rather than having the browser compile in
an encoder. For one thing, ASTC is likely to supplant the mandatory
formats in ES 3.0 soon, so an ETC2/EAC encoder built in the browser
might be obsolete almost as soon as it ships.

Have you looked at https://code.google.com/p/crunch/ ? Evan Parker and
Brandon Jones did some work compiling Crunch to asm.js using
Emscripten a while back, and that approach is viable -- it's shipping
in Google Maps today.

-Ken



On Mon, Jul 6, 2015 at 9:32 AM, Ashley Gullen <ashley...@> wrote:
> I think this may have been discussed briefly on this list a year or two ago,
> but I wanted to bring it up again now WebGL 2 is in the works with a
> mandatory supported ETC2/EAC.
>
> While compressed textures are good for saving GPU memory and improving
> rendering performance, they are less suitable for delivery over the web.
> PNG/JPEG can get much higher compression ratios and can considerably reduce
> the download size of a web app. While delivering the compressed textures
> over the web is one solution, it would be nice for web apps to have the
> option of delivering PNG/JPEG content and encoding to ETC2/EAC on startup.
>
> The obvious solution might be to allow passing HTMLImageElement etc.
> directly to compressedTexImage2D etc. However for a large app (or even a
> small/medium one on a slow device) the startup time may be significantly
> increased by the encoding work to be done. I think it would be better if we
> had a way to encode images to a Blob or ArrayBuffer representing the image
> in a compressed format, so that this can be cached with IndexedDB or some
> other local storage mechanism, and retrieved more quickly on subsequent
> loads. So perhaps there could be a method like:
>
> Promise<ArrayBuffer> encodeCompressedTexture(image, format);
>
> Perhaps this could be a static method on the WebGL context, since I don't
> see why it needs a context to be created to work.
>
> I can't find many sources but it doesn't look like there are any patents
> covering the ETC2/EAC texture formats, so it seems browsers should be able
> to ship encoders. An alternative is to compile an encoder with
> asm.js/WebAssembly and run it in a worker. I'm not sure how implementors
> feel about whether features like this should be in frameworks or implemented
> natively, but I wanted to raise the suggestion. Implementing natively would
> guarantee maximum performance and avoid having to ship extra code with the
> web app for the encoder. Even if it is left to be implemented in a JS
> library, it would be nice to have an official open-source reference
> implementation to work with.
>
> Ashley
>

-----------------------------------------------------------
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 Jul  6 13:02:02 2015
From: kbr...@ (Kenneth Russell)
Date: Mon, 6 Jul 2015 13:02:02 -0700
Subject: [Public WebGL] Encoding compressed texture formats
In-Reply-To: <CAMYvS2ebfzhJcZ_ift=J2UjeeapkOdq5ri41Ln4oTCTv0-f6ug@mail.gmail.com>
References: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com>
	<CAMYvS2ebfzhJcZ_ift=J2UjeeapkOdq5ri41Ln4oTCTv0-f6ug@mail.gmail.com>
Message-ID: <CAMYvS2cdMS2g2_-1QyFobz9f5YevKSxH10jjrV=5Gk5T6s9L5A@mail.gmail.com>


Correction: to the best of my knowledge it's shipping in Google Maps today.


On Mon, Jul 6, 2015 at 12:59 PM, Kenneth Russell <kbr...@> wrote:
> It's much more flexible for applications to implement this sort of
> functionality in a library rather than having the browser compile in
> an encoder. For one thing, ASTC is likely to supplant the mandatory
> formats in ES 3.0 soon, so an ETC2/EAC encoder built in the browser
> might be obsolete almost as soon as it ships.
>
> Have you looked at https://code.google.com/p/crunch/ ? Evan Parker and
> Brandon Jones did some work compiling Crunch to asm.js using
> Emscripten a while back, and that approach is viable -- it's shipping
> in Google Maps today.
>
> -Ken
>
>
>
> On Mon, Jul 6, 2015 at 9:32 AM, Ashley Gullen <ashley...@> wrote:
>> I think this may have been discussed briefly on this list a year or two ago,
>> but I wanted to bring it up again now WebGL 2 is in the works with a
>> mandatory supported ETC2/EAC.
>>
>> While compressed textures are good for saving GPU memory and improving
>> rendering performance, they are less suitable for delivery over the web.
>> PNG/JPEG can get much higher compression ratios and can considerably reduce
>> the download size of a web app. While delivering the compressed textures
>> over the web is one solution, it would be nice for web apps to have the
>> option of delivering PNG/JPEG content and encoding to ETC2/EAC on startup.
>>
>> The obvious solution might be to allow passing HTMLImageElement etc.
>> directly to compressedTexImage2D etc. However for a large app (or even a
>> small/medium one on a slow device) the startup time may be significantly
>> increased by the encoding work to be done. I think it would be better if we
>> had a way to encode images to a Blob or ArrayBuffer representing the image
>> in a compressed format, so that this can be cached with IndexedDB or some
>> other local storage mechanism, and retrieved more quickly on subsequent
>> loads. So perhaps there could be a method like:
>>
>> Promise<ArrayBuffer> encodeCompressedTexture(image, format);
>>
>> Perhaps this could be a static method on the WebGL context, since I don't
>> see why it needs a context to be created to work.
>>
>> I can't find many sources but it doesn't look like there are any patents
>> covering the ETC2/EAC texture formats, so it seems browsers should be able
>> to ship encoders. An alternative is to compile an encoder with
>> asm.js/WebAssembly and run it in a worker. I'm not sure how implementors
>> feel about whether features like this should be in frameworks or implemented
>> natively, but I wanted to raise the suggestion. Implementing natively would
>> guarantee maximum performance and avoid having to ship extra code with the
>> web app for the encoder. Even if it is left to be implemented in a JS
>> library, it would be nice to have an official open-source reference
>> implementation to work with.
>>
>> Ashley
>>

-----------------------------------------------------------
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 jgi...@  Mon Jul  6 13:08:04 2015
From: jgi...@ (Jeff Gilbert)
Date: Mon, 6 Jul 2015 13:08:04 -0700
Subject: [Public WebGL] Encoding compressed texture formats
In-Reply-To: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com>
References: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com>
Message-ID: <CAOztSJ1GwfgKASbfTOh1DmMeL762vdAZP678gfR+4WGpQipBsw@mail.gmail.com>

Adding an encoder into the browser is not attractive. If anything is
missing from the platform that makes a JS library infeasible, we should
work to add it in.

On Mon, Jul 6, 2015 at 9:32 AM, Ashley Gullen <ashley...@> wrote:

> I think this may have been discussed briefly on this list a year or two
> ago, but I wanted to bring it up again now WebGL 2 is in the works with a
> mandatory supported ETC2/EAC.
>
> While compressed textures are good for saving GPU memory and improving
> rendering performance, they are less suitable for delivery over the web.
> PNG/JPEG can get much higher compression ratios and can considerably reduce
> the download size of a web app. While delivering the compressed textures
> over the web is one solution, it would be nice for web apps to have the
> option of delivering PNG/JPEG content and encoding to ETC2/EAC on startup.
>
> The obvious solution might be to allow passing HTMLImageElement etc.
> directly to compressedTexImage2D etc. However for a large app (or even a
> small/medium one on a slow device) the startup time may be significantly
> increased by the encoding work to be done. I think it would be better if we
> had a way to encode images to a Blob or ArrayBuffer representing the image
> in a compressed format, so that this can be cached with IndexedDB or some
> other local storage mechanism, and retrieved more quickly on subsequent
> loads. So perhaps there could be a method like:
>
> Promise<ArrayBuffer> encodeCompressedTexture(image, format);
>
> Perhaps this could be a static method on the WebGL context, since I don't
> see why it needs a context to be created to work.
>
> I can't find many sources but it doesn't look like there are any patents
> covering the ETC2/EAC texture formats, so it seems browsers should be able
> to ship encoders. An alternative is to compile an encoder with
> asm.js/WebAssembly and run it in a worker. I'm not sure how implementors
> feel about whether features like this should be in frameworks or
> implemented natively, but I wanted to raise the suggestion. Implementing
> natively would guarantee maximum performance and avoid having to ship extra
> code with the web app for the encoder. Even if it is left to be implemented
> in a JS library, it would be nice to have an official open-source reference
> implementation to work with.
>
> Ashley
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150706/cee95bbc/attachment.html>

From khr...@  Tue Jul  7 04:33:25 2015
From: khr...@ (Mark Callow)
Date: Tue, 7 Jul 2015 20:33:25 +0900
Subject: [Public WebGL] Encoding compressed texture formats
In-Reply-To: <CAMYvS2ebfzhJcZ_ift=J2UjeeapkOdq5ri41Ln4oTCTv0-f6ug@mail.gmail.com>
References: <CAABs73hsHEE+a51Zec3-p10R4xN=mgKohXcHzdKFw_bfLgUq9g@mail.gmail.com> <CAMYvS2ebfzhJcZ_ift=J2UjeeapkOdq5ri41Ln4oTCTv0-f6ug@mail.gmail.com>
Message-ID: <5071D1B0-857F-4E60-A99D-D38EC68E0E31@callow.im>


> On Jul 7, 2015, at 4:59 AM, Kenneth Russell <kbr...@> wrote:
> 
> Have you looked at https://code.google.com/p/crunch/ ? Evan Parker and
> Brandon Jones did some work compiling Crunch to asm.js using
> Emscripten a while back, and that approach is viable -- it's shipping
> in Google Maps today.

I think the crunch approach is much more viable than transcoding from JPG to a compressed tex format after download. Encoding to ASTC, for example, is not the fastest thing on the planet. And down the road when you want array and 3D textures, you might find that ASTC is rather better than an array of JPEGS.

Regards

    -Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150707/b7178a50/attachment.asc>

From jgi...@  Tue Jul  7 13:12:30 2015
From: jgi...@ (Jeff Gilbert)
Date: Tue, 7 Jul 2015 13:12:30 -0700
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
Message-ID: <CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>

There's no ability to have different antialias/stencil/depth, but different
size is fine. (And with WebGL2, if you do your own multisampling, you can
also do your own spencil/depth)

Drawing into 10 canvases is fine: Resize as needed, draw, detach the
imageBitmap, attach imageBitmap to canvasN, repeat.
I can throw together some code for examples.

On Tue, Jun 30, 2015 at 12:41 PM, Dean Jackson <dino...@> wrote:

> [culling the CC list]
>
> On 1 Jul 2015, at 5:39 AM, Florian B?sch <pyalot...@> wrote:
>
> A few example uses of the the proposed API would help. Far as I understand
> this proposal an offscreen canvas is used to obtain a context and then you
> can transfer whatever is in the offscreen canvas to another canvas (either
> all on the main thread or from a worker).
>
> I'm not quite clear how it should work to define several backing stores
> with different settings for antialias, stencil, depth and size that serve
> as the target to render into. It seems to me that you're pretty much frozen
> into whatever you setup the offscreen canvas to be.
>
>
> Yeah, I was trying to work out how it would look actually using this API
> to draw into, say, 10 canvases in the main page.
>
> Examples would be great. I'd suggest a one to many, and a worker example.
>
> Dean
>
>
>
>
> On Tue, Jun 30, 2015 at 8:32 PM, Kenneth Russell <kbr...@> wrote:
>
>> I also agree that this is an important use case and that the upgrade
>> to WebGL 2.0 is an excellent opportunity to address it. Apologies for
>> not being more vocal on the topic, but am pretty swamped. The API
>> proposal at https://wiki.whatwg.org/wiki/OffscreenCanvas should
>> hopefully address this use case and a couple of others, and isn't tied
>> directly to the WebGL API. Feedback on the proposal would be
>> appreciated. I have some outstanding work to do on it including
>> putting together example code. Firefox is prototyping some of the API
>> in https://bugzilla.mozilla.org/show_bug.cgi?id=709490 , and the
>> Chrome team intends to start a prototype soon.
>>
>>
>> On Tue, Jun 30, 2015 at 11:26 AM, Dean Jackson <dino...@> wrote:
>> > I agree this is an important use case, and that we should address it
>> now.
>> > The most obvious example would be a dashboard application of some sort
>> with
>> > lots of little widgets - having a separate context for each widget is
>> > unreasonable and wasteful.
>> >
>> > Dean
>> >
>> > On 30 Jun 2015, at 7:51 PM, Florian B?sch <pyalot...@> wrote:
>> >
>> > I believe that an excellent opportunity to address this issue
>> conclusively
>> > is being wasted by not incorporating appropriate APIs into WebGL2.
>> >
>> > On Wed, Jun 24, 2015 at 4:30 PM, Florian B?sch <pyalot...@>
>> wrote:
>> >>
>> >> Rendering to multiple canvases from one WebGL context is still an
>> unsolved
>> >> problem.
>> >
>> >
>> >
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150707/578bf25a/attachment.html>

From khr...@  Tue Jul  7 18:31:06 2015
From: khr...@ (Mark Callow)
Date: Wed, 8 Jul 2015 10:31:06 +0900
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com> <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com> <CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com> <5114B8F1.9040706@jetbrains.com> <CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com> <CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com> <CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com> <CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com> <CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com> <CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com> <CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com> <CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com> <CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com> <CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com> <CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com> <CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com> <CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com> <CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com> <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> <CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com> <CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com> <19857AD9-000A-40CF-807C-526BCB978DDC@apple.com> <CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
Message-ID: <1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>


> On Jul 8, 2015, at 5:12 AM, Jeff Gilbert <jgilbert...@> wrote:
> 
> There's no ability to have different antialias/stencil/depth, but different size is fine. (And with WebGL2, if you do your own multisampling, you can also do your own spencil/depth)
> 
> Drawing into 10 canvases is fine: Resize as needed, draw, detach the imageBitmap, attach imageBitmap to canvasN, repeat.
> I can throw together some code for examples.
> 

Do bits have to be copied from the offscreen canvas to the final destination canvas?s backing store? If so, then this is not a suitable solution. Or does the offscreen canvas act as a backing store for all the destination canvases?

I think an ideal solution would be to be able to create a WebGL context without any canvas, and be able to attach any canvas to one of an FBO's color buffer attachment points. The application would be responsible for creating the depth and stencil buffers it wishes to use. Switching between canvases then becomes a matter of binding a different FBO. I?ll have to look at the specs again to see how antialias would fit into this scheme.

Regards

    -Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150708/abf210d2/attachment.asc>

From jgi...@  Tue Jul  7 19:39:57 2015
From: jgi...@ (Jeff Gilbert)
Date: Tue, 7 Jul 2015 19:39:57 -0700
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
	<CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
	<1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
Message-ID: <CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>

On Tue, Jul 7, 2015 at 6:31 PM, Mark Callow <khronos...@> wrote:

> Do bits have to be copied from the offscreen canvas to the final
> destination canvas?s backing store? If so, then this is not a suitable
> solution. Or does the offscreen canvas act as a backing store for all the
> destination canvases?
>

No, copies are not required.


> I think an ideal solution would be to be able to create a WebGL context
> without any canvas, and be able to attach any canvas to one of an FBO's
> color buffer attachment points. The application would be responsible for
> creating the depth and stencil buffers it wishes to use. Switching between
> canvases then becomes a matter of binding a different FBO. I?ll have to
> look at the specs again to see how antialias would fit into this scheme.
>

Headless contexts is ideal, yes. However, this would preclude using certain
APIs for composition (such as EGLSurface), as well as preventing any
optimizations like drawing directly to the screen in full-screen mode.

Antialiasing isn't that big a deal, since you can (and should) do it
yourself in WebGL 2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150707/878ecaa7/attachment.html>

From jda...@  Thu Jul  9 04:58:14 2015
From: jda...@ (John Davis)
Date: Thu, 9 Jul 2015 07:58:14 -0400
Subject: [Public WebGL] Apple TV
Message-ID: <CAOyxrtQnBfd1Y03en52H_16t=AY=cU7L3Pg-v7-M2_zPevLo8Q@mail.gmail.com>

I see rumors that Apple TV will soon be open to app devs.  Anybody heard if
there will be webgl support?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150709/76f91ab3/attachment.html>

From khr...@  Thu Jul  9 05:21:34 2015
From: khr...@ (Mark Callow)
Date: Thu, 9 Jul 2015 21:21:34 +0900
Subject: [Public WebGL] Apple TV
In-Reply-To: <CAOyxrtQnBfd1Y03en52H_16t=AY=cU7L3Pg-v7-M2_zPevLo8Q@mail.gmail.com>
References: <CAOyxrtQnBfd1Y03en52H_16t=AY=cU7L3Pg-v7-M2_zPevLo8Q@mail.gmail.com>
Message-ID: <D3F08B0E-B774-4D57-9C41-4E378A751238@callow.im>


> On Jul 9, 2015, at 8:58 PM, John Davis <jdavis...@> wrote:
> 
> I see rumors that Apple TV will soon be open to app devs.  Anybody heard if there will be webgl support?
> 

Aren?t these two things orthogonal?

Regards

    -Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150709/08c60256/attachment.asc>

From pya...@  Thu Jul  9 05:54:37 2015
From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=)
Date: Thu, 9 Jul 2015 14:54:37 +0200
Subject: [Public WebGL] Apple TV
In-Reply-To: <D3F08B0E-B774-4D57-9C41-4E378A751238@callow.im>
References: <CAOyxrtQnBfd1Y03en52H_16t=AY=cU7L3Pg-v7-M2_zPevLo8Q@mail.gmail.com>
	<D3F08B0E-B774-4D57-9C41-4E378A751238@callow.im>
Message-ID: <CAOK8ODjAim16CV9nC6+S_=4JZR6Ng-zN6NRxMte5ykTBx6Jj0w@mail.gmail.com>

I should point out that it pretty much doesn't matter if SmartTV's (and
within that the subcategory AppleTV) supports WebGL (in its browser).

The reason is that SmartTV's (all of them) only occupy less than 0.1% of
pageviews. And AppleTV holds less than 12% of that category. People, by far
and large, don't use their SmartTV to browse web-pages. So it doesn't
matter what the browser they would use support, because you simply never
see anybody visiting with one of those UAs.

On Thu, Jul 9, 2015 at 2:21 PM, Mark Callow <khronos...@> wrote:

>
> > On Jul 9, 2015, at 8:58 PM, John Davis <jdavis...@> wrote:
> >
> > I see rumors that Apple TV will soon be open to app devs.  Anybody heard
> if there will be webgl support?
> >
>
> Aren?t these two things orthogonal?
>
> Regards
>
>     -Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150709/13cfe0b0/attachment.html>

From ale...@  Thu Jul  9 09:14:44 2015
From: ale...@ (Aleksandar Rodic)
Date: Thu, 09 Jul 2015 16:14:44 +0000
Subject: [Public WebGL] Apple TV
In-Reply-To: <CAOK8ODjAim16CV9nC6+S_=4JZR6Ng-zN6NRxMte5ykTBx6Jj0w@mail.gmail.com>
References: <CAOyxrtQnBfd1Y03en52H_16t=AY=cU7L3Pg-v7-M2_zPevLo8Q@mail.gmail.com>
 <D3F08B0E-B774-4D57-9C41-4E378A751238@callow.im> <CAOK8ODjAim16CV9nC6+S_=4JZR6Ng-zN6NRxMte5ykTBx6Jj0w@mail.gmail.com>
Message-ID: <CA++dbRrfygmapG2urFhoOKexumUwDBi9oi-81B=UkomQ84EpdA@mail.gmail.com>

This would matter if it was possible to publish SmartTV apps wrapped in
WebView of some sort. Otherwise, I agree with Florian.

~Aki

On Thu, Jul 9, 2015 at 2:55 PM Florian B?sch <pyalot...@> wrote:

> I should point out that it pretty much doesn't matter if SmartTV's (and
> within that the subcategory AppleTV) supports WebGL (in its browser).
>
> The reason is that SmartTV's (all of them) only occupy less than 0.1% of
> pageviews. And AppleTV holds less than 12% of that category. People, by far
> and large, don't use their SmartTV to browse web-pages. So it doesn't
> matter what the browser they would use support, because you simply never
> see anybody visiting with one of those UAs.
>
> On Thu, Jul 9, 2015 at 2:21 PM, Mark Callow <khronos...@> wrote:
>
>>
>> > On Jul 9, 2015, at 8:58 PM, John Davis <jdavis...@>
>> wrote:
>> >
>> > I see rumors that Apple TV will soon be open to app devs.  Anybody
>> heard if there will be webgl support?
>> >
>>
>> Aren?t these two things orthogonal?
>>
>> Regards
>>
>>     -Mark
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150709/c997d277/attachment.html>

From jam...@  Thu Jul  9 15:01:42 2015
From: jam...@ (James Bedford)
Date: Thu, 09 Jul 2015 15:01:42 -0700
Subject: [Public WebGL] Apple TV
In-Reply-To:  <CA++dbRrfygmapG2urFhoOKexumUwDBi9oi-81B=UkomQ84EpdA@mail.gmail.com>
References:  <CAOyxrtQnBfd1Y03en52H_16t=AY=cU7L3Pg-v7-M2_zPevLo8Q@mail.gmail.com>
 <D3F08B0E-B774-4D57-9C41-4E378A751238@callow.im>
 <CAOK8ODjAim16CV9nC6+S_=4JZR6Ng-zN6NRxMte5ykTBx6Jj0w@mail.gmail.com>
 <CA++dbRrfygmapG2urFhoOKexumUwDBi9oi-81B=UkomQ84EpdA@mail.gmail.com>
Message-ID: <0FC73A04-14BD-47E6-BD1C-28063E566171@me.com>

I don?t think there?s anything to be achieved from this thread other than speculation, but here?s a comment.

> People, by far and large, don't use their SmartTV to browse web-pages.

Today?s usage doesn?t necessarily indicate tomorrow?s usage.

James

> On Jul 9, 2015, at 9:14 AM, Aleksandar Rodic <aleksandar.xyz...@> wrote:
> 
> This would matter if it was possible to publish SmartTV apps wrapped in WebView of some sort. Otherwise, I agree with Florian.
> 
> ~Aki
> 
> On Thu, Jul 9, 2015 at 2:55 PM Florian B?sch <pyalot...@ <mailto:pyalot...@>> wrote:
> I should point out that it pretty much doesn't matter if SmartTV's (and within that the subcategory AppleTV) supports WebGL (in its browser).
> 
> The reason is that SmartTV's (all of them) only occupy less than 0.1% of pageviews. And AppleTV holds less than 12% of that category. People, by far and large, don't use their SmartTV to browse web-pages. So it doesn't matter what the browser they would use support, because you simply never see anybody visiting with one of those UAs.
> 
> On Thu, Jul 9, 2015 at 2:21 PM, Mark Callow <khronos...@ <mailto:khronos...@>> wrote:
> 
> > On Jul 9, 2015, at 8:58 PM, John Davis <jdavis...@ <mailto:jdavis...@>> wrote:
> >
> > I see rumors that Apple TV will soon be open to app devs.  Anybody heard if there will be webgl support?
> >
> 
> Aren?t these two things orthogonal?
> 
> Regards
> 
>     -Mark
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150709/9948250a/attachment.html>

From oet...@  Fri Jul 10 00:27:05 2015
From: oet...@ (Olli Etuaho)
Date: Fri, 10 Jul 2015 07:27:05 +0000
Subject: [Public WebGL] Heads-up: WebGL is starting to enforce ESSL global variable
 initialization spec more strictly
Message-ID: <1436513224147.78339@nvidia.com>

Hi all,


this is a heads-up on changes that were recently made to make WebGL follow the ESSL spec more closely. The ESSL 1.00 spec section 4.3 says that global variable initializers should be constant expressions, but for a long time major WebGL implementations have had a bug where they haven't checked this. At this point it's impossible to fix this completely without introducing compatibility issues, but a more lenient form of this restriction was recently implemented in ANGLE. Basically, we allow any global variables, uniforms and most math operations to be used in global variable initializers, but nothing else. For example, you can't sample textures in the global scope any more, or use operators which require an l-value, such as ++ or --.


?The change was tested with most of the major WebGL libraries and engines and several shader demos, and no issues were found. However, if this is causing major compatibility issues with some content that wasn't tested yet, we'd like to hear about it and possibly take steps to make the spec more lenient. The change should be visible in Chrome Canary in a few days.


-Olli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150710/574ff9ea/attachment.html>

From khr...@  Sun Jul 12 19:55:29 2015
From: khr...@ (Mark Callow)
Date: Mon, 13 Jul 2015 11:55:29 +0900
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com> <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com> <CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com> <5114B8F1.9040706@jetbrains.com> <CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com> <CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com> <CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com> <CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com> <CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com> <CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com> <CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com> <CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com> <CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com> <CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com> <CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com> <CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com> <CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com> <CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com> <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> <CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com> <CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com> <19857AD9-000A-40CF-807C-526BCB978DDC@apple.com> <CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com> <1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im> <CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
Message-ID: <5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>


> On Jul 8, 2015, at 11:39 AM, Jeff Gilbert <jgilbert...@> wrote:
> 
> Headless contexts is ideal, yes. However, this would preclude using certain APIs for composition (such as EGLSurface), as well as preventing any optimizations like drawing directly to the screen in full-screen mode.
> 

WebGL implementations have a layer between the application and OpenGL ES/EGL. I think that layer could manage using EGL surfaces for canvases, if that what the browser wants for composition, and drawing directly when in full screen. I thought browsers typically backed canvases with textures, in which case full screen is the only area of concern.

Regards

    -Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150713/3343fe2c/attachment.asc>

From kbr...@  Mon Jul 13 17:39:22 2015
From: kbr...@ (Kenneth Russell)
Date: Mon, 13 Jul 2015 17:39:22 -0700
Subject: [Public WebGL] Heads-up: WebGL is starting to enforce ESSL global
 variable initialization spec more strictly
In-Reply-To: <1436513224147.78339@nvidia.com>
References: <1436513224147.78339@nvidia.com>
Message-ID: <CAMYvS2dSbV7yDCZMShd90YPfNjZUVOgrfQtzNOvC9KVX2wvQtg@mail.gmail.com>


Thanks Olli for identifying these longstanding problems and tightening
up the specification, implementations and tests. The spec change is
here:
  https://www.khronos.org/registry/webgl/specs/latest/1.0/#6.30

GLSL ES implementations have been lenient about enforcing these rules
in the past, but in possibly inconsistent ways. Tightening up WebGL's
rules in this area will help ensure that shaders remain portable
across many types of devices.

WebGL 2.0 implementations will fully enforce ESSL 3.00's global
variable initialization rules, since it's expected that some porting
work will be needed anyway when upgrading from WebGL 1.0 to 2.0. This
will again help ensure content remains portable.

If anyone discovers that certain shaders aren't compiling anymore in
Chrome Canary, please post here right away. Thanks everyone for your
help.

-Ken



On Fri, Jul 10, 2015 at 12:27 AM, Olli Etuaho <oetuaho...@> wrote:
> Hi all,
>
>
> this is a heads-up on changes that were recently made to make WebGL follow
> the ESSL spec more closely. The ESSL 1.00 spec section 4.3 says that global
> variable initializers should be constant expressions, but for a long time
> major WebGL implementations have had a bug where they haven't checked this.
> At this point it's impossible to fix this completely without introducing
> compatibility issues, but a more lenient form of this restriction was
> recently implemented in ANGLE. Basically, we allow any global variables,
> uniforms and most math operations to be used in global variable
> initializers, but nothing else. For example, you can't sample textures in
> the global scope any more, or use operators which require an l-value, such
> as ++ or --.
>
>
> The change was tested with most of the major WebGL libraries and engines and
> several shader demos, and no issues were found. However, if this is causing
> major compatibility issues with some content that wasn't tested yet, we'd
> like to hear about it and possibly take steps to make the spec more lenient.
> The change should be visible in Chrome Canary in a few days.
>
>
> -Olli

-----------------------------------------------------------
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...@  Wed Jul 22 19:16:30 2015
From: kbr...@ (Kenneth Russell)
Date: Wed, 22 Jul 2015 19:16:30 -0700
Subject: [Public WebGL] Call for participation: SIGGRAPH 2015 WebGL and glTF BOF
Message-ID: <CAMYvS2dsc+9uDx31b+RQyzJEAb-O7tnvw9L1aFgz1+NJjF9mUw@mail.gmail.com>


[cross-posted to webgl-dev-list]

The Khronos Group cordially invites you to the WebGL and glTF BOF at
SIGGRAPH 2015 on Wednesday, August 12, from 3:45 PM to 5:00 PM. The
detailed schedule of all Khronos BOFs is published at
https://www.khronos.org/news/events/2015-siggraph .

The agenda of the BOF will be:

 1) Updates on the WebGL 1.0 and 2.0 specs and implementations
 2) Updates on the glTF specification -- "JPEG for 3D"
 3) Lightning talks showing leading-edge uses of WebGL in the field
 4) Q&A and community discussion

As in previous years, the working groups would like to invite the
community to participate. If you have a WebGL demonstration you'd like
to show at the BOF, please email me directly.

Looking forward to seeing you at the BOF!

-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 jgi...@  Tue Jul 28 14:28:14 2015
From: jgi...@ (Jeff Gilbert)
Date: Tue, 28 Jul 2015 14:28:14 -0700
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
	<CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
	<1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
	<CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
	<5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>
Message-ID: <CAOztSJ1pVKG0WZYXmvQhT3F82NV-7aNZw6Dhcji2qjdJw1n8+A@mail.gmail.com>

I threw together some examples:
https://github.com/jdashg/snippets/tree/master/webgl-from-worker
https://github.com/jdashg/snippets/tree/master/webgl-one-to-many

Since there's not really a browser with support for these, they're
untested.

On Sun, Jul 12, 2015 at 7:55 PM, Mark Callow <khronos...@> wrote:

>
> > On Jul 8, 2015, at 11:39 AM, Jeff Gilbert <jgilbert...@> wrote:
> >
> > Headless contexts is ideal, yes. However, this would preclude using
> certain APIs for composition (such as EGLSurface), as well as preventing
> any optimizations like drawing directly to the screen in full-screen mode.
> >
>
> WebGL implementations have a layer between the application and OpenGL
> ES/EGL. I think that layer could manage using EGL surfaces for canvases, if
> that what the browser wants for composition, and drawing directly when in
> full screen. I thought browsers typically backed canvases with textures, in
> which case full screen is the only area of concern.
>
> Regards
>
>     -Mark
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150728/c0b72075/attachment.html>

From pya...@  Tue Jul 28 14:44:10 2015
From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=)
Date: Tue, 28 Jul 2015 23:44:10 +0200
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <CAOztSJ1pVKG0WZYXmvQhT3F82NV-7aNZw6Dhcji2qjdJw1n8+A@mail.gmail.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
	<CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
	<1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
	<CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
	<5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>
	<CAOztSJ1pVKG0WZYXmvQhT3F82NV-7aNZw6Dhcji2qjdJw1n8+A@mail.gmail.com>
Message-ID: <CAOK8ODiaFSj_rcJDQiFLQu4XfsDXAF3BHP9Hi57PfhtmXRJJBA@mail.gmail.com>

Could you extend the one to many example by different canvas sizes?

On Tue, Jul 28, 2015 at 11:28 PM, Jeff Gilbert <jgilbert...@> wrote:

> I threw together some examples:
> https://github.com/jdashg/snippets/tree/master/webgl-from-worker
> https://github.com/jdashg/snippets/tree/master/webgl-one-to-many
>
> Since there's not really a browser with support for these, they're
> untested.
>
> On Sun, Jul 12, 2015 at 7:55 PM, Mark Callow <khronos...@> wrote:
>
>>
>> > On Jul 8, 2015, at 11:39 AM, Jeff Gilbert <jgilbert...@> wrote:
>> >
>> > Headless contexts is ideal, yes. However, this would preclude using
>> certain APIs for composition (such as EGLSurface), as well as preventing
>> any optimizations like drawing directly to the screen in full-screen mode.
>> >
>>
>> WebGL implementations have a layer between the application and OpenGL
>> ES/EGL. I think that layer could manage using EGL surfaces for canvases, if
>> that what the browser wants for composition, and drawing directly when in
>> full screen. I thought browsers typically backed canvases with textures, in
>> which case full screen is the only area of concern.
>>
>> Regards
>>
>>     -Mark
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150728/8dea522b/attachment.html>

From jgi...@  Tue Jul 28 15:19:59 2015
From: jgi...@ (Jeff Gilbert)
Date: Tue, 28 Jul 2015 15:19:59 -0700
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <CAOK8ODiaFSj_rcJDQiFLQu4XfsDXAF3BHP9Hi57PfhtmXRJJBA@mail.gmail.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
	<CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
	<1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
	<CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
	<5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>
	<CAOztSJ1pVKG0WZYXmvQhT3F82NV-7aNZw6Dhcji2qjdJw1n8+A@mail.gmail.com>
	<CAOK8ODiaFSj_rcJDQiFLQu4XfsDXAF3BHP9Hi57PfhtmXRJJBA@mail.gmail.com>
Message-ID: <CAOztSJ2_BH1JUD2Bes7LSKMGFBOqbDSdyShrbVDCCsHJ8izMQQ@mail.gmail.com>

Done.

On Tue, Jul 28, 2015 at 2:44 PM, Florian B?sch <pyalot...@> wrote:

> Could you extend the one to many example by different canvas sizes?
>
> On Tue, Jul 28, 2015 at 11:28 PM, Jeff Gilbert <jgilbert...@>
> wrote:
>
>> I threw together some examples:
>> https://github.com/jdashg/snippets/tree/master/webgl-from-worker
>> https://github.com/jdashg/snippets/tree/master/webgl-one-to-many
>>
>> Since there's not really a browser with support for these, they're
>> untested.
>>
>> On Sun, Jul 12, 2015 at 7:55 PM, Mark Callow <khronos...@> wrote:
>>
>>>
>>> > On Jul 8, 2015, at 11:39 AM, Jeff Gilbert <jgilbert...@>
>>> wrote:
>>> >
>>> > Headless contexts is ideal, yes. However, this would preclude using
>>> certain APIs for composition (such as EGLSurface), as well as preventing
>>> any optimizations like drawing directly to the screen in full-screen mode.
>>> >
>>>
>>> WebGL implementations have a layer between the application and OpenGL
>>> ES/EGL. I think that layer could manage using EGL surfaces for canvases, if
>>> that what the browser wants for composition, and drawing directly when in
>>> full screen. I thought browsers typically backed canvases with textures, in
>>> which case full screen is the only area of concern.
>>>
>>> Regards
>>>
>>>     -Mark
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150728/c423e0f9/attachment.html>

From pya...@  Wed Jul 29 02:47:26 2015
From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=)
Date: Wed, 29 Jul 2015 11:47:26 +0200
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <CAOztSJ2_BH1JUD2Bes7LSKMGFBOqbDSdyShrbVDCCsHJ8izMQQ@mail.gmail.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
	<CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
	<1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
	<CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
	<5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>
	<CAOztSJ1pVKG0WZYXmvQhT3F82NV-7aNZw6Dhcji2qjdJw1n8+A@mail.gmail.com>
	<CAOK8ODiaFSj_rcJDQiFLQu4XfsDXAF3BHP9Hi57PfhtmXRJJBA@mail.gmail.com>
	<CAOztSJ2_BH1JUD2Bes7LSKMGFBOqbDSdyShrbVDCCsHJ8izMQQ@mail.gmail.com>
Message-ID: <CAOK8ODg99Uwp-ta7Tc93e8VAWiH0JrSrL1z2wpg-c1T9u0ddLQ@mail.gmail.com>

Suppose we do something like this:

var offscreen = new OffscreenCanvas(512,512)
var gl = offscreen.getContext('webgl', {
  depth: true
  stencil: true
});


And then render as per example to 4 different target sizes, each of which
assigns the offscreen.width and offscreen.height, that means that
underneath the following GL commands (or equivalents) will be issued:

offscreen.width = 128;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);

offscreen.height = 128;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);


offscreen.width = 512;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);

offscreen.height = 512;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);


offscreen.width = 128;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);

offscreen.height = 128;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);


offscreen.width = 512;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);

offscreen.height = 512;

glActiveTexture(GL_TEXTURE_0);

int tmp;

glGetIntegerv(GL_TEXTURE_BINDING_2D, &currentTexture);

glBindTexture(GL_TEXTURE_2D, colorBuffer);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA,
GL_UNSIGNED_BYTE, NULL)

glBindTexture(GL_TEXTURE_2D, tmp);

glBindRenderbuffer(GL_RENDERBUFFER, stencilBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_STENCIL_INDEX8, width, height);

glBindRenderBuffer(GL_RENDERBUFFER, depthBuffer);

glRenderBufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT16, width, height);


I.e. resize color texture, stencil buffer and depth buffer 2x for each size
change, which is 4x per frame, meaning that for that GL re-allocating
buffers 24x/frame.

What performance drawback is there attached to resizing buffers constantly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150729/7ad01893/attachment.html>

From pya...@  Wed Jul 29 04:27:33 2015
From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=)
Date: Wed, 29 Jul 2015 13:27:33 +0200
Subject: [Public WebGL] using the same context with multiple canvases
In-Reply-To: <CAOK8ODg99Uwp-ta7Tc93e8VAWiH0JrSrL1z2wpg-c1T9u0ddLQ@mail.gmail.com>
References: <CAOK8ODh3mCjAA6OReYL5P0YOrJ7XEkR=Ss4--iqSn5oTJdZh5g@mail.gmail.com>
	<1323262007.46206883.1359598185356.JavaMail.root@mozilla.com>
	<CAOK8ODgXtTBOvxJn9EYA+vxcRL3LuZvtupZ3A4+62_HahYn+LA@mail.gmail.com>
	<CAKZ+BNqcQGu=mG7wBf=fBPWYJtROjW1ZaWW6EBg2y9tqJQgrpA@mail.gmail.com>
	<5114B8F1.9040706@jetbrains.com>
	<CAKZ+BNqpGj5HFMw7HrP-OgC92EhQS6SL-tyEvoJN+cx8j=k-hw@mail.gmail.com>
	<CAOK8ODio+kOarqHMtWPSQsd90AbeWDA8v2Mc=g46wFh-ac_maQ@mail.gmail.com>
	<CAJNug7vzy6r=S+AfmWMJCY=HTCgbN2c_wVx4cq2Pvm=U+gyjwg@mail.gmail.com>
	<CA++dbRop5kY-ex3orjULvpQi2YS1-a4RghXY_d=7h4XtMoKyjg@mail.gmail.com>
	<CAOK8ODhZYO_pxDY=FMAEGx_vaVc=U=NK54AVZ884pwKrwy1g+Q@mail.gmail.com>
	<CA+=MiyAhxfqiR3x4dz+K+5gHzDnz04OTqx80mMqsn4ypEExgSw@mail.gmail.com>
	<CAABs73htW7aonH7nbopKZ1fO0LNjMsWPPWnB56wv+BsmVqf4Aw@mail.gmail.com>
	<CAOK8ODjsShgcFJD51J-Vt3E3twCNNqFBszKc=1SKPL6V04ZodA@mail.gmail.com>
	<CAABs73hrcxr-+J91=EnrCPVbRykDrHnDsJNvvTt8ydQTRJZP6Q@mail.gmail.com>
	<CAOK8ODj1rVWPtThMfdTMLsZ_DW3n+i+6YU7uAsLNPUNKOG660w@mail.gmail.com>
	<CAOK8ODgcOiW6nfgKy=A3oX6Di=L7RwOpZ_B1SrtNZ7n82Cz6AA@mail.gmail.com>
	<CAOK8ODi6pR1Daqgxkg=4727LAhnrjGV+d67oH-PE9NieTCEKYQ@mail.gmail.com>
	<CAOK8ODjG+sQaVsGvdcV0NF0Xxoi3YhTuCZF8LKRH2=6u4HAo3w@mail.gmail.com>
	<CAOK8ODg3cP8ei8mu3HAtV6y5v7aFxOfks44h516prN4JMou74Q@mail.gmail.com>
	<96CD2494-528E-41F1-BABC-8874E5C28609@apple.com>
	<CAMYvS2f+==M=ZP7fkjF6qW5=_Y+uDZSgagsB3ObdKrLDmjqVxA@mail.gmail.com>
	<CAOK8ODhQgSPzc8kXAV0HPaFtUp5TbcOyP4uNEdCjzF4b_fmoZw@mail.gmail.com>
	<19857AD9-000A-40CF-807C-526BCB978DDC@apple.com>
	<CAOztSJ27PTFqtEp57-Y+fRA2KLmKZDd4U4TV=cWSTjXoAKk6pQ@mail.gmail.com>
	<1BDCDB51-A14D-4B1C-B7AA-465E0113535D@callow.im>
	<CAOztSJ3cSq0HRWqPQmCFQ5jWvtwiHL1Uybw8wDe8YBBr1BL1qA@mail.gmail.com>
	<5DFBDA07-14D4-4247-BF9E-4033B51546AE@callow.im>
	<CAOztSJ1pVKG0WZYXmvQhT3F82NV-7aNZw6Dhcji2qjdJw1n8+A@mail.gmail.com>
	<CAOK8ODiaFSj_rcJDQiFLQu4XfsDXAF3BHP9Hi57PfhtmXRJJBA@mail.gmail.com>
	<CAOztSJ2_BH1JUD2Bes7LSKMGFBOqbDSdyShrbVDCCsHJ8izMQQ@mail.gmail.com>
	<CAOK8ODg99Uwp-ta7Tc93e8VAWiH0JrSrL1z2wpg-c1T9u0ddLQ@mail.gmail.com>
Message-ID: <CAOK8ODjKhrgSZUyV7ejp-7r5ROOeRqYYuxxEf+WOgH+OSZCDLQ@mail.gmail.com>

Another aspect I'm concerned about is this:

var offscreen = new OffscreenCanvas(512,512)
var gl = offscreen.getContext('webgl', {
  preserveDrawingBuffer: true
});

offscreen.width = 128; offscreen.height = 128;

drawStuff();

offscreen.commitTo(viewA);
offscreen.width = 128; offscreen.height = 128; // err, preserve?

Doesn't seem like preserving is viable. But then, you've got to render to
an FBO, so the process becomes:

offscreen.width = 128; offscreen.height = 128;

bindFBO(viewAFBO);

drawStuff();

unbindFBO();

quadpass(viewAFBO.texture);

offscreen.commitTo(viewA);
offscreen.width = 128; offscreen.height = 128; // yay we preserve stuff in
the viewAFBO...

offscreen.width = 128; offscreen.height = 128;
bindFBO(viewBFBO);
drawStuff();
unbindFBO();
quadpass(viewBFBO.texture);
offscreen.commitTo(viewB);
offscreen.width = 128; offscreen.height = 128;


But wait, what's commitTo doing? Well, it's sampling some texture and
blitting it with a quadpass to the buffer standing in for the bitmaprender
buffer...

So we can't preserve drawing (or take more fine grained control over the
buffer we draw into) unless we create an FBO (in which case some toggles
like MSAA only become available in WebGL2). But then we're blitting stuff
around 2x each time. Somehow that's a little weird.

Now if we had some way to establish a backbuffer with the desired
properties at the desired (largely unchanging) size, we could just draw to
that. Without resize->resize->bindFBO->drawStuff->unbindFBO->blit->blit,
it'd just be: bindTarget->drawStuff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150729/673c8db1/attachment.html>