From 2c848179530b8fa97b5aa681d95e00bdcaa29950 Mon Sep 17 00:00:00 2001 From: Jeff Gilbert Date: Thu, 4 Mar 2021 14:41:38 -0800 Subject: [PATCH 1/2] Replace non-ascii chars where unnecessary or accidental in extensions/*. Some of these aren't even valid utf-8, and python's open(foo,'r').read() raises UnicodeDecodeErrors. --- extensions/OES_vertex_array_object/extension.xml | 8 ++++---- extensions/OVR_multiview2/extension.xml | 2 +- extensions/proposals/WEBGL_debug/extension.xml | 6 +++--- .../WEBGL_security_sensitive_resources/extension.xml | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/extensions/OES_vertex_array_object/extension.xml b/extensions/OES_vertex_array_object/extension.xml index 2efd1c4e13..772d646413 100644 --- a/extensions/OES_vertex_array_object/extension.xml +++ b/extensions/OES_vertex_array_object/extension.xml @@ -78,11 +78,11 @@ interface OES_vertex_array_object {

  • RESOLVED: Buffers should be reference counted when attached to a vertex array object. This is consistent with the OpenGL ES 3.0 - spec's implementation of Vertex Array Objects and matches the + spec's implementation of Vertex Array Objects and matches the behavior of other WebGL objects, such as textures that are attached to framebuffers.

    -

    This will require that most implementations do not call +

    This will require that most implementations do not call glDeleteBuffer when the user calls deleteBuffer on the WebGL context. Instead the implementation must wait for all references to be released before calling glDeleteBuffer to prevent undefined behavior. @@ -91,8 +91,8 @@ interface OES_vertex_array_object { bound vertex array object, then it is as if BindBuffer had been called, with a buffer of 0, for each target to which this buffer was attached in the currently bound vertex array object. In other words, this buffer - is first detached from all attachment points in the currently bound - vertex array object. Note that the buffer is specifically not detached + is first detached from all attachment points in the currently bound + vertex array object. Note that the buffer is specifically not detached from any other vertex array object. Detaching the buffer from any other vertex array objects is the responsibility of the application.

    diff --git a/extensions/OVR_multiview2/extension.xml b/extensions/OVR_multiview2/extension.xml index eaeb311011..276550a878 100644 --- a/extensions/OVR_multiview2/extension.xml +++ b/extensions/OVR_multiview2/extension.xml @@ -188,7 +188,7 @@ interface OVR_multiview2 { Specified what happens when the number of views doesn't match or if the number of views is one. - ´ + Specified what happens on invalid num_views declarations and if assignment to gl_Position.x is inside a larger expression. diff --git a/extensions/proposals/WEBGL_debug/extension.xml b/extensions/proposals/WEBGL_debug/extension.xml index 00f02f5d19..383d44e107 100644 --- a/extensions/proposals/WEBGL_debug/extension.xml +++ b/extensions/proposals/WEBGL_debug/extension.xml @@ -71,7 +71,7 @@ - As per the usual WebGL binding rules, functions don’t keep the KHR + As per the usual WebGL binding rules, functions don't keep the KHR suffix they have in the GLES version, but tokens do. @@ -245,7 +245,7 @@ function init(gl) {
    Skip a section of the code. - + 
    
     Only output a subsection of the code and disable some messages for the
     entire application.
-  
+
     
    For an example of security sensitive content, consider the rendering of an HTML link. The color of the link can indicate its visited or unvisited state. Third parties must not be able to access or infer this information.
    
       
    Specifically, third parties must not be able read the pixel data of security sensitive content through WebGL or other APIs. Additionally, third parties must not be able to divulge or approximate the pixel data of security sensitive content by timing WebGL operations.
    
       
    Prior to this extension, WebGL restricted the upload of security sensitive content as a texture for graphical processing. This extension enables the uploading and processing of security sensitive content, with some restrictions. Note that this extension imposes no restrictions on the processing of regular, non-security sensitive content.
    
-      
    To secure a user’s privacy, a WebGL implementation must not leak information about the contents of security sensitive textures through the execution time of its commands. To achieve this, no part of the underlying graphics pipeline may vary in execution time based on the contents of a security sensitive texture. For example, primitive assembly and depth testing must not vary based on the contents of a security sensitive texture.
    
+      
    To secure a user's privacy, a WebGL implementation must not leak information about the contents of security sensitive textures through the execution time of its commands. To achieve this, no part of the underlying graphics pipeline may vary in execution time based on the contents of a security sensitive texture. For example, primitive assembly and depth testing must not vary based on the contents of a security sensitive texture.
    
       
    The vertex shading and fragment shading stages of the graphics pipeline require particular restrictions to keep their execution time independent of the contents of security sensitive textures. Specifically, the contents of a security sensitive texture must only appear in constant-time GLSL operations. A constant-time GLSL operation is an operation whose execution time does not vary based on the values of its operands. This extension will describe how a WebGL implementation can enforce this requirement.
    
       
    Additionally, this extension attempts to identify non-constant-time GLSL operations. All other GLSL operations are assumed to be constant time in both the WebGL implementation and the underlying GPU implementation. If this assumption is false on a particular implementation, then this extension must be disabled for that implementation. In the future, GPU vendors may be able to provide a mechanism to guarantee that the assumed GLSL operations are in fact constant-time.
    
     
    

From 7ad29eb5873268472202db3832a932963741d709 Mon Sep 17 00:00:00 2001
From: Jeff Gilbert 
Date: Thu, 4 Mar 2021 16:26:11 -0800
Subject: [PATCH 2/2] Convert to utf8.

I think these files were Windows-1252, but it's hard to tell.
---
 conformance-suites/1.0.0/conformance/glsl-conformance.html  | 2 +-
 .../conformance/glsl/misc/non-ascii-comments.vert.html      | 6 +++---
 .../1.0.1/conformance/glsl/misc/non-ascii.vert.html         | 6 +++---
 .../conformance/glsl/misc/non-ascii-comments.vert.html      | 6 +++---
 .../1.0.2/conformance/glsl/misc/non-ascii.vert.html         | 6 +++---
 .../conformance/glsl/misc/non-ascii-comments.vert.html      | 6 +++---
 .../1.0.3/conformance/glsl/misc/non-ascii.vert.html         | 6 +++---
 .../conformance/glsl/misc/non-ascii-comments.vert.html      | 6 +++---
 .../2.0.0/conformance/glsl/misc/non-ascii.vert.html         | 6 +++---
 9 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/conformance-suites/1.0.0/conformance/glsl-conformance.html b/conformance-suites/1.0.0/conformance/glsl-conformance.html
index f72a17e9c2..ec49607309 100644
--- a/conformance-suites/1.0.0/conformance/glsl-conformance.html
+++ b/conformance-suites/1.0.0/conformance/glsl-conformance.html
@@ -301,7 +301,7 @@
 }