Adobe AIR Development

[TheDarkIn1978]

i just started testing my display assets on the simulator (v 0.9.3) with discouraging results.

for portability / future-proofing purposes, my display assets are large vector (one or two bitmap) files which are scalled down proportionaly to match the height of the target device's screen.

when testing in ADL, these assets are anti-aliased and look as they should.  however, when testing on the simulator the display assets look very jagged around the edges - even on vector assets!  this is also also the case for assets that are not scalled.

i'm using the command line to package / install the application as i'm using Flash Professional CS5 (which contains the scalable vector assets in the library)

any ideas why this is happening?

--

EDIT:  creating and embedding an assets.swf containing the vector sprites in Flash Builder also exhibits the same aliased results when debugging on the simulator.

[jtegen]

Keep in mind the final simulator has a lot denser screen resolution than the simulator or the desktop, so you have to assume the anti-aliasing along the edges will be better.

[TheDarkIn1978]

i had assumed that at first, but then i noticed the icon for Browser as well as the text on the home screen and setting panel is perfectly smooth and crisp.  therefore, i'm not sure that this aliasing problem will be any less visible on the device.

[jtegen]

An image and the graphics drawing routines render differently.  I have some graphics drawing that can easily be off a pixel and look like ***beep***. I recall that there is "sub-pixel" math that can be turned on since normal graphics is done at the integer level.  I cant recall where I saw this.  When I create PNG files, there is a world of difference between PNG-8 and PNG-24.

[TheDarkIn1978]

hand coded graphics exhibit the same aliasing problem (noticable on the white stroke):

package
{
	//Imports
	import flash.display.GradientType;
	import flash.display.Sprite;
	import flash.geom.Matrix;

	//Class
	[SWF(height="600", width="1024", frameRate="30", backgroundColor="#444444")]
	public class PlayBookTest extends Sprite
	{	
		//Constructor
		public function PlayBookTest()
		{
			init();
		}
		
		//Initialize
		private function init():void
		{
			var sp:Sprite = new Sprite();
			
			var matrix:Matrix = new Matrix();
			matrix.createGradientBox(200, 200, Math.PI / 2.95);
			
			sp.graphics.beginGradientFill(GradientType.LINEAR, [0xFF0000, 0xFFFF00, 0x0000FF], [1.0, 1.0, 1.0], [0, 95, 225], matrix);
			sp.graphics.lineStyle(2, 0xFFFFFF);
			sp.graphics.lineTo(0, 0);
			sp.graphics.curveTo(20, 100, 200, 10);
			sp.graphics.curveTo(100, 100, 125, 200);
			sp.graphics.curveTo(0, 200, 0, 0);
			
			sp.x = stage.stageWidth / 2 - sp.width / 2;
			sp.y = stage.stageHeight / 2 - sp.height / 2;
			
			addChild(sp);
		}
	}
}

[kdittyr]

I have an application that graphs a bunch of results and noticed this as well. I was a lot underwhelmed by the results I was seeing, but it looks great outside of the simulator.

I figured it had to do with density as well.

[TheDarkIn1978]

it would be nice to have confirmation from RIM on this, eventhough it wouldn't really make a difference at this stage of the game.

fingers crossed that it's an issue with pixel density.

[kdittyr]

I just wanted to add a few images to back up what I am seeing in my second application to better illustrate my situation, and help to backup TheDarkIn1978's claim.

I decided to just use attachments as they show up quicker ( I think ) and also they show at 100%.

See below for attachments if interested.  Exact same code used to create both graphics, the only difference is the data points.  If need be I can certainly take the time to make the logbook entries exactly the same for better comparison.

[jtegen]

I see this too on much simpler geometry.  A single rectangle or round rectangle will be off by a pixel and the anti-alias on the simulator just **beep**.  I am just hoping that the final device has a lot better rendering tailored to its resolution than the simulator does.

[peter9477]

I'm now thinking this is the same underyling cause for the asymmtery that led me to add "+2" and "-2" compensating factors for several of control points in my bezier curves in the corners of the "popover" box code.  I never actually tried it on the desktop, but on the simulator it certainly looked bad without that.

I think perhaps the implementation of OpenGL that is being used in the simulator, which is x86-based, is turning out to have problems that, as John said, we can hope will not be on the ARM-based device.

Unfortunately it may well mean we can't rely on what we see on the simulator to tell us reliably how it will look on the final device, which poses a problem for all these sim-based early apps.

RIM: now would be a really good time to have somebody get a bit more involved in this forum for a moment, as in someone with access to the actual device, who could test out some sample code or in some other way confirm some of this speculation.  Do we have to test our graphics on the desktop and go by how it looks there, or what?