-1

I have made some full screen renders using OpenGL ES 2.0 on Andorid devices.

In these renders I used a custom fragment shader that uses a uniform time parameter as part of the animation.

I have experienced major image tearing/massive fps drops and pixelated result as the render went on. After playing around with values and trying to fix it, I found the problem to be in the size of the time parameter, as the value got bigger and bigger the result got worse. changing the float precision to highp in the fragment shader didn't help,but the animation got worse at a later time then before, as you'd expect.

I found a solution by limiting the size of the parameter before it was sent to the shader, by using the mod operator on it.

On the other hand, I copied the exact shader code into a browser that runs a web-gl environment to render the same thing that runs on my phone, and there is no problem with the parameter size, no fps drop, no nothing.

I can understand that the graphics card on mobile devices is weaker then what I have on my pc, and it is only natural to assume that my pc graphics card can hold much larger values.

But, my question is, what possible solution can I work with to go around this problem of parameters sizes?

I would like my animation to go on forever*, and not be forced to loop around after 5 seconds.

Here is a link to the website with the animation: website link

*not actually forever but a quite a long time, just like in the browesr.

genpfault
  • 51,148
  • 11
  • 85
  • 139
Daniel Mendel
  • 506
  • 5
  • 17
  • I want to say [`glGetShaderPrecisionFormat (...)`](https://www.khronos.org/opengles/sdk/docs/man/xhtml/glGetShaderPrecisionFormat.xml) is your best bet. Query the range for `highp` (also be aware that `highp` may not be supported in fragment shaders in ES 2.0 on some systems). But, this isn't really a work-around, it just tells you the limits you are supposed to conform to. – Andon M. Coleman Aug 21 '15 at 18:21
  • so I understand it is a known issue and needs to be accounted for always? – Daniel Mendel Aug 21 '15 at 18:31
  • I don't know that it's necessarily a known issue (since I don't know the range of numbers you are dealing with), but it is absolutely true in GLES that the precision qualifiers have a minimum required range and implementations vary wildly on whether they meet or exceed that minimum. It would be very easy to inadvertently write code that only works on one vendor's hardware because you made a bad assumption. The ranges are discussed [here](https://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf#page=39) – Andon M. Coleman Aug 21 '15 at 18:52

1 Answers1

0

If uFloat is meant to represent a timestamp, I'd advise passing in a unix timestamp instead, in milli- or nano- seconds, as an int or long. I don't know how it'll fix the framerate issues, but if the cause of your woes are related to the precision of the timestamp, that'll probably fix that issue.

Edit: Based on the comments, this may be a precision issue. As uFloat increases in value, it slowly loses precision on its mantissa. What could very well be happening is that incremental increases to uFloat are too low. What you'll want to do for debugging purposes is spit out the entirety of the floating point number generated each frame for the value of uFloat, and compare them frame by frame to see if the number stops increasing consistently every frame.

Xirema
  • 19,889
  • 4
  • 32
  • 68
  • the value in question is a uniform float, it doesn't represent any exact measurement of time, just an arbitrary value that grows as time passes by – Daniel Mendel Aug 21 '15 at 18:33
  • Alright, but what's the rate at which it grows over time? – Xirema Aug 21 '15 at 18:34
  • time = (((System.currentTimeMillis() - startTime) * 0.00005f)) % 1f; – Daniel Mendel Aug 21 '15 at 18:38
  • it reaches the maximum value (value of 1.0) in 20 seconds, abit more then that it starts to lag – Daniel Mendel Aug 21 '15 at 18:40
  • Also, is the page you linked to going to start exhibiting this behavior if I open my phone to it for awhile? – Xirema Aug 21 '15 at 18:48
  • Yes, Sorry I tried it now and it does get laggy, to get the lag faster you should change highp to lowp at the code and click run, after like 10 seconds you will notice frame drops – Daniel Mendel Aug 21 '15 at 18:49
  • Well, Based on what's visible to me, it doesn't look like there's anything wrong with your code. You may wish to investigate if there's anything you're doing on the application side that could be affecting the performance. – Xirema Aug 21 '15 at 18:52
  • Hey xirema, I updated my comment, it does lag, I am trying it now – Daniel Mendel Aug 21 '15 at 18:52
  • @DanielMendel: 0.00005 is ridiculously small. This may not be a problem with range so much as precision. Floating-point numbers usually have absolutely massive ranges, but precision is where they suffer and that number is small enough to raise concern in GLSL. – Andon M. Coleman Aug 21 '15 at 18:57
  • @Andon M. Coleman any bigger then that and the animation gets massive frame drops, I tried with various values and this one works the best, Also, it multiplies miliseconds which are a big number , 1000 miliseconds is 1 second so 1000 * 0.00005 = 0.05 which is not that small of a number – Daniel Mendel Aug 21 '15 at 18:58