Three.js: Firefox Nightly: Error: WebGL: texImage2D: Chosen format/type incured an expensive reformat: 0x1908/0x1401

[makc]

Error: WebGL: texImage2D: Chosen format/type incured an expensive reformat: 0x1908/0x1401

it still works, but this is in console for png textures (r76)

[mrdoob]

Uhm... Do you have an link to test with?

[makc]

In fact, it happens in http://threejs.org/examples/webgl_animation_cloth.html for example, I guess everywhere...

[ghost]

In fact, it happens in http://threejs.org/examples/webgl_animation_cloth.html for example, I guess everywhere...

I cannot replicate the issue.

[makc]

49.0a1 here

[ghost]

49.0a1 here

47.0 is the latest official version.
48.0b1 is the latest beta.
https://ftp.mozilla.org/pub/firefox/releases/

[makc]

Just updated to 50.0a1, the message is still there.

[ghost]

Just updated to 50.0a1, the message is still there

Firefox Nightly is something else.
On many hardware configs WebGL does not even work on this browser.

[makc]

but if the message will start to appear in beta and then release, nightly gives you extra time to investigate. preventive fixes might not be the policy of 3js, of course.

[ghost]

I get the same error in the latest Firefox Nightly.

I don't use this browser (all kind of bugs), but I agree with you: it should be investigated.

[makc]

It might be the warning from comment 4 here https://bugzilla.mozilla.org/show_bug.cgi?id=1246410#c4

[makc]

then again, there are no non-power-of-two warnings, so it's not canvas texture?

[Mardonis]

Using Chrome Version 51.0.2704.84 m on [http://threejs.org/examples/webgl_animation_cloth.html]
Getting this warning below:

three.js:24739 THREE.WebGLRenderer 77
2016-06-10 07:43:15.347 three.js:29690 THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(417,1): warning X4000: use of potentially uninitialized variable (_getShadow_float4)

[peppsac]

AFAIU, this is caused by the texture format.
To avoid this warning (and use the fast-path code), this condition needs to be true:

if (srcFormat == dstFormat && premultOp == WebGLTexelPremultiplicationOp::None) {

(see https://dxr.mozilla.org/mozilla-central/source/dom/canvas/WebGLTexelConversions.cpp#392)

But when creating a texture (dst) from an image (src) we have:

(gdb) p srcFormat
$14 = mozilla::WebGLTexelFormat::BGRX8
(gdb) p dstFormat
$15 = mozilla::WebGLTexelFormat::RGBA8

[stefnotch]

This now also happens in the normal/not nightly Firefox version. I can confirm that this happens with a canvas texture.

[makc]

nightly gives you extra time to investigate

lol. this guy is stupid )

[mrdoob]

[makc]

yes, you get more errors now.

[brianchirls]

I ran into this problem a couple months ago in Nightly, and I did some very minimal experimenting. I tried a few different formats - RGB, RGBA, POT, etc. And no matter what I did, I still go the error. There was some brief discussion in the webvr slack about it with some of the Mozilla people, but I don't think it went anywhere.

I would be surprised if there's anything you can do about it in three.js.

@kearwood - do you know anything about this?

[loldrup]

In Firefox 49.0.1 with three.js r81 I get this errror when running my own three.js app:

Error: WebGL: texImage2D: Chosen format/type incured an expensive reformat: 0x1907/0x1401

And all this stuff when running https://threejs.org/examples/#webgl_animation_cloth :

THREE.WebGLRenderer 81three.js:19386:6
THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(416,1): warning X4000: use of potentially uninitialized variable (_webgl_88e2b6533014e4f1)
C:\fakepath(310,8-99): warning X4121: gradient-based operations must be moved out of flow control to prevent divergence. Performance may improve by using a non-gradient operation

three.js:16531:7
THREE.WebGLProgram: gl.getProgramInfoLog() C:\fakepath(400,1): warning X4000: use of potentially uninitialized variable (_webgl_88e2b6533014e4f1)
C:\fakepath(296,8-99): warning X4121: gradient-based operations must be moved out of flow control to prevent divergence. Performance may improve by using a non-gradient operation

three.js:16531:7
Error: WebGL: texImage2D: Chosen format/type incured an expensive reformat: 0x1908/0x1401three.js:18909:8
Error: WebGL: texImage2D: Chosen format/type incured an expensive reformat: 0x1907/0x1401three.js:18909:8

[stefnotch]

About the gradient-based operations: https://www.gamedev.net/topic/543541-hlsl-warning-gradient-based-operations-must-be-moved-out-of-flow-control-to-prevent/

[ilsj]

In Mozilla Firefox Developer edition this page https://threejs.org/examples/webgl_animation_cloth.html
(and any other pages with ThreeJS scenes too) throws errors on load textures:

Error: WebGL: texImage2D: Incurred CPU-side conversion, which is very slow. three.js:18909:8
Error: WebGL: texImage2D: Incurred CPU pixel conversion, which is very slow. three.js:18909:8
Error: WebGL: texImage2D: Chosen format/type incurred an expensive reformat: 0x1908/0x1401 three.js:18909:8

In other my page in WebGL scene without Three.JS that errors throws too.

So this errors throws WebGL method gl.texImage2D():
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, texture.image );

Two errors because I used HTML Image, instance of Image(). This image data type is expensive.
And other one error throws because used FlipY pixel storage:
gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true);

After converting image data to Uint8Array and removing gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true);
errors disappear. But all textures now was flipped from up to down. To fix it, I manually flipped Uint8Array image data.

Rewrited texImage2D() call:

`gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, image.width, image.height, 0, gl.RGBA, gl.UNSIGNED_BYTE, image);`

Converting image to Uint8Array:

function imageToUint8Array(image){
  var canvas = document.createElement('canvas'),
      ctx = canvas.getContext('2d');
  canvas.width = image.width,
  canvas.height = image.height;
  ctx.drawImage(image, 0, 0);
  var imageData = ctx.getImageData(0, 0, image.width, image.height);
  var buff = new Uint8Array(imageData.data.buffer);
  return buff;
}

Function to flip Uint8Array:

function flipYImageArray(image, width, height){
  var buff = new Uint8Array(image.length);
  var i = 0;
  for (var y = height - 1; y >= 0; y--) {
    for (var x = 0; x < width * 4; x += 4) {
      for (var c = 0; c < 4; c++) {
        buff[i] = image[width * 4 * y + x + c];
        i++;
      }
    }
  }
  return buff;
}

But I'm not sure, does using this method will improve code?
Seems like functions imageToUint8Array() and flipYImageArray() is make scene slow too.
So this all code just to avoid console errors.

[makc]

To fix it, I manually flipped Uint8Array image data.

which is like exactly what they warn about - slow cpu conversion - but now even slower than they could do in native code.

[ilsj]

Exactly. Native code will work much faster.
How i said this all code just to avoid console errors.

Other way, we can flip all image textures in any other grapical editor, and save flipped images to file.
But now it temporary solution.

Suppose, the best solutions is to prepare all images and save it as Uint8Array binnary file.
In this way we will load images as resources, without any conversations in code. But file size will increased, and it will cause to page load.

[loldrup]

On 17 October 2016 at 08:51, ilsj [email protected] wrote:

Suppose, the best solutions is to prepare all images and save it as
Uint8Array binnary file.
In this way we will load images as resources, without any conversations in
code.

If this is going to be the recommended option, can we then have a guide
that tells us how to convert images in this way?

/Jon

[nehvaleem]

i've encountered this issue while using video as source for texture. For me it is unable to preprocess source to another format. Is it anything I can do to workaround this problem?