Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Slowness in drawing on a RenderTarget tracked down — Gideros Forum

Slowness in drawing on a RenderTarget tracked down

AniketAniket Member
edited July 2015 in General questions
https://github.com/gideros/gideros/releases/tag/2015.04.04 is what introduced the problem. The version just before it, https://github.com/gideros/gideros/releases/tag/2015.03.22 was flickery but fast, while drawing on the rendertarget.

I'm trying to track down and fix this issue since it still affects the latest gideros binary till now, 2015.07.15

More importantly, the nature of the error is the same in both 2015.07.15 and 2015.04.04, which is when it was introduced. Most likely to fix the flicker error which was present in that one.

Reading release notes for 0404, one of the things mentioned is "Fixed RenderTarget dimension allocation" I'm going to start from there to see if it might have caused this.

Note: The issue is not present on devices like the nexus 4, but a 7 inch tablet that was tested had this issue. And as of 2014.01, the issue did not exist on either.

Any help in tracking down this issue or a simple example that demonstrates it even would be helpful, since the error is currently only in our proprietary code so I can't release that, however if I do find a fix I will commit it back to the main repo.

Comments

  • hgy29hgy29 Maintainer
    Thanks Aniket.
    If you manage to isolate a code snippet that reproduce the issue, please share so that we can work on the issue too.
  • hgy29hgy29 Maintainer
    Just a remark, 2015.04.04 was a huge change from 2015.03.22 in that OpenGL calls moved to GL ES 2 semantics, i.e. fixed pipeline to programmable pipeline. This means that the underlying graphic driver used on the devices themselves is not the same, starting from 2015.04.04 requests a version 2 EGL context and no longer a version 1.
  • john26john26 Maintainer
    What 7 inch tablet was used to test? Perhaps it simply doesn't support GL2 natively and is using some type of emulation...?

    this problem is only happening in Android right?
  • SinisterSoftSinisterSoft Maintainer
    @Aniket the fix you mentioned (Fixed RenderTarget dimension allocation) wouldn't have caused the problem.

    A) Can you try allocating textures that are a power of 2 and see if that fixes it for you. Some tablets need textures to be a power of 2 (128,256,512,1024,etc)

    B) Also try with a power of 2 and both w and h the same (on some the need to be square).

    If this fixes it on the latest player then please let us know (A or B).
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
  • SinisterSoftSinisterSoft Maintainer
    Also check that your manifest and java activity files are up to date with the currently generated ones.
    Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
    https://deluxepixel.com
  • hgy29hgy29 Maintainer
    This may well be a chipset bug: http://stackoverflow.com/questions/10729352/framebuffer-fbo-render-to-texture-is-very-slow-using-opengl-es-2-0-on-android
    I saw a "qualcomm" fix somewhere in gideros code, maybe related...
  • hgy29hgy29 Maintainer
    Another thing: in your application, do you make several consecutive calls to RenderTarget:draw() per frame, or do you render a single sprite containing all your objects ?

    This is because draw() call overhead has increased in 2015.04.04, and it would help knowing if your slowness may be due to that.
  • @Aniket
    Could you try whether thiscode would speed up yours :
    stage:setClearColorBuffer(false)
Sign In or Register to comment.