search

markfguerra / GLWallpaperService

Please submit issues and pull requests to the main repository
https://github.com/GLWallpaperService/GLWallpaperService
Apache License 2.0
218 stars 114 forks source link

WaitForCondition (mytouch4g) issue and fix #11

Closed TaDaa closed 11 years ago

TaDaa commented 13 years ago

Hi,

First of all thanks for hosting this code, it is extremely helpful.

I have found one small issue that affects at least the mytouch4g. If you switch between screens quickly (i.e browser and home screen), the wallpaper stops updating and logcat gets flooded with WaitForCondition. If you put a short Thread.sleep (e.g Thread.sleep(10)) after mEglHelper.swap(), it fixes the issue. Other than that, everything has worked for me so far...I've actually downloaded and modified min3d to work with your code for fun.

Thanks again, Trevor

markfguerra commented 13 years ago

Trevor, thanks for this. When I have time in my busy life to spend a few hours on this project I will check this issue out. There other contributions that need some attention as well.

As always contributions of all kinds are welcome. If anyone has the time to look in to this and confirm the issue\fix, I would be very appreciative.

If you feel it is ready for the public, please publish your min3d work somewhere. It sounds like a very useful thing.

markfguerra commented 13 years ago

Trevor,

Is this more or less the waitForCondition message you saw?

 WARN/SharedBufferStack(6984): waitForCondition(LockCondition) timed out (identity=252, status=0). CPU may be pegged. trying again.
TaDaa commented 13 years ago

yeah same waitForCondition and CPU may be pegged message.

markfguerra commented 13 years ago

I see. LockCondition too?

This issue has dogged us for a while now, in a couple of different ways. I am really glad that you reported on this. I hope we have a permanent solution here. Anyway we have some testing to do. Thanks!

TaDaa commented 13 years ago

yeah sorry lockcondition too...I should have just copied the entire error:

waitForCondition(LockCondition) timed out (identity=49, status=0). CPU may be pegged. trying again.

I hope it fixes it the issue for everyone as I can only test it on the mytouch4g. Thanks for maintaining this project.

markfguerra commented 13 years ago

Do you have a reliable way to trigger the bug? At least as far as the stuff I tried, I can only trigger it on an inconsistent basis.

If I remember correctly I triggered it on my HTC G2 by rapidly turning the screen on and off. I think I could also do it by rapidly opening and closing the physical keyboard. The bug would occur something like 1 in 25 tries for either method, more or less depending on the day.

TaDaa commented 13 years ago

For me... the issue would consistantly occur if I repeatedly and quickly opened the default browser and then press the home button. Since making the changes, ADW launcher sometimes has to force close after the screen unlocks..I'm not sure if this is caused by a separate issue

CodeCommander commented 13 years ago

I also tried implementing this fix and tested it on my G2. It does seem to help the problem because now if I turn the screen on and off really fast several times in a row it doesn't seem to freeze the animation. However, after using the wallpaper for a long period of time it still eventually gets frozen. :/

b1naryatr0phy commented 13 years ago

Same problem here on my Optimus V. Unfortunately, the fix didn't work for me =/

It only happens to me when exiting my preferences screen. I've left the wallpaper running for literally 4 hours straight without a hitch.

b1naryatr0phy commented 13 years ago

Just wanted to let you all know that for the past two weeks or so, I have not once encountered this bug. I was getting it very, very frequently when exiting the preferences screen of my app.

