Author Topic: FrameBuffer creation time  (Read 819 times)

Offline mAlinka

  • byte
  • *
  • Posts: 21
    • View Profile
FrameBuffer creation time
« on: November 24, 2015, 09:16:03 am »
Hello.
I have a question about FrameBuffer creation. As I noticed it takes about 2-4 seconds on my test device (Samsung S4 mini) and makes the UI hangs. Is it possible to create it on separate thread or some other way to avoid such effects?

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11985
    • View Profile
    • http://www.jpct.net
Re: FrameBuffer creation time
« Reply #1 on: November 24, 2015, 09:37:32 am »
That's mainly caused by the shader compilation. You can't do this in another thread, it has to happen in the render thread. The time this takes highly depends on the device and the GPU/driver. The S4 mini isn't exactly a power horse, so it takes it's time. There isn't much you can do about it, I'm afraid. The only option is to set Config.skipDefaultShaders = true. This is meant for apps that mainly use their own shaders and don't rely on the default ones. If you set this to true without providing your own shaders, it will still work, but runtime performance might suffer (but how much depends on your app, so it might at least be worth a try).

If you experience this issue in pause/resume operations as well and not just on initial startup, you can try to minimize GL context changes by adding this to your code: mGLView.setPreserveEGLContextOnPause(true); and then check if the GL context in onSurfaceChanged() has actually changed since the last call (even if you don't use it directly for OpenGL ES 2.0). Then only create a new FrameBuffer instance if that's the case.

Offline mAlinka

  • byte
  • *
  • Posts: 21
    • View Profile
Re: FrameBuffer creation time
« Reply #2 on: November 24, 2015, 10:47:57 am »
Thank you Egon for response!
The main reason  why I should recreate buffer is surface size changing. An activity where GlSurface is used is fullscreen while other application activities not. So surface is created a little less and than stretched on full screen size. It leads to call onSurfaceChanged several times with different width and height.
As I can conclude from your explanation there is no way to improve this situation(