<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Adobe to ARM mobile devices with Flash 10</title>
	<atom:link href="http://jkontherun.com/2008/11/17/adobe-to-arm-mo/feed/" rel="self" type="application/rss+xml" />
	<link>http://jkontherun.com/2008/11/17/adobe-to-arm-mo/</link>
	<description>Using mobile devices since they weighed 30 lbs.</description>
	<lastBuildDate>Sat, 21 Nov 2009 21:10:32 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mark H</title>
		<link>http://jkontherun.com/2008/11/17/adobe-to-arm-mo/#comment-171</link>
		<dc:creator>Mark H</dc:creator>
		<pubDate>Mon, 17 Nov 2008 12:08:53 +0000</pubDate>
		<guid isPermaLink="false">http://jkontherun.wordpress.com/2008/11/17/adobe-to-arm-mo#comment-171</guid>
		<description>&lt;div xmlns=&quot;http://www.w3.org/1999/xhtml&quot;&gt;
        &lt;p&gt;I&#039;d love to see Adobe AIR on mobile devices. Imagine using one development environment to create (basic) desktop and mobile applications. Though Java already provides this but support is a bit patchy on Windows Mobile and I believe doesn&#039;t exist yet on the iPhone.&lt;/p&gt;
      &lt;/div&gt;</description>
		<content:encoded><![CDATA[<div xmlns="http://www.w3.org/1999/xhtml">
<p>I&#8217;d love to see Adobe AIR on mobile devices. Imagine using one development environment to create (basic) desktop and mobile applications. Though Java already provides this but support is a bit patchy on Windows Mobile and I believe doesn&#8217;t exist yet on the iPhone.</p>
</p></div>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian E</title>
		<link>http://jkontherun.com/2008/11/17/adobe-to-arm-mo/#comment-172</link>
		<dc:creator>Brian E</dc:creator>
		<pubDate>Mon, 17 Nov 2008 08:34:39 +0000</pubDate>
		<guid isPermaLink="false">http://jkontherun.wordpress.com/2008/11/17/adobe-to-arm-mo#comment-172</guid>
		<description>&lt;div xmlns=&quot;http://www.w3.org/1999/xhtml&quot;&gt;&lt;p&gt;The problem with Flash now on ARM processors isn&#039;t that it isn&#039;t optimized for ARMs. The problem is that Flash isn&#039;t optimized for anything. You can offload as much of the video processing as you like, and while that will get you YouTube, it won&#039;t get you acceptable performance on other Flash-heavy web sites.&lt;/p&gt;

&lt;p&gt;One part of the problem is in the ActionScript language that&#039;s used to drive Flash interactivity. It&#039;s an extended variant of JavaScript, and like JavaScript it wasn&#039;t designed to be compiled. When you&#039;re just using it to do a little bit of event processing magic, using an interpreter makes perfect sense. When you&#039;ve got it driving your animations, then it starts to break down. Unfortunately the language has picked up a lot of cruft that makes running it fast very, very difficult. The browser vendors are throwing lots of smart people at improving the JavaScript performance situation, and all of that work is applicable in some form to ActionScript, but it will never really be fast. Microsoft has a much better starting point in the CLR (Common Language Runtime) that&#039;s built into Silveright 2.0, but I really doubt they&#039;re going to get much traction here.&lt;/p&gt;

&lt;p&gt;Another part of the problem is in the Flash canvas itself. Flash 10 has done a lot to improve this situation, but developers will need to adopt the new features before they have an effect. Right now, even text is done as a set of curves, which prevents the type of glyph-caching optimizations that are typically done in a device text renderer to make antialiased text rendering possible on a small device. Scrolling a Flash text widget can be painful for this reason.&lt;/p&gt;

&lt;p&gt;Everything adds up. Like HTML and HTTP and JavaScript, Flash will always be a waste of processor power and bandwidth. I&#039;d like to see a cleaner starting point built around the idea of energy efficiency on the device itself, but that&#039;s a losing battle as compatibility trumps all.&lt;/p&gt;

&lt;p&gt;The good news is that it is possible to make Flash several times faster, and Adobe does seem to be on the right track. Between this and the Canonical joint venture for Ubuntu, ARM seems to be heavily investing in optimizing software for the ARMv7 architecture in the Cortex processors. Since the ARM instruction set has undergone rapid evolution, they&#039;d like to see more software optimized for the latest processors rather than built in a compatibility version that runs on processors in five-year-old cell phones. In particular there are instructions in ARMv7 which are designed to improve the performance of dynamic runtimes like Flash. This processor extension was derived from the Jazelle instructions for accelerating Java 2 ME applications, but broadened to make it more applicable to other languages. I suspect that taking advantage of these instructions is on ARM&#039;s agenda here.&lt;/p&gt;&lt;/div&gt;</description>
		<content:encoded><![CDATA[<div xmlns="http://www.w3.org/1999/xhtml">
<p>The problem with Flash now on ARM processors isn&#8217;t that it isn&#8217;t optimized for ARMs. The problem is that Flash isn&#8217;t optimized for anything. You can offload as much of the video processing as you like, and while that will get you YouTube, it won&#8217;t get you acceptable performance on other Flash-heavy web sites.</p>
<p>One part of the problem is in the ActionScript language that&#8217;s used to drive Flash interactivity. It&#8217;s an extended variant of JavaScript, and like JavaScript it wasn&#8217;t designed to be compiled. When you&#8217;re just using it to do a little bit of event processing magic, using an interpreter makes perfect sense. When you&#8217;ve got it driving your animations, then it starts to break down. Unfortunately the language has picked up a lot of cruft that makes running it fast very, very difficult. The browser vendors are throwing lots of smart people at improving the JavaScript performance situation, and all of that work is applicable in some form to ActionScript, but it will never really be fast. Microsoft has a much better starting point in the CLR (Common Language Runtime) that&#8217;s built into Silveright 2.0, but I really doubt they&#8217;re going to get much traction here.</p>
<p>Another part of the problem is in the Flash canvas itself. Flash 10 has done a lot to improve this situation, but developers will need to adopt the new features before they have an effect. Right now, even text is done as a set of curves, which prevents the type of glyph-caching optimizations that are typically done in a device text renderer to make antialiased text rendering possible on a small device. Scrolling a Flash text widget can be painful for this reason.</p>
<p>Everything adds up. Like HTML and HTTP and JavaScript, Flash will always be a waste of processor power and bandwidth. I&#8217;d like to see a cleaner starting point built around the idea of energy efficiency on the device itself, but that&#8217;s a losing battle as compatibility trumps all.</p>
<p>The good news is that it is possible to make Flash several times faster, and Adobe does seem to be on the right track. Between this and the Canonical joint venture for Ubuntu, ARM seems to be heavily investing in optimizing software for the ARMv7 architecture in the Cortex processors. Since the ARM instruction set has undergone rapid evolution, they&#8217;d like to see more software optimized for the latest processors rather than built in a compatibility version that runs on processors in five-year-old cell phones. In particular there are instructions in ARMv7 which are designed to improve the performance of dynamic runtimes like Flash. This processor extension was derived from the Jazelle instructions for accelerating Java 2 ME applications, but broadened to make it more applicable to other languages. I suspect that taking advantage of these instructions is on ARM&#8217;s agenda here.</p>
</div>
]]></content:encoded>
	</item>
</channel>
</rss>
