Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

[RESOLVED] Weird framebuffer image bug on iOS devices in G 2.0 builds
Started by Stephen Lewis Nov 23 2013 09:40 AM

17 replies to this topic
[TOPIC CONTROLS]
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

I have a strange visual artifact when I build my project in G 2.0.  Basically, when I transition between my scenes (I'm not using storyboard or director) an image of the very first screen displayed after launch flashes in front of everything else.  Repeatedly transitioning from scene to scene, the same image keeps appearing for a second at the beginning of the transition. Moreover, if I press the home button to suspend the app, then return to the app, the last screen prior to the suspend is now the image the flashes to the front during scene transitions.   

 

This only happens on iOS devices (tested on 3GS, iPad2, and iphone 5), not the simulator or the Android devices i've tested on, and only on Graphics 2.0 builds.  I tried previous daily builds and the problem finally disappears with daily 1260, so this seems related to the new graphics 2.0 engine.  I don't know much about openGL, or framebuffers, so my terminology is probably off, but it seems to be a fullscreen image leftover, like a framebuffer wasn't properly cleared or is being switched into view when it shouldn't be.

 

My project is currently built with daily 2088 with 1.0 compatibility mode true, but I also see the problem on the very first G2.0 daily build.  

 

I made an attempt at creating a simpler test case that reproduces the issue, but no luck.  So far all my efforts at working around it in my project have been fruitless.  I'm wondering if anyone else sees something similar, or if anyone at Corona Labs might have some insight.  

 

Thanks,

 

-Stephen



[TOPIC: post.html]
#2

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

I've also seen this, and as you also say, only on iOS devices. It's also with a project where I used my own scene management ( project was made before Storyboard existed). The problem is that when I try to recreate the issue with a simpler example it works as expected.

[TOPIC: post.html]
#3

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

Thanks for the confirmation ingemar.  I, too, have had no luck so far recreating the issue with a simpler project. I was hoping that the symptoms might spark some kind of "a-ha" moment for someone at Corona Labs.  Just to be sure we are seeing the same thing, are you also saying it only happens for you with the G2.0 builds?

 

I've done bunches of tests, turning off various aspects of my transition code but can't isolate where the issue is coming from.  Again, it is only happening in G2.0 builds so it really does seem like something fundamental under the graphics engine hood broke, and only for iOS devices.  



[TOPIC: post.html]
#4

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Yeah, only on G2 builds... G1 builds are fine.

[TOPIC: post.html]
#5

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

After a full day of brute force debugging I boiled down a much simpler version of my scene transitioning code that still exhibits the problem. While pretty compact it's still a multi lua file project with image files so I won't include it here, but I submitted a bug with the project.  (Case 28408)

 

In its' boiled down state I get a slightly different version of the bug where the current scene displays completely black even though touch areas are still working.  When the scene transition is triggered the new scene flashes on briefly during the transition and then the screen goes back to black.  If I then suspend/resume the app the screen now shows the scene that was on screen prior to the suspend. If I continue to switch scenes again and again the new scene flashes briefly and then the display always reverts to the same image of the old scene displayed prior to the suspend! 

 

I notice other recent threads reporting apps built with G 2.0 that were black screens though not crashed, and these were on certain Android devices such as the S2, so perhaps this is the same bug.  I hope someone at Corona Labs can take a look at the bug.

 

-Stephen



[TOPIC: post.html]
#6

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

@stephen
It's great that you found a way to create a test project for this.

Thanks,
Ingemar

[TOPIC: post.html]
#7

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

The cause of all my problems was setting antialias = true in config.lua.  Long ago I had this set to false because it was then known to cause lots of graphics glitching.  More recently I had turned it back to true since those issues appeared to be fixed.  But now, with Graphics 2.0, it's causing problems again.  I see a bunch of recent threads that sound like they might be related.  So, ingemar, I would suggest checking your app's antialias setting.

 

Coronalabs, any chance this can get re-fixed?  Antialias = true is pretty useful for de-jagging lines and border outlines.



[TOPIC: post.html]
#8

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Aha! You've been hit by that one too! Yes, antialias=true causes all sorts of weird behavior with Graphics 2.
I submitted a bugreport about this issue last week.

However I've still seen some framebuffer issues even with antialias=false, but I haven't been able to put my finger on it yet because I can't get consistent results with my sample app. Most of the time it works, but sometimes it doesn't. However it looks like it only affects iOS devices too.

[TOPIC: post.html]
#9

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

Yikes, bummer it is still an issue.  At least antialias = true causes the problem consistently, so perhaps if they can get to the root cause and fix it that will clear up the other issues (I can dream, can't I?)



[TOPIC: post.html]
#10

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Shucks. my bad. Before I knew about the antialias=true problem, I had made some changes to my code to try to find out what the problem was. I thought I had rolled everything back but, thanks to the power of git, I found a previous commit where I had made the breaking I was still seeing. After rolling back that change I don't see the problem anymore.

The only issue is the antialias=true setting now. As long as it's false everything is OK.
It would be great if they could find out what the problem may be. I'd like to be able to use the antialias feature to smooth out borders and lines. The way I'm handling it now is applying an image stroke to the objects where the image is a feathered circle. It works, but I'd still like to use the hardware's capability to do this instead...

[TOPIC: post.html]
#11

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

Your feathered circle trick sounds pretty cool.  Does it leave a more opaque dot at the beginning/end of a closed stroke where the circle would be drawn over twice, such as around a rectangle?

 

 I'm forced to use compatibility mode so I'm not sure I can even use the new features, though.



[TOPIC: post.html]
#12

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Not that I've seen. I'm still experimenting with this to find the best brush sizes to work with.

[TOPIC: post.html]
#13

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

I tried a variation of your feathered circle (instead I'm using a solid square image that tapers to transparent on the top and bottom edges) to paint the borders around rounded rectangles and it works well.  So it looks like I can use some of the G2 features after all, even with G1 compatibility on.  Now I will simply leave antialias off for good.  I've wasted so much time chasing bugs that were caused by its glitchy behavior I don't think I would risk using it even if it gets "fixed" again.  



[TOPIC: post.html]
#14

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

Square brush. Interesting. I'm going to try that too and maybe also an oval brush just to see what happens :-)

Another thing I noticed is that the hardware antialiasing didn't really work as well as I had expected. I think that our approach will yield better results even though it requires a few more graphics assets. I'm planning to include a brush imagesheet which includes all brushes / sizes / shapes that I'd use in a project.

[TOPIC: post.html]
#15

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

I agree, the hardware antialiasing left a lot to be desired (still better than no antialiasing).  But using the new stroke with image technique works well.  

 

I've attached an example of the stroke image I've been using in case you want to experiment with it.  Using it with a strokeWidth of between 2 and 6 looks great.  Anything more and it starts to look blurry.  I guess if you knew you were going to use wider strokes you could just use a bigger image, or perhaps a more severe drop off to transparency would work.

Attached Files



[TOPIC: post.html]
#16

Bryan01

[GLOBAL: userInfoPane.html]
Bryan01
  • Enthusiast

  • 95 posts
  • Corona Staff

A change has been made to daily builds (> 2092) to disable antialiasing on iOS.  We will look into enabling this in future builds. This change is in place for compatibility with Graphics 1.0 until the issues is resolved.



[TOPIC: post.html]
#17

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

@stephen
Looks good.

I'm planning to have an imagesheet with assorted brush shapes and sizes that I can use throughout my projects.
The images will be white so that I can tint the color of the brush to any color I want.

[TOPIC: post.html]
#18

ingemar

[GLOBAL: userInfoPane.html]
ingemar
  • Corona Geek

  • 2,733 posts
  • Enterprise

I've been experimenting with different solid brushes and I came across an unexpected result that renders very good results.

The unexpected "formula" I used to create a solid brush is 1px wide x stroke-width+2px high.

 

So for a stroke of 4 pixels I create an image that is 1px by 6px. The trick is to always leave the top and bottom pixel transparent.

I create the brushes white, so that I can use setStrokeColor to tint the stroke to any color I want.

 

I'm continuing to experiment, but so far this formula has turned out to give me the best results.




[topic_controls]
[/topic_controls]