Re: eglSwapBuffers slow / low FPS just calling glClear

[Leigh McRae]

Make sure you have one thread for your simulation and one for
rendering. Some platforms, such as Android, has eglSwapBuffers as a
blocking call.

On 8/13/2012 4:37 PM, mortoray wrote:
> I'm having an issue with a low framerate on my Android Tablet (Lenovo
> IdeaPad). The frame rate is extremely variable, from 20-55 even if all
> I do is call the glClear command.
>
> This is done within a framework <gameplay3d.org> but I believe I've
> narrowed it down to the call to eglSwapBuffers. Everything else takes
> < 1ms to execute, so the variable is eglSwapBuffers. The time doesn't
> seem to depend at all on what I draw -- and the horrible time persists
> when calling just glClear. If I don't call clear, that is, make no gl
> calls, the swapping is fast.
>
> I've tried altering the contexts and attributes of the configuration
> but cannot get rid of this delay. I'm at a loss as to what I can
> check, or how I can further debug this issue.
>
> On the same tablet the Java interface produces smooth 60FPS
> animations, even with lots of objects. So I know it isn't
> fundamentally a hardware issue. I'm detecting FPS by using the NDK
> logging facility and measuring elapsed time using clock_gettime.
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-ndk/-/MezXcl7nN2gJ.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to
> android-ndk...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-ndk?hl=en.

[Leigh McRae]

I still think that is the problem. I have published on the BB PlayBook
and looking at my code it's single threaded. My iOS code is also
single threaded. From what I have seen only Android requires the
multithreaded rendering. Because the swap blocks you're also likely
getting nailed by vsync even if you're not drawing.

BTW I downloaded that game engine and from what I can see opengl is
being initialized on the main thread so it must be single threaded.
It's sad that Android has this limitation. I would think that the
driver should be able to handle sending a 'push buffer' to the GPU
better than the app using threads. Maybe since iOS and PlayBook both
do the hardware and software, they are able to remove this limitation.

On Tuesday, August 14, 2012 1:55:13 AM, mortoray wrote:
> I'm not doing any rendering beyond just calling "glClear" and I get
> the slowdown.

>
> On Tuesday, August 14, 2012 2:25:46 AM UTC+2, Leigh McRae wrote:
>
> Make sure you have one thread for your simulation and one for
> rendering. Some platforms, such as Android, has eglSwapBuffers as a
> blocking call.
>
> On 8/13/2012 4:37 PM, mortoray wrote:
> > I'm having an issue with a low framerate on my Android Tablet
> (Lenovo
> > IdeaPad). The frame rate is extremely variable, from 20-55 even
> if all
> > I do is call the glClear command.
> >
> > This is done within a framework <gameplay3d.org

> <http://gameplay3d.org>> but I believe I've

> > narrowed it down to the call to eglSwapBuffers. Everything else
> takes
> > < 1ms to execute, so the variable is eglSwapBuffers. The time
> doesn't
> > seem to depend at all on what I draw -- and the horrible time
> persists
> > when calling just glClear. If I don't call clear, that is, make
> no gl
> > calls, the swapping is fast.
> >
> > I've tried altering the contexts and attributes of the
> configuration
> > but cannot get rid of this delay. I'm at a loss as to what I can
> > check, or how I can further debug this issue.
> >
> > On the same tablet the Java interface produces smooth 60FPS
> > animations, even with lots of objects. So I know it isn't
> > fundamentally a hardware issue. I'm detecting FPS by using the NDK
> > logging facility and measuring elapsed time using clock_gettime.
> > --
> > You received this message because you are subscribed to the Google
> > Groups "android-ndk" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/android-ndk/-/MezXcl7nN2gJ

> <https://groups.google.com/d/msg/android-ndk/-/MezXcl7nN2gJ>.

> > To post to this group, send email to andro...@googlegroups.com

> <javascript:>.

> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com <javascript:>.

> > For more options, visit this group at
> > http://groups.google.com/group/android-ndk?hl=en

> <http://groups.google.com/group/android-ndk?hl=en>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/android-ndk/-/jQlrG0sJSoUJ.

[Leigh McRae]

Try and set your swap interval to 0 and see what happens.