I wish I could tell you all how it's fixed for me now, but I have no idea. I didn't change any code in the GLWallpaperService (besides trying the 'fix' above, which didn't work,) I did however go through all of my own source and made several changes in accordance with the advice given at: http://www.opengl.org/wiki/Common_Mistakes

I came across maybe 3 or 4 common OpenGL pitfalls in my code and corrected them accordingly. Now, I just don't see the bug anymore, and believe me I've tried and tried to recreate it. I should have kept a copy of my old source so I could compare it to my current version, but unfortunately I didn't. My apologies for not being more diligent, but I really wasn't expecting to eliminate it completely.

So anyway my best suggestion at this point would be to try optimizing your own source, document your changes, and maybe someone will find a definitive cause.

CodeCommander commented 13 years ago

I have not run into this problem since I installed Cyanogen mod on my G2. b1naryatr0phy, have you had any system updates since you noticed the problem was fixed?

b1naryatr0phy commented 13 years ago

Not from my service provider no. I originally had my test phone rooted with a modified rom, but after encountering this issue (and thinking that perhaps it was conflicting with some other code at the low-level, maybe due to a bad rom hack) I reset my phone back to factory. That didn't solve the problem either. Then a couple days after, the issue was gone.

That was just one of my theories, and perhaps it's way off. I don't have much experience with Linux at the low level. But it just really bothered me that the bug was so random.

markfguerra commented 13 years ago

I created an APK with this patch included. Anyone who is willing, please test and comment on whether the issue is resolved by the fix. This bug is intermittent, so if possible please leave the device running a wallpaper for a few hours, and use it as normal. If you can trigger the bug, try to do that too.

Along with your results, please post your device model and any other relevant info.

Patched version: http://files.markguerra.net/glwallpaperservice/issue11/GLWallpaperTest-bug-waitforcondition-936d05b.apk

Unpatched version: http://files.markguerra.net/glwallpaperservice/rel/GLWallpaperTest-rel-v0.9.apk

markfguerra commented 13 years ago

I pushed the code for Tadaa's fix to a new branch so that people can have a look. The branch is called bug-waitforcondition

https://github.com/markfguerra/GLWallpaperService/tree/bug-waitforcondition

markfguerra commented 13 years ago

@b1naryatr0phy After you decided that the fix wasn't working for you, did you then remove the fix? Because now that you've changed your rendering code and the problems are gone, I'm curious as to whether you're running the patched or unpatched version of GLWallpaperService.

dkeese commented 13 years ago

I might be able to help. My wallpaper was working fine yesterday. After some updates last night, I started getting this problem on my HTC Incredible running Launcher Pro on Android 2.2.

I did not change anything in the Renderer or in the Service. Only stuff in my draw methods. I'll try to narrow down what did it. My wallpaper is all in Java, using OpenGl ES 1.0 only.

For me, the screen freezes entirely and the phone is unresponsive for about a minute before it automatically restarts. The freeze happens anywhere between 10 seconds and 15 minutes after starting the wallpaper, and it occurs every time while the home screen is just sitting there. It's not in response to an orientation change or coming back to the home screen. I get the same Logcat message as the above posts show, repeatedly a few hundred times until the phone resets.

I'll also check if this new branch fixes it.

dkeese commented 13 years ago

So far so good for two hours. But what I don't understand is why this fix would work for crashes that happen when the home screen is just sitting there. The gl context shouldn't be changing, should it?

markfguerra commented 13 years ago

I'm not sure about that crash thing someone mentioned. Sounds like it might be a separate issue.

I've been testing this patch on my unmodified HTC G2 (Vision), Build number 1.22.531.8 CL277427. I ran the patched version for two days and didn't encounter this issue, so Tadaa's patch either fixes the issue or mitigates it very well. Looking good.

For comparison I started running the unpatched version today. The animation froze within an hour. I restarted it, so we'll see how long it goes before it freezes again.

If possible I'd like to hear from a few more testers running various devices before I merge this patch into the master branch.

dkeese commented 13 years ago

Well, I still got a freeze about three or four hours in. The patch seems to have reduced the occurrence rate.

Mark, are you getting freezes only during a screen transition, or also when the phone is just sitting there?

markfguerra commented 13 years ago

By screen transition, do you mean when the user swipes to change home screens (desktops)?

I've never seen that happen to me. Maybe the wallpaper you're running is causing that particular issue for you. I'm not sure, though. I'm testing the patch using the GLWallpaperTest wallpaper included in the source. Is anyone else having that issue?

I usually see the issue occur at random while the phone is just sitting there.

Perhaps you can tweak how long the thread sleeps for to find a value that works for you.

Btw what device are you running on?

dkeese commented 13 years ago

No, I'm only seeing the same thing as you...random freezes that are not triggered by screen changes.

I have been testing only my own wallpaper, but I'll try testing your test wallpapers this weekend. Basically, the difference between the working version of my code and the non-working version is the number of calls to disable and enable GL lighting and switch the active texture. I had changed it so it was flipping lighting on and off about 12 times a frame instead of three times.

Under what conditions does createWindowSurface() get called? I don't understand why this patch would affect random freezes. I thought window surfaces only get created after an orientation change.

markfguerra commented 13 years ago

I'm not 100% sure what causes calls to createWindowSurface(). I didn't write the code, and don't have a very deep understanding of how it works. It's possible that this is in response to a system event (such as a process being killed) but I'm only guessing there.

As far as my testing goes, the unpatched version freezed again this morning. I believe that the patch mitigates the issue for me, but I will continue testing.

m6246 commented 13 years ago

I was experiencing the bug as well but haven't seen those logcat messages after changing my own code. I created a GLManager class that has a static GL10 variable sGL that holds the GL context, being set at onSurfaceCreated and onSurfaceChanged (which happens in either the real wallpaper or the preview). Then every gl* call uses this variable GLManager.sGL. Don't know if this is the part that actually fixes the bug, but it might be worth testing. Worked for me so far.

markfguerra commented 13 years ago

@m6246 Sounds interesting. If had my way, users would not have to go to such lengths to manage their GL10 instance.

TaDaa commented 13 years ago

Hey guys..sorry to leave you hanging been really busy lately.

I've had a test live wallpaper running the last 3 months and my phone has been on pretty much the entire time...I had only one waitforcondition freeze in that period of time. This was running CM7 stable rc2 on a mytouch 4g.

Last night I was thinking about the problem some more because even one lockup is not acceptable for me. For whatever reason I was thinking that this could possibly be just a really simple synchronization issue. I think that the mEglHelper.swap() may need to be synchronized with the sGLThreadManager. I changed my code to the following:

                /*
                 * Once we're done with GL, we need to call swapBuffers() to instruct the system to display the
                 * rendered frame
                 */

                synchronized (sGLThreadManager) {
                    mEglHelper.swap();
                }

            }
        }
    } finally {
        /*
         * clean-up everything...
         */
        synchronized (sGLThreadManager) {
            stopEglLocked();
            mEglHelper.finish();
        }
    }

