Skip to content

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also compare across forks.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also compare across forks.
...
  • 2 commits
  • 1 file changed
  • 8 commit comments
  • 2 contributors
Commits on Aug 10, 2011
DustinEwan Added some synchronization to force gl updates to actually run on the…
… GL thread...
8b577bd
Commits on Aug 11, 2011
@ZhouWeikuan Merge pull request #29 from dustinanon/master
This should fix the white texture bug.
cf48bbb
Showing with 36 additions and 6 deletions.
  1. +36 −6 cocos2d-android/src/org/cocos2d/opengl/GLResourceHelper.java
View
42 cocos2d-android/src/org/cocos2d/opengl/GLResourceHelper.java
@@ -102,7 +102,11 @@ public void perform(GL10 gl) {
*/
public void perform(GLResorceTask res) {
if(inUpdate) {
- res.perform(CCDirector.gl);
+
+ /** check if the taskQueue is locked */
+ synchronized(taskQueue) {
+ res.perform(CCDirector.gl);
+ }
} else {
taskQueue.add(res);
}
@@ -115,16 +119,42 @@ public void perform(GLResorceTask res) {
* perform all tasks in GL thread
* @param gl
*/
- public void update(GL10 gl) {
- if(taskQueue.size() > 0) {
+ public void update(final GL10 gl) {
+ r.setGL(gl);
+
+ /** lock the taskQueue and force the update to run on the GL thread */
+ synchronized (taskQueue) {
+ CCDirector.sharedDirector().getOpenGLView().queueEvent(r);
+ }
+ }
+
- GLResorceTask res;
- while((res = taskQueue.poll()) != null) {
- res.perform(gl);
+ /** custom runnable for doing the GL Update */
+ private class GLRunner implements Runnable {
+
+ GL10 gl;
+
+ @Override
+ public void run() {
+ if(taskQueue.size() > 0) {
+
+ GLResorceTask res;
+ while((res = taskQueue.poll()) != null) {
+ res.perform(gl);
+ }
}
}
+
+ public void setGL(GL10 gl) {
+ this.gl = gl;
+ }
+
}
+ final GLRunner r = new GLRunner() {};
+
+
+
public void setInUpdate(boolean inUpd) {
inUpdate = inUpd;
}

Showing you all comments on commits in this comparison.

@opengenius
Collaborator

update is called from GL thread only, why do you perform onother queue? this class was designed for performing update in this point. Now when tests starts I see white quads.

@opengenius
Collaborator

update is called from GL thread only, why do you perform onother queue? this class was designed for performing update in this point. Now when tests starts I see white quads.

@dustinanon

Really? On my Samsung Galaxy Tab I had frequent white textures, >=50% of the time... now I see none. Maybe there is some inconsistency between devices?

Check this Issue Thread for the discussion that lead to this code: #20

@opengenius
Collaborator

Now I can see blinking quads for a while on my HTC Desire after cclabel update, after home-resume and this happens always.

@dustinanon

Wierd... on my Samsung Galaxy Tab (v1) it fixes all my sprite related problems... I was getting white textures for all sprites and labels, but it's perfect now... to be honest, I'm not entirely sure of the problem, and because of my lack of complete understanding of the system, I'm not entirely sure of the cause. I just know that this fix was proposed by another contributor to the project and when I tested it, it worked for me.

@dustinanon

I was premature on saying that... it would be best to roll this commit back out. :(

It seems that the white textures issue still persists on my machine with this change, albeit less often. FWIW, it seems to happen more often with larger sprites than smaller sprites (1024 x 768 vs 100 x 100).

@vcarluer

I didn't follow all your discussion about this issue but for information I had white textures when I loaded them from a new dedicated loading thread. When I load from main thread it does not do that (but it freezes ui^^). I am on a version of 1 month ago for info.

@dustinanon

Well, regardless of what thread you execute the loading from, it's SUPPOSED to execute on the GLThread, in fact, attempting to load from any other thread will cause the request to be queued onto the end of the GLThread.

It seems that there's some issues with that though. I'm not exactly sure what's causing the problem though. It must be some thread concurrency issue, that's the only thing that even seems remotely plausible, but all the threading appears to be properly handled so it's quite a conundrum for me atm.

Something went wrong with that request. Please try again.