On 8/14/2012 9:56 AM, mortoray wrote:
> Just to test the theory I put my rendered on a separate thread and the
> problem persists. All that thread is doing now is calling glClear and
> swap in a loop (plus the logging to see FPS). This is already giving
> highly erratic results.
>
> I understand that eglSwapBuffers blocks. I expect it to always block
> for about the remainder of the 16ms span required for the next 60 FPS
> sync. It however waits for longer than this, frequently 25ms,
> sometimes longer.
>
> Note, there are no GC events in the log. This slowdown is persistent.
> I can see that for a few spurts it maintains 60FPS, but it tends to
> drop quickly again.

> <https://groups.google.com/d/msg/android-ndk/-/jQlrG0sJSoUJ>.

> > To post to this group, send email to andro...@googlegroups.com
> <javascript:>.
> > To unsubscribe from this group, send email to
> > android-ndk...@googlegroups.com <javascript:>.
> > For more options, visit this group at
> > http://groups.google.com/group/android-ndk?hl=en
> <http://groups.google.com/group/android-ndk?hl=en>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/android-ndk/-/szOq41EF-wsJ.

[David Given]

mortoray wrote:
> Just to test the theory I put my rendered on a separate thread and the
> problem persists. All that thread is doing now is calling glClear and
> swap in a loop (plus the logging to see FPS). This is already giving
> highly erratic results.

What kind of surface are you asking EGL for? Some devices will give you
really stupid surfaces unless you're picky about the bit depth, etc. If
it's giving you an alpha channel you might be at the mercy of some
external compositor.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams

[Leigh McRae]

Since you have stated that you're just clearing and swapping, how are
you getting the fps? Could it be that your logging is causing this?
At this point I would also start to profile your loop using your own
timers and track down where the time is.

On Tuesday, August 14, 2012 12:31:52 PM, mortoray wrote:

>
> On Tuesday, August 14, 2012 6:01:43 PM UTC+2, David Given wrote:
>
> What kind of surface are you asking EGL for? Some devices will
> give you
> really stupid surfaces unless you're picky about the bit depth,
> etc. If
> it's giving you an alpha channel you might be at the mercy of some
> external compositor.
>
>

> I tried many combinations of attributes and nothing made any
> difference. Also, in my other app, not in the framework, I tried the
> same attributes and they all worked fine. So I'm guessing that while
> the problem influences GL heavily, that GL isn't the problem itself.

>
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/android-ndk/-/1eVydOaumeUJ.

[Latimerius]

On Tue, Aug 14, 2012 at 7:23 PM, Leigh McRae
<leigh...@lonedwarfgames.com> wrote:
> At this
> point I would also start to profile your loop using your own timers and
> track down where the time is.

Well the OP mentions right in his initial message that

"... I believe I've narrowed it down to the call to eglSwapBuffers.

Everything else takes < 1ms to execute, so the variable is
eglSwapBuffers."

so you can see he's done that already.

[Leigh McRae]

Thank you for the constructive response Latimerius. As I mentioned,
perhaps the logging of the frame rate is causing the problem. Also the
OP said it takes < 1ms but didn't mention what was being used to make
this measurement.

Mortory, did you set the swap interval to 0 to disable vsync?

[David Given]

mortoray wrote:
> Yes, I've tried changing that setting. Essentially I have the framework
> GL code to match the native application sample in virtually all
> respects. One is slow, one is not. I don't see any other GL related code
> I could change (looks identical at this point). It seems like something
> in the framework is getting it stuck in some emulation/low priority
> mode, no idea what however, or whether such a thing even exists on Android.

Actually, there is --- check out <uses-sdk> in the manifest. If the
application's targetSdkVersion is low enough, the system assumes that
the app is old and will enable various emulation features.

Usually it's obvious when this is happening, though, because your app
will be zoomed to fit a tablet screen and everything goes fuzzy...

And you're not running this on a Intel-power San Diego, are you? They do
software emulation of ARM binaries, which is hideously slow.

[edA-qa mort-ora-y]

On 15/08/12 11:47, David Given wrote:
> Actually, there is --- check out <uses-sdk> in the manifest. If the
> application's targetSdkVersion is low enough, the system assumes that
> the app is old and will enable various emulation features.

Interesting. It looks like I have version 9 for the SDK in the manifest
and no uses-sdk flag. I think this is high enough to get native
rendering. I also matched the manifest file to have identical settings
(save names) to the sample native app. So it's nothing in the manifest
that I can see.

I have this strange feeling I'll learn everything about the android but
still not find the problem. Well, at least I've learned something. ;)

BTW, I'm running a Lenovo IdeaPad A1. The reason I though to investigate
the problem originally is because I wrote a GL program via Java with the
SDK and its performance is top-notch. So when I ran the native program I
could see immediately something was wrong.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.