layoutSubviews in EAGLView is broken - how to work around it for retina display?

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

layoutSubviews in EAGLView is broken - how to work around it for retina display?

(32 posts) (3 voices)

Started 7 months ago by michail
Latest reply from araker

Tags:

12 Next »

michail
Member

Preventing the first call to EAGLView's layoutSubviews from occurring seems to fix a rather lengthy freeze that occurs on some devices (with both retina and non-retina displays but apparently not with the iPad).

But skipping the first layoutSubviews call introduces a problem with the retina display - retina mode isn't enabled in cocos2d and the graphics are off.

How do I get retina mode working in cocos2d without letting the broken layoutSubviews in EAGLView call execute the first time it is called?

This bug is present in cocos2d for iPhone v1.0.1.

Posted 7 months ago #
cocos
Member

@michail Could you submit bug report? Demo project illustrating the problem would helpful.
http://code.google.com/p/cocos2d-iphone/issues/list
Thanks!

Posted 7 months ago #
michail
Member

Is there a workaround that I can use for now?

Posted 7 months ago #
cocos
Member

@michail I am not aware of the workaround. If you submit a bug report there is a good chance for fix or workaround. Then the problem can be analyzed.
Could you do that? Thanks!

Posted 7 months ago #
araker
Moderator

@michail, without a test case it's difficult to tell what's going wrong. Like you observed by not executing the first layoutSubviews, the OpenGL view isn't created properly at the time that enableRetinaDisplay is called. EnableRetinaDisplay checks whether the OpenGL view reponds to setContentScaleFactor, which won't work if there is no view yet. At least that's what I think it is.

You could release your first scene in the first frame and call enableRetinaDisplay again to get the right contentScaleFactor and then initialize the scene again.

Several people have reported this bug, but none could provide a test case or even more specific information. It would be very helpful if you could provide one.

A workaround that seemed to help for users was to switch to another app and back again.

Posted 7 months ago #
michail
Member

What about this workaround instead of the first call to layoutSubviews (copied from EAGLView.m but without drawing the scene):

size_ = [renderer_ backingSize];

[renderer_ resizeFromLayer:(CAEAGLLayer*)self.layer];

// Issue #914 #924
CCDirector *director = [CCDirector sharedDirector];
[director reshapeProjection:size_];

Posted 7 months ago #
michail
Member

Strangely, the EAGLView contents persist (very briefly) across separate runs of the app on a 2nd gen iPod touch (no multitasking). How could that happen? Why isn't the EAGLView cleared upon initialization?

Posted 7 months ago #
araker
Moderator

That line was there to prevent artifacts in the first rendering frame. As a temporary workaround it's good enough, but as you see it can introduce a new issue.

One other thing, size_ = [renderer_ backingSize]; needs to be directly after [renderer_ resizeFromLayer:], that will be fixed in 1.1. Maybe it's related to your problem.

Edited response to new reply

Posted 7 months ago #
michail
Member

Swapping those two lines could eliminate those freezes?

Posted 7 months ago #
araker
Moderator

I don't know, I don't have a test project to work with.

Posted 7 months ago #
michail
Member

The problem isn't reproducible in the sense that I still don't know precisely which devices encounter this problem. So submitting a bug report may not help if it works on all your devices...

Posted 7 months ago #
cocos
Member

@michail If you do not submit than for sure no one is going to help you. If you do your chances are better.

Posted 7 months ago #
araker
Moderator

Does it happen on your 2nd gen iPod touch? I have one of those. If you can spare some time to make a test case, there are a few things that I'd like to try out. Thanks.

Posted 7 months ago #
michail
Member

No, it doesn't happen on my 2nd gen iPod touch. It also doesn't happen on my 1st gen iPad.

Posted 7 months ago #
michail
Member

Swapping those two lines doesn't fix the freeze problem.

Posted 7 months ago #
araker
Moderator
Too bad that didn't work.

I presumed you had access to a device that showed the bug, this makes it more complicated. We can try to systematically reduce possible causes.

Things that come to mind are
1) too intense loading of resources at start-up which causes memory problems.
2) memory problems because the device hasn't been restarted for a long time.
3) drawScene will eventually call swapBuffer which could stall if there is no valid EAGLView present
4)something in drawScene is causing the stall

1 and 2 are things you can check with the user that's experiencing the problem. 3, you were already working on that. Did it help to remove the call?

4 can be checked by inserting the following code in layoutSubViews (instead of the drawScene call)
```
//minimal opengl calls to warm the pipeline.
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glClearColor(0.0f,0.0f,0.0f,1.0f);
  float verts[]={0.f,0.f,0.f,0.f,0.f,0.f,0.f,0.f};
  glVertexPointer(2,GL_FLOAT,0,verts);
  glDrawArrays(GL_TRIANGLE_FAN,0,4);
  [self swapBuffers];
```
Posted 7 months ago #
michail
Member

The minimal code above (but using a zero alpha value) instead of the drawScene call still results in a lengthy freeze.

Posted 7 months ago #
michail
Member

@araker, refining my workaround, one can hide the EAGLView to prevent artifacts in the first rendering frame.

Posted 7 months ago #
michail
Member

@araker, it turns out that the hiding the EAGLView to prevent artifacts in the first rendering frame simply delays the freeze.

Posted 7 months ago #
michail
Member

@araker, actually, it looks like this code is causing the freeze problem:

[renderer_ resizeFromLayer:(CAEAGLLayer*)self.layer];
size_ = [renderer_ backingSize];

// Issue #914 #924
CCDirector *director = [CCDirector sharedDirector];
[director reshapeProjection:size_];

Posted 7 months ago #
araker
Moderator

Good to see that you're narrowing it down.

ReshapeProjection just sets a new projection, it's unlikely to be the culprit here. ResizeFromLayer on the other hand resizes the frame buffer and attachments to cope with the new window dimensions. It's pretty necessary to ensure correct rendering.

Unfortunately without having more information I wouldn't know how to solve this.

Btw, I've deleted your new topic, it's better to keep the information in one place.

Posted 7 months ago #
michail
Member

The call to resizeFromLayer is not necessary for a non-retina display apparently.

What is the minimum required to get cocos2d graphics working properly on a retina display while doing less than / avoiding resizeFromLayer?

Posted 7 months ago #
araker
Moderator

No that's not true, resizeFromLayer is always called once during initialization on all devices. If you're using a UIViewController to handle orientation changes, it will also be called every time the orientation changes.

To get a another angle on this, I've looked at the default initialization code of the OpenGL template and it differs a bit. Every time layoutSubViews is called, all OpenGL buffers are deleted and recreated again. Cocos only resizes the buffers.

I think it's interesting to see if this makes a difference (even though the chances are small). I've changed the EAGLView and ES1Renderer to mimic the setup in the template. You can find the source here.

Posted 7 months ago #
michail
Member

@araker, it works!!!

Posted 7 months ago #
araker
Moderator

That's good news. I'll make a patch for 1.1 to include this.

Posted 7 months ago #
michail
Member

Could you tell me when 1.1 might be released?

Posted 7 months ago #
araker
Moderator

Sorry, can't say anything yet about the possible release date of 1.1. The patch is ready though, you can download it here.

Posted 7 months ago #
michail
Member

@araker, sometimes this error occurs with the new code (from http://www.megaupload.com/?d=UO3ZIB2I):

OpenGL error 0x0502 in -[EAGLView swapBuffers]

Is it harmless?

Posted 7 months ago #
araker
Moderator

Error 0x502 means GL_INVALID_OPERATION, it shouldn't happen when everything is correctly initialized. Could you check whether it still occurs within the latest patch? The megaupload code was a quick test to see if it would work. The patch contains a few improvements on that code.

Posted 7 months ago #
michail
Member

@araker, the OpenGL error 0x502 issue is still there with the latest patch.

Is it a big deal? It seems harmless.

Posted 7 months ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.