[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] y-orientation for texImage2D from HTML elements
I say texImage2D automatically handles both top-left and bottom-left apps because if the app uploads data in top-first and bottom-first order respectively, they'll see things are right-side-up in either case. In bottom-left apps, it's because this is the native format, and texImage2D follows its spec. (Which says it's bottom-first) For top-left apps, it uploads data upside-down, but renders upside down (0,0=top-left is upside down, for GL), so two y-flips mean it's right-side-up again.
TexImage2D on HTML elements is not so lucky, since UNPACK_FLIP_Y_WEBGL determines the order the rows are uploaded. However, with UNPACK_FLIP_Y_WEBGL=true, the functionality I detailed for texImage2D on TypedArrays is broken. With UNPACK_FLIP_Y_WEBGL=true, apps need to upload TypedArray data in the opposite order of their coord system.
A developer knowing that HTML elements are 0,0=top-left reads the WebGL spec on TexImage2D, and finds they can call it on HTML elements to have the data uploaded to a texture automatically. He also doesn't see anything about the orientation that data is uploaded, so he checks the GLES2 spec. The GLES2 spec clearly says that TexImage2D uploads the bottom-row first. Since the browser is offering to automatically upload an image into a texture, why would ignore its own spec and send top-row-first data to a bottom-row-first function.
At the absolute minimum, we need wording in the spec that spells this out:
"We send decoded image data top-row-first into texImage2D, which, per spec, expects bottom-row-first data. This means that textures uploaded this way will be upside down compared to textures uploaded via other methods. You can force HTML element uploads to upload bottom-row-first by using UNPACK_FLIP_Y_WEBGL=true, but this also flips the order that TypedArray rows are uploaded."
Until then, this is not just counter-intuitive, but also unspecified behavior.
For the record, other OpenGL and WebGL devs I have shared this with have agreed that this behavior is surprising.
----- Original Message -----
From: "Mark Callow" <firstname.lastname@example.org>
To: "Jeff Gilbert" <email@example.com>
Cc: "Gregg Tavares (社用)" <firstname.lastname@example.org>, "public webgl" <email@example.com>
Sent: Thursday, December 6, 2012 6:12:41 PM
Subject: Re: [Public WebGL] y-orientation for texImage2D from HTML elements
On 2012/12/07 10:27, Jeff Gilbert wrote:
It is also a little crazy that texImage2D(gl.canvas) does not reduce to the same operation as copyTexImage2D. Welcome to the world of bashing square pegs into round holes.
I understand that people are used to passing image data directly to texImage2D as top-row-first, and just dealing with the flipped u/v coords, but this choice should not be force on everyone as it is now. UNPACK_FLIP_Y_WEBGL as it is today does not solve this, as to get consistent bottom-row-first behavior, an app needs to use UNPACK_FLIP_Y_WEBGL=false for TypedArray uploads, and UNPACK_FLIP_Y_WEBGL=true for HTML element uploads. Why should we try to hide that HTML elements have a top-left, top-row-first origin? It is easy enough for the application to change the setting of UNPACK_FLIP_Y_WEBGL between uploading from a typed array and uploading from an HTML element.
WebGL is *not* working the same way as OpenGL here, because OpenGL *only* accepts raw bytes. If you upload data top-row-first, and use uv 0,0 at the top-left, it's right-side-up. If you upload data bottom-row-first (like the texImage2D spec says), and use uv 0,0 at the bottom-left, it's also right-side-up. WebGL introduces loading from images directly. WebGL works exactly the same way as OpenGL. As in WebGL the application is expected to understand that most image formats have a top-left origin and to flip the data before uploading or provide different texture coordinates. WebGL provides the service of decoding and uploading standard image formats so we provided the pixel store property to request a flip. The knowledge needed by an application developer is the same in both cases.
This means WebGL has to make a choice over what order to upload the rows. Whereas texImage2D on TypedArrays doesn't really matter, We made a choice that WebGL would not make a choice. The application specifies whether it wants the image flipped or not. If it doesn't and wants the image the right way up, it is expected to supply the necessary texture coordinates.
texImage2D on HTML elements can't automatically handle both. We have half the solution in the form of UNPACK_FLIP_Y_WEBGL, but it doesn't provide a solution to making WebGL consistent for both choices of origin location.
You've lost me here. What does "texImage2D on HTML elements can't automatically handle both" mean? Do HTML elements come with different orientations? I thought they were all top-left therefore why does texImage2D on HTML elements need to handle both?
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
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 firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: