Yeah, only on G2 builds… G1 builds are fine.
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
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.
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.
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?)
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…
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.
Not that I’ve seen. I’m still experimenting with this to find the best brush sizes to work with.
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.
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.
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.
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.
@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.
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.