I did some very basic experimenting last night and have not experienced any issues yet... Going to mess around with it some more. I really need to make a resource heavy wallpaper because it seems to affect the frequency of the problems (e.g. waitforcondition never occurs for me with 2 or 3 squares on the screen, but occurs semifrequently with a large skydome) .

markfguerra commented 13 years ago

I created a new branch (bug-waitforcondition-sync) and pushed the code from Tadaa's last post. https://github.com/markfguerra/GLWallpaperService/tree/archive/bug-waitforcondition-sync (Edit: Branch deleted. Linked to a tag)

You can get a working APK here: http://files.markguerra.net/glwallpaperservice/issue11/GLWallpaperTest-bug-waitforcondition-sync-0481eaf.apk

markfguerra commented 13 years ago

I've been testing with TaDaa's latest patch, 0481eaf (with the synchronized block). With that patch, I still encounter the issue fairly often (every 1-4 hours) on an HTC G2.

However I had a good amount of success with the previous patch, 936d05b (with the Thread.sleep(10) line). As I recall I didn't see the issue often, if at all. I'm gonna re-test to confirm, and if all goes well I'll merge it in to the master branch and create a new version of the Jar.

If 936d05b causes issues for you, speak up now before I merge it in. If not one objects then in a few days I plan to merge it and make a release.

Thanks everyone for your hard work and input.

markfguerra commented 13 years ago

I merged 936d05b into master and bumped the version to v0.9.1

You can download an updated Jar file at https://github.com/downloads/markfguerra/GLWallpaperService/GLWallpaperService.jar

Link to the older v0.9 Jar: http://files.markguerra.net/glwallpaperservice/jar/v0.9/GLWallpaperService.jar

Thanks again to everyone who commented, tested, or otherwise worked on this.

carlhopf commented 13 years ago

I can confirm the report from dkeese. I am working on my own OpenGL android project, having random freezes. The freezing stopped so far, when i removed calls to glEnable/Disable(GL_LIGHTNING). I was switching lightning on and off 1 time each frame, but since i've stopped that the freeze was gone. HTC Desire.

Basically i am drawing 3 different textured VBOs. For some odd reason i do not have the freezing problems in my other projects, cannot find a difference though - just the objects and textures mostly changed. My GL calls are not very different..

dkeese commented 13 years ago

I'm not sure why this hasn't been discussed...I've been searching for ways to improve frame rate, and I came back to this after a while and realized that we have put Thread.sleep(10) in the rendering loop.

This has a the potential to make a huge impact on frame rate! If you do the math, a 60fps animation will go down to 37fps. A 30fps animation will go down to 23fps.

In actuality, it seems to only have a 2fps hit on my live wallpaper when it's just sitting there, but then gives it the full ~10fps hit when sliding between home screens. Could this be do to inaccuracy in Thread.sleep?

It does seem that many GPU calls increase the risk of a crash. More efficient code that reduces GPU calls may be a better solution. I'm not sure why the synchronization method didn't work. Apparently swapBuffers() is not always getting a chance to finish if the rendering code is very complex.

markfguerra commented 13 years ago

It might be worth trying to tweak how long the thread sleeps for and see if it improves the framerate while still mitigating the freeze issue.

dkeese commented 13 years ago

Yeah. Now if the problem is related to how many GL calls are made, then the value is going to depend on the particular wallpaper. Might want to make the sleep time a variable that's set in the Engine's constructor.

markfguerra commented 13 years ago

JesusFreke has created an alternate implementation of GLWallpaperService. I've tested this for about 2 weeks, and it appears to resolve this issue.

I would like it if some of you guys can test it out and see how well this works out for you. Here's the alternative JAR and fork.

http://files.markguerra.net/glwallpaperservice/jar/jesusfreke/793c95f/GLWallpaperService.jar https://github.com/JesusFreke/GLWallpaperService

By the way, a quick and easy way to test is to install JesusFreke's Penroser wallpaper from the Android market. https://market.android.com/details?id=org.jf.Penroser

@dkeese Can you please see if the new implementation affects your framerate?

timogriese commented 12 years ago

I tried out the implementation from JesusFreke, the issue still persists.

Tried with a NOOP-Renderer that just does nothing but it still occurs. Will have to investigate more.

timogriese commented 12 years ago

[FIX] for 'waitForCondition(LockCondition) timed out' problem I was able to track down the issue to a single line in my implementation that makes the difference.

To save energy I did nothing in the draw method (just return). This works well for a few minutes and fails afterwards as decribed above. A single glClear of the COLOR_BUFFER before returning solves the problem.

It should be tested if it must be a glClear or if any other GL command will be enough.

Hope this helps!

Regards, Projekt2501

keaukraine commented 12 years ago

I'm having this issue on HTC Desire S with Android 2.3. Sometimes I even can't open live wallpaper for preview without rebooting phone. Anyways wallpaper won't work any longer than a few minutes.

The less geometry I draw, the more stable it is. If I draw only a 3-5 objects, it is absolutely stable. I've tried adding sleep(), it doesn't make it more stable, only causes framerate drops (obviously).

What is interesting, live wallpaper works like a charm on my Transformer w/ Honeycomb.

keaukraine commented 12 years ago

OK, so in my case I narrowed down this to problem with fragment shader, which misbehaved on Adreno GPU (oh boy I just love these differences between nVidia and Qualcomm's GLSL implementations :P ). @Projekt2501 - so this issue really seems to be specific for every live wallpaper. In general, I believe, it is mainly caused by OpenGL used in non-optimal way.

timogriese commented 12 years ago

I suppose you are right on this one.

2012/1/19 keaukraine < reply@reply.github.com

OK, so in my case I narrowed down this to problem with fragment shader, which misbehaved on Adreno GPU (oh boy I just love these differences between nVidia and Qualcomm's GLSL implementations :P ). @Projekt2501 - so this issue really seems to be specific for every live wallpaper. In general, I believe, it is mainly caused by OpenGL used in non-optimal way.

Reply to this email directly or view it on GitHub:

https://github.com/markfguerra/GLWallpaperService/issues/11#issuecomment-3559149

markfguerra commented 11 years ago

This issue is being closed because the project is being moved to the GLWallpaperService GitHub organization

If you're still having this problem, please go there and open new issue or pull request. Don't forget to link back to this page.