DevelopmentArc - Helping clients build for the future

Adding Superscript and Subscript support to HTML text via Text Layout Framework (TLF)

Aaron Pedersen — Wed, 23 Feb 2011 20:42:28 +0000

For a recent client project, we were having an issue with using superscript to display the number next to a disclaimer information. In HTML this is accomplished by simply wrapping a tag around the text. For example: "1 The client wants a disclaimer here." looks like:

¹ The client wants a disclaimer here.

However, Flash does not support superscripts or subscripts in HTML text out of box, so a "hack" of some sort needed to be applied

Looking around I found two solutions. The first is fairly old (2007/2008) and uses a combination of some regular expression magic to convert and tags into HTML tags. The solution next used an extra set of embedded fonts that were created for superscirpt and subscript. Here is the blog post for reference.

This solution is a reasonable but requires the process of embedding two extra fonts into the application to get the desired result.

The second approach was to use the Text Layout Framework (TLF) in Flex 4 and take advantage of the baselineShift property to create subscript and superscript text. See this Adobe blog for reference.

My personal desire was to use the TLF approach so we would not have to embed extra fonts into the application. Plus, our application reads in text dynamically that is formatted as simply HTML and is then converted into TLF via the TextConverter.importFlow() method. Here is a quick example of the conversion.

var richText:RichText = new RichText();
richText.textFlow = TextConverter.importToFlow(ourContentAsString,
TextConverter.TEXT_FIELD_HTML_FORMAT);

Since we are using the TextConvert to convert HTML into TLF, we don't have a chance to modify any or tags that might be within the HTML string. The challenge is that the converter will actually strip out those tags (and any other unsupported tags), during conversion.

So what to do...

We found a way to combine both methods. We first use the regular expression magic outlined in the first blog, to convert all and into tags that TextConverter will not remove.

// create regular expressions
var supStartExpression:RegExp = new RegExp("", "g");
var supEndExpression:RegExp = new RegExp("", "g");
var subStartExpression:RegExp = new RegExp("", "g");
var subEndExpression:RegExp = new RegExp("", "g");

// replace all tags
htmlContentAsString = htmlContentAsString.replace(supStartExpression,
"");
htmlContentAsString = htmlContentAsString.replace(supEndExpression, "");
htmlContentAsString = htmlContentAsString.replace(subStartExpression,
"");
htmlContentAsString = htmlContentAsString.replace(subEndExpression, "");

// convert HTML into a TextFlow element var textFlow:TextFlow = TextConverter.importToFlow(htmlContentAsString,format, config); // format superscript and subscripts in TextFlow formatCustomTextFlow(textFlow);

You will notice, instead of converting each / into tags like in the first blog post suggests, we instead use tags and add a class attribute based on what tag ( or ) we are converting. We do this for one main reason, when we convert HTML into TLF each found will be converted into a SpanElement object and we need a way to mark each SpanElement with what they were prior in HTML. This is so that we can act upon it in the next step when we call our method formatCustomTextFlow(). The TextConverter takes the 'class' attribute we define on the and during the conversion, assigns the value to the 'styleName' property on the SpanElement.

The output from this part will be a single TextFlow element, which will have children for each HTML element found in the text. We will next traverse the entire TextFlow hierarchy of children searching for FlowElements (SpanElement is a decedent of FlowElement). We start this by calling a custom method formatCustomTLF(). In this method we examine each mxmlChild of the TextFlow element. We first look to see if the element is of type FlowElementGroup. If so, we know it might have children, so we loop over all it's children calling formatCustomTLF(). If the element is not a FlowElementGroup and has a styleName attribute value of "superscript" or "subscript", we process it. We process the FlowElement by setting the baselineShift property based on the styleName. So if the stylename is "superscript" we set the baselineShift equal to BaselineShift.SUPERSCRIPT and then remove the styleName value. Here's a look at the code.

private function formatCustomTLF(element:FlowElement):void {
// if FlowElement is a group loop over it's children and format them
if(element is FlowGroupElement) {
var parentAsGroupElement:FlowGroupElement = FlowGroupElement(element);

   for each(var childElement:FlowElement in parentAsGroupElement.mxmlChildren) {
      formatCustomTLF(childElement);
   }
}
// set baselineShift based on stylename
else if(element.styleName == "superscript") {
   element.baselineShift = BaselineShift.SUPERSCRIPT;
   element.styleName = "";
}
else if(element.styleName == "subscript") {
   element.baselineShift = BaselineShift.SUBSCRIPT;
   element.styleName = "";
}
}

After that, we have our superscript and subscript support in our html content!

Here's a sample Flex application you can download and import into Flash Builder 4, that demonstrates the entire technic.

The invalidateSkinState() Trap

James Polanco — Mon, 22 Nov 2010 21:03:20 +0000

A while back, a friend of mine and fellow Flex developer was consulting on a Flex 4 based application. He was having a troublesome issue where in some cases the skin state was not updating in his application when he called invalidateSkinState(). The problem was that when he called invalidateSkinState(), the getCurrentSkinState() was never called during the next commit properties phase (think validation during maturity, eee our whitepaper for more details). It wasn't consistent in the code and it only happened in a few specific cases.

He asked me if I had ever seen the issue where getCurrentSkinState() is skipped after calling invalidateSkinState(). At that time I had never seen a problem with the Skin state not updating, so I didn't have much guidance for him. He found a solution which involved making sure to call both invalidateSkinState() and invalidateProperties() at the same time, even though invalidateSkinState() should also invalidate properties for you.

About three weeks later, I stumbled upon the same issue while working on an application. Inexplicably, one of my components started ignoring invalidateSkinState() and the skin wouldn't change. After setting some breakpoints and screaming at the code for a while I finally figured out what the cause was. I had mistakenly used invalidateSkinState() within the commitProperties() after calling super.commitProperties():

/* don't do this... */
override protected function commitProperties():void {
// call super first

super.commitProperties();

... calculate data, set the flag if the skin needs to change ...

     // set the skin state
     if(_flag) {
          _stateIWant = "stateName";
          invalidateSkinState();
     }
}

I am simplifying the code dramatically, but what I was trying to do was during the commit phase I was calculating a lot of data set by a dataProvider. If the data had certain properties I needed to change the state of my skin, and that was why I was calling invalidateSkinState() post-data calculation. The core issue was that during the setting of the dataProvider, I had no idea if my skin had to change or not because the new data had to be processed before I could determine what state I needed to be in. At that point, I still wanted to delay the data processing until the commit phase, so I deferred the calculation until later and then post-calculation I could set the proper state.

Looking back, this was clearly a bad thing to do but at the time it seemed like a reasonable request. The problem with this call is around order of operation. Let's look at the order of operation within the UI component:

Invalidation
1. invalidateProperties() is called
2. invalidateProperties() sets invalidatePropertiesFlag = true
3. The component registers with LayoutManager for the next validation pass
Validation
1. LayoutManager begins the validation pass (started by ENTER_FRAME / RENDER event)
2. LayoutManager calls validateProperties() on the invalid component
3. validateProperties() determines if invalidatePropertiesFlag is set to true
4. if true, validateProperties() calls overridden commitProperties()
5. overridden method first calls super.commitProperties()
6. super.commitProperties() determines if the skinStateIsDirty has been marked true (set via invalidateSkinState())
7. if skinStateIsDirty is true it calls getCurrentSkinState() to get the state name
8. super is complete and returns to the overridden method
9. we process the data, determine the skin needs to change
10. we call invalidateSkinState()
11. invalidateSkinState() sets skinStateIsDirty to true and calls invalidateProperties()
12. invalidateProperties checks to see if invalidatePropertiesFlag is already set to true
13. invalidatePropertiesFlag is set to true (we are still validating at this point), so invalidateProperties() does not re-start the invalidation process
14. commitProperties is complete, and returns to validateProperties(), remember we are synchronous at this point
15. invalidatePropertiesFlag is set back to false
16. validation process is complete
Re-Invalidation
1. At some point post the last validation pass, we call invalidateSkinState()
2. invalidateSkinState() checks skinStateIsDirty, which is still set to true so invalidateProperties() is not called

At there lies the crux of the issue. The problem is that when we call invalidateSkinState() it still thinks the skin flag is dirty, meaning we are already waiting for a validation pass and therefore we don't restart the invalidation process. This means that our skin flags are now out of sync and we get odd behavior until the next full invalidation process goes through. Of course we may keep re-entering into the same conflict over and over depending on how circular our logic is in the code.

The way to fix this is to move our logic BEFORE the super call:

/* acceptable fix */
override protected function commitProperties():void {
     // do our code first
     if(_flag) {
          _stateIWant = "stateName";
          invalidateSkinState();
     }

// then call super
super.commitProperties();
}

This allows the invalidateSkinState() method to set the skinStateIsDirty flag to true before the super is called and will prevent the issue.

Finally, in 99% of the cases you won't need to call invalidateSkinState() within commitProperties(). You will more then likely want to call invalidateProperties() and invalidateSkinState() at the same time. But remember, you will still need to do all your skin state flag calculations BEFORE calling super so that commitProperties() and getCurrentSkinState() process the flags correctly.

Application Development on the BlackBerry Playbook via Adobe AIR (Free PlayBook)

Aaron Pedersen — Thu, 18 Nov 2010 21:07:22 +0000

At Max one of the most interesting announcements was around the BlackBerry PlayBook. The new device presents a slick 7'' screen and is packed with a 1GHz dual core processor and 1GB of RAM. The device will run BlackBerry's Tablet OS and come stocked with developer's favorite runtimes. Those include Open GL, WebKit, SMP, Adobe Flash, Java, and Adobe AIR.

For us Flash developers, the most important specs are that the device will ship with Flash 10.1 and with Adobe Air 2.5. This means all Flash content on the web will be viewable via the latest WebKit. And Flash developers can take advantage of the Blackberry Tablet OS SDK and a Flash Builder plugin to create ActionScript based projects. The SDK seems to be a custom version of the Flex 4 SDK, but from what I understand, they do not recommend you use the Flex 4 component set. BlackBerry has created their own core set of ActionScript components for general use and to assist with developing custom components that are performante on the device.

The SDK does support Flex's resource bundles, which means, your application can take advantage of internationalization. This is an important feature considering the PlayBook will be released in multiple countries in 2011.

Currently the PlayBook is to be shipped sometime early next year. But this has not stopped RIM from encouraging application development now. At Max RIM announce an offer for application developers. If you build an application and the application is submitted and approved into BlackBerry's AppWorld, you can be eligible for a free PlayBook. Look here for the announcement. http://devblog.blackberry.com/2010/10/blackberry-playbook-developer-prom....

Now you may be asking, "How do I develop an application without the hardware". Well, RIM has provided a Windows and Mac simulator to development environments. The simulator is an ISO file that will need to be run under a VMware Player on Windows or VMware Fusion on Mac. With the FlashBuilder plugin and the Simulator, you can developer, deploy, and debug your application.

For more information on developing for the PlayBook visit Adobe Labs.

http://labs.adobe.com/technologies/flash/blackberrytabos/

And for those of you already diving into the Max prerelease of FlashBuilder Burrito, Adobe has already posted an article to get you up and running for PlayBook development.

http://www.adobe.com/devnet/devices/articles/blackberry_tablet_os_sdk.html

RIM has also created a forum for questions and a blog where they have promised to post any new announcements about the hardware and software.

RIM has also announced a set of webcast series to help get developers up to speed on the development environment and the hardware.

http://us.blackberry.com/developers/tablet/devresources.jsp

RSL Calculations in the new Flex 4 Preloader

Tue, 28 Sep 2010 17:57:19 +0000

Flex 4 has introduced a new preloader and with it a series of new events that we can leverage. I am not going to take much time explaining how to build a preloader, there are some solid examples out there to cut your teeth on. The first example is Adobe's official documentation.

The issue with this documentation is that it ignores the Runtime Shared Library (RSL) progress events dispatched by the preloader instance. Its briefly mentioned in the Events list, but never used in the code. The challenge is that the basic progress events change drastically based on the current RSL being loaded.

By default, Flex 4 now breaks the SDK into multiple RSLs (SWF & SWZ), this means that we have to track n number of RSLs at load time and this cascades down into both the RSL progress and the init progress. The change in RSL requirements creates some interesting challenges in how we have to calculate the current progress and also causes some odd behavior with our loader. Let's take a look at the following diagram to see how the Flash player loads the content and what events are dispatched.

The goal of an RSL is to compartmentalize code in a downloadable file that can be cached and individually updated without requiring the entire project to be re-compliled (more or less). The new Flex 4 RSL structure for the framework is intended to break out different elements of the SDK into separate RSL files to allow developers to only require the RSLs they use in the project, and to allow the player to cache the files so the user only has to download them once.

If you are creating a Flex application using all the features of Flex 4, you will have seven files that are required to be downloaded and then loaded into the player. The main SWF (your application code) and the six Flex 4 RSLs: framework, osmf_flex, rpc, spark, sparkskins, and textLayout. All of these files must be loaded and initialized before you application is started and we can reflect this process in the custom preloader. If you add more RSLs, custom libraries, etc; then you will have to load even more files before the application can begin.

Preloader Events

There are few preloader events that we want to track during our load process: ProgressEvent.PROGRESS, RSLEvent.RSL_PROGRESS, RSLEvent.RSL_COMPLETE, FlexEvent.INIT_PROGRESS and FlexEvent.INIT_COMPLETE. All these events are dispatched during the loading process, and the order they get called in changes based on what action is being taken. This can create a really confusing order of operation.

The ProgressEvent.PROGRESS event is dispatched as the main application SWF is being loaded and as RSLs are being loaded. This means that the total bytes and the loaded bytes in the ProgressEvent.PROGRESS event changes depending on where we are in the load process. The problem is that most examples just use the ProgressEvent.PROGRESS event to calculate the percent based on the total and loaded values.

What we experienced in a current project I am working on is that the loader bar would jump around from complete to partially loaded back to complete as each of these progress values are updated. This lead me to start researching into the different events and found out about the RSLEvent.RSL_PROGRESS and RSLEvent.RSL_COMPLETE events.

Bernhard Hirschmann has an example (make sure to view the source) that taps into the RSL download events, but his solution only shows the basics for tracking and calculating a single RSL. Seth Duffy also has a good demo, but once again he is not handling multiple-RSL loads.

The RSLEvent.RSL_PROGRESS is dispatched as a specific RSL is being loaded into the player and gives us bytes loaded and total, so that we can calculate a percentage. When the RSL is done loading the RSLEvent.RSL_COMPLETE is dispatched. The problem is that ProgressEvent.PROGRESS events are randomly mixed into the RSLEvent.RSL_PROGRESS events and this creates a lot of confusion. Luckily, Bernhard's example (mentioned above) handles the mixing of RSLEvent.RSL_PROGRESS and ProgressEvent.PROGRESS for us.

Once I tied our project into the RSLEvents, we still were not getting a seamless load experience, because the progress would start back at zero once the next RSL started loading (not including the SWF load calculation that Bernhard shows). After a bit more digging, I found out that the RSLEvent has two properties, rslIndex and rslTotal. These properties tell us which RSL is being loaded and how many we have to load. Knowing this information we can calculate what percentage we are currently at using the bytesLoaded, totalBytes, rslIndex and rslTotal.

At this point I had to do a little (okay a lot) of hacking to get the right calculation, because I suck at math. BUT, I am persistent and I usually can figure it out. Here is the code (the event is the RSLEvent.RSL_PROGRESS):

Math.round(((event.bytesLoaded / event.bytesTotal) + event.rslIndex) / event.rslTotal * 100);

This allows us to calculate the current percentage of the RSL download based on both the current bytes and the position within the RSL index.

The result is the ability to create a smooth 0 - 100% progress bar for all our SWF and RSL files, no matter how many RSLs we have attached to our application.

One other thing to note, is that once the SWF and RSLs are loaded they need to be initialized. The final event we can track is the FlexEvent.INIT_PROGRESS event. This is not your typical progress event, because it does not provide bytesLoaded vs. bytesTotal. This is just dispatched as each part (SWF/RSL) is being initialized.

We can determine how many times FlexEvent.INIT_PROGRESS will be called by storing the total number of RSLs plus one (each RSL and the main SWF application). Using this value we can then increment the progress bar by a small amount as each FlexEvent.INIT_PROGRESS is dispatched and allow us just a bit more granularity into the preloader.

I hope this post helps some of you out there, I know that making a smooth loader was a bit of a challenge, but once you get all the parts its not too bad.

FITC San Francisco 2010 & Twitter #devarc

Mon, 16 Aug 2010 22:43:00 +0000

Flash in the Can (FITC) is almost upon us (or already happened depending when you read this) and we are really excited to be attending the San Francisco version of this internationally renowned conference. Aaron and I will speaking on the first day about the Flex 4 component lifecycle and if you are attending the conference we highly recommended swinging by and saying hi.

For attendees we will be handing out a conference code for a 20% discount off our training program, so keep an eye out for our flyers. There should also be a copy of the flyer in your goodie bag. If you are not attending FITC, we have a twitter contest going on. If you tweet about our training with the keyword #devarc you will have a chance to win a free session. So, get out there and tweet!

Introducing DevelopmentArc Online Seminar Training

Fri, 09 Jul 2010 18:06:09 +0000

We are proud to announce that DevelopmentArc is introducing a new training program focusing on Flex 4 development. Each training session will be a live seminar hosted online using Adobe Connect. We will offer our seminars multiple times each month, hopefully providing a good window for anyone who is interested. Our sessions also include unique training materials that are provided to you after each session. These materials include the source code we demonstrate with, a PDF copy of the slides and any custom training material we are creating for each series.

For our first series we are offering a four hour seminar focusing on developing custom Flex components and item renderers using the new Flex 4 Spark architecture. There has been a lot of minor and major changes to how Flex 4 content is created, which is going to change how you approach application development using Flex. Our goal with this series is to examine and explain these changes, look at new best practices to leverage these features and show you how to create content using the new principles that we are demonstrating.

This first seminar is based on our own development experiences while creating Adobe's WorkflowLab which uses Flex 4 and AIR 2. We have also been doing extensive research around the changes to the Flex 4 component lifecycle. Our initial research has been presented at multiple conferences such as 360|Flex (San Jose), Flash And the City (NYC), Designer Developer Workflow Conference (Kansas City) and will be featured at Flash in the Can (San Francisco) and Adobe MAX 2010 (Los Angeles). Our conference series are usually limited to only an hour and this seminar will be the first time that allows us to provide a truly in-depth look at the results from our research.

At the end of the session you will get access to a new 60 page mini-book that covers all the principles and examples that we discuss in the seminar. This mini-book includes a large section that is a Flex 4 update to our popular "Understanding the Adobe Flex® 3 Component and Framework Lifecycle" whitepaper. We have been getting a lot of requests for how Flex 4 has changed this process and by attending this session you will get a first hand look at this new information.

Each seminar has a limited number of spots, to enable everyone time for more questions and answers. So make sure to sign up as soon as possible to guarantee a spot in the session time that works best for you. If you have a larger team, are interested in onsite training or more focused training in a specific area, let us know because we are more then willing to work with you and your team. Hopefully, you will be able to join us and we look forward to this and multiple other series as time goes on!

Moving our site over to Drupal...

Thu, 03 Jun 2010 21:08:42 +0000

Over the last few weeks we have been rebuilding DevelopmentArc.com using Drupal as our new platform. Prior to the switch over, we having been running Wordpress and it has been pretty good for the last year or so. Unfortunately, we had purchased a template system that worked well for the launch yet to make it work we had to heavily modify the template and the CSS.

When Wordpress updated to 2.9, this broke all of the tempting systems and the developers had to roll out a new version. This new roll out drastically changed a lot of the files that we had modified, and this caused us a lot of heartache trying to re-build our modifications in the new template framework. We are currently planning a Drupal site for a client and we felt that rebuilding our site in Drupal was the perfect exercise. Small enough to do it between other work and would also free us up from the previous template fiasco since we would be building it from the ground up.

Now that we have ported over to Drupal, our goal is to keep the site in parity to the first one. Hopefully, you won't even tell a difference. But now that we control the entire stack, we hope to roll out new content and updates on a much shorter timeline. That, and we are finally wrapping up our book which has been our main focus for all our work and personal free time. So, enjoy the "new" site and let us know what issues you all have!

DevelopmentArc @ 360|Flex

Aaron Pedersen — Thu, 18 Feb 2010 07:19:43 +0000

With a little less than a month until 360|Flex I thought I would sit down and write a long over due post about the conference. 360|Flex is known in the community as one of those “hard core” conferences where the expectation is to leave sessions with your Flex and Flash IQ increased by a couple digits.

Unfortunately until now, James and I have had to experience the conference through other people’s stories. For some reason or another the last few years have been pretty hectic, but we made it a mission in 2010 to attend and speak at more events, with 360|Flex being the first on the list.

Session
In our session “Flex 4 Component LifeCycle Best Practices” our goal is to walk folks through the three stages of the Flex lifecycle (birth, mature, death) and discuss what methods can be used to help build efficient and high performance Flex applications following that Flex component design methodology. With the reengineering of the skinning architecture in Flex 4, a few methods have been introduced and others have been more or less deprecated in importance. We will discuss these changes in detail and how you will want to change your development practices. We are extremely excited to share our year long research that began with our widely popular white paper on the Flex 3 lifecycle. Soon after the conference and session, we plan on updating the paper to Flex 4 and will share it with the community.

Attending
As much of an honor it is to speak at 360|Flex what is really exciting us is attending some of the other session and diving deeper into topics we have not had the time to investigate. James and I have been debating our schedule for a few weeks now so far we have compiled a “must-see” list that we have listed below to share with everyone.

Aaron & James’ Must See!

Going deep w/OSMF - OMG!
Level 300
By David Hassoun

RobotLegs on Top of Gaia Flash Framework
Level 100
By Jesse Warden

Building Applications using Test Driven Development (TDD)
By Elad Elrom Dramatic

Effect of Flex Library Linkage
Level 300 By
Yakov Fain

Reflex: Rethinking Component Design
Level 300 By Jacob and Tyler Wright

Social Activity
We will be both tweeting as much as we can from the conference and sessions. Hit us up if you would like to discuss our session or any other session in more details. We love meeting new techies!

Aaron Pedersen - @aaronpedersen
James Polanco - @jamespolanco

Also don’t forget to follow 360|Flex for news and updates as we approach the and throughout the conference.

360|Flex - @360flex

Wrap Up
If you are thinking about attending 360|Flex you should book your tickets soon. Last time the conference was held in San Jose it was sold out. This year the conference has parties every night giving you a chance to mingle with the community at large. There are over 40 sessions, 2 panels, and your ticket includes hands on training sessions for all levels on the Sunday before the conference begins. Also, if you are new to Flex, you can take an all day Flex 101 course (one of the hands on training sessions) and be ready for regular sessions on Monday. Speakers include a wide assortment of Adobe engineers and communities leaders. For a full list check out the following site http://www.360flex.com/blog/category/the-speakers.

Merging Fonts When Embedding

Tue, 24 Nov 2009 17:27:13 +0000

I found an interesting trick with embedding fonts today while working with the Text Flow engine in Flex 4. What I found out is that you can embed multiple fonts under the same font family name, but set the properties such as font weight or font style to different settings based on the font source you are using. This may be an obvious thing to a lot of people, and the property name 'font-family' makes a lot more sense now, but for me it was a real 'ah-ha' moment. By the way, this isn't just a Flex 4 thing, you can do this with Flex 3 and probably AS3 only projects (haven't tried that yet) but the issue became more apparent in Flex 4's new TLF enabled components.

The problem came about because we have a set of fonts that provide each style type in a unique OTF file, i.e. Font-Regular.otf, Font-Bold.otf, Font-Italic.otf, and Font-BoldItalic.otf. In the past, we just embedded this with unique font-family ids (font-family: "Font-Regular") and then just bound them via CSS. This approach becomes a significant problem when starting to work with TLF's selection management and Text Format. We are building a simple Rich Text Editor in Flex 4 (since its not available yet in Beta 2) to allow a user to set their text to bold, italic or underline. Simple enough, right?

Well, its not so simple when you have your font styles spread across font identifiers. The way we started to handle this is that when the user selected some text and applied Bold, we would set the text format's font family for the selection to "Font-Bold". To enable the ability to toggle the style, we would ask for the selection ranges format, look to see what the font family is and then toggle it to either bold or normal. Now, let's say that the user selects a section of text that mixes bold and normal text. When you get the text format back, the font family property is set to undefined, letting you know that you have a mixed set.

In the bold/normal case this is easy to solve, but let's say that you have bold, normal and italic text in the selection. Because the property is undefined we can't determine this nor can we just apply the new style across the entire selection because you would remove the italic (in the case of applying bold). At this point I was getting kind of upset because the solution wasn't sounding pretty. We were looking at having to loop through the selection, grabbing the leafs and then looking at the format to determine the correct selection. I was going to punt on it as a bug for now and move on.

This morning, while making coffee I thought about the fact that the key for the CSS font embed is font-family, and that when using @font-face that you can actually set things such as font-weight. What I found out is that you can embed different sources under the same name as long as they have different style properties:

@font-face {

src: url("./assets/fonts/Font-Regular.otf");

font-family: MyFont;

}

@font-face {

src: url("./assets/fonts/Font-Bold.otf");

font-family: MyFont;

font-weight: bold;

}

@font-face {

src: url("./assets/fonts/Clean UI/Font-Italic.otf");

font-family: MyFont;

font-style: italic;

}

@font-face {

src: url("./assets/fonts/Font-BoldItalic.otf");

font-family: MyFont;

font-weight: bold;

font-style: italic;

}

Now I can treat the font as the same family and then toggle the style properties, such as font-weight or font-style without having any font conflict. This fixes the Text Format issue and also allows for a much cleaner/consistent CSS file. I am sure this is explained somewhere (probably in the documents, clear as day), but I never knew that you could do this... hope it helps!

Flash Player Internals 10.1 Recap (part four)

Fri, 23 Oct 2009 17:26:28 +0000

In part one of the Flash Player Internals recap we covered how the player is built, in part two we talked about how the player infrastructure works, in part three we examined how ActionScript and the Virtual Machine (VM) are improvin g in Flash Player 10.1. Now, in the final segment (looking at my notes this will be the longest segment) we will look at how the Flash Player rendering system is being improved and how you can leverage it for multiple devices.

Shake Your Movie-maker

One of the biggest changes in player 10.1 is that all video will now be GPU decoded. This is huge for you video buffs out there because GPU decoding is sick fast and allows lower power devices, like netbooks, to play 1080p video smoothly and efficiently. In the current player, video is decoded using a software based decoder (except in fullscreen, when GPU may be used, but not guaranteed) which is fine when you are on a big 8 core beast, but little machines just can't handle the data.

Now, with a change this big there has to be a few caveats. Well, there is. First, your GPU has to support H.264 decoding in the chipset. If your GPU (ex: video card) doesn't support that, then you are out of luck and the Player will fall back to software decoding. Next, your GPU and GPU drivers have to be certified for the Player to use it. If you have an older driver that is not certified it won't matter if your chipset supports H.264 or not, the Player won't leverage it.

Having the chipset/driver pair white-listed for the Player means that Adobe has to work closely with the manufactures to verify the certification process. Adobe has partnered with all the major manufactures for this process, but this means that we still have a few years before everyone can leverage GPU acceleration. The good news is that mobile devices turn over faster, and pretty much all of the newest devices meet the Player's requirements today.

Another issue is that existing video may need to be re-encoded to allow for GPU acceleration. This issue is created because the H.264 codec version that is used to encode the video must be supported by the GPU/driver combination. Lee recommends that you use H.264 main or baseline codecs because this will guarantee that all GPUs that meet the certification process will be able to render your video. If your videos were not encoded with main or baseline, then you may have to re-encode the video for GPU support.

So, how can you tell if the user can support GPU rendering or not? At the moment, you can't. The Player team is looking at this and they want it for 10.1 but there is a chance that this will not be exposed for the 10.1 release. GPU detection is coming, they will support it, but its up in the air for when the Player will enable this.

Finally, GPU support will be enabled for all wmodes. For those of you that where in attendance for the 2008 Flash Player Internals session, Jim and Lee discussed that only one wmode may be supported in the future. Well, Lee lost the argument and all browser wmodes will support GPU rendering (as long as you meet the previously discussed requirements).

Picture This

There has been a lot of work done in 10.1 for how the player handles images. Images take up a LOT of memory, and updating how images are managed was one of the keys to getting the memory footprint of applications down, without having the developer change code. For example, the player now handles image instances much better, and allows image reuse without having to copy them. This is an issue, because if you are trying to show the same image multiple times (skins, etc.) the current player would copy the instance for each one on screen. Now, Player 10.1 can leverage the same instance in memory for rendering. Hot!

The Player now allows you, the developer, to determine when an image is decompressed. Currently, when the Player loads a JPEG, it is decompressed right there and then. This becomes an issue because the decompressed image takes up significantly more memory, even if you are not using it yet. This becomes a serious challenge when you are trying to pre-load/cache images but aren't ready to show them yet. In Player 10.1 you will have the ability to tell the Player to load the JPEG, but not to decompress it. This allows for a much better memory management experience within your applications. Lee also mentioned that images that are not being used will now be thrown away. It sounds like the Player would hold on to unused images longer then needed and this is probably one of the many GC tuning issues that we talked about in part three.

For you 3D junkies out there, Player 10.1 supports direct mip-mapping. I am not a 3D guru by any stretch of the imagination, most of my 3D experience was back with Director 8 and 3D Studio Max. So, here are my notes from what Lee said, and if you have a better understanding of mip-mapping feel free to chime in. Lee stated that unused memory is now managed when using mip-mapping, it is extremely efficient with 16-bit images and now it only decodes/renders what is seen, which makes a lot of sense when your read the Wikipedia article on mip-mapping.

Vectorize Me!

Player 10.1 will support GPU vector rendering on mobile platforms. This new engine fully replaces the software rendering of vector graphics and moves the process over the GPU. The issue is that this only works well when the GPU is faster then the CPU. In most desktop environments, this is never the case so this feature is really a mobile only solution. The reason this is great for mobile is that in today's devices the GPU is significantly faster then the CPU for rendering out Vector graphics.

Why So Slow?

Lee had a few recommendations about improving general performance in Flash Player based applications. First, use ActionScript 3 and strong type everything. Using AS2, Generic objects, marking everything * and/or Dynamic based Classes do not perform nearly as well as strong typing and sealed Classes. Use the AVM2 to your advantage and take the time to type. Another tip is to avoid using intervals (timers) when ever possible and don't rush to setting high frame rates. One of the oldest tricks in the Flash book is to crank up your frame rate to "11" (i.e. 100+ frames per second). This strong arming technique used to work but now the AVM and the way it processes frame intervals won't gain you the same benefits as before, in fact in may actually hurt performance. Really take the time to understand the elastic racetrack concept and build your application with this in mind.

You Want Me To Display What?!

When building mobile/handheld based applications, understanding the display list is critical. As developers, especially Flex developers, we get a little nest happy. HBoxes, within VBoxes, within Canvases, etc. This becomes a HUGE problem with mobile devices. Everytime the user interacts with the app the display list has to be traversed and this just kills the CPU. To prevent this, try to keep the display list as flat and as small as possible. If you don't have to nest it, don't, if you can render it as one Sprite, do! Keep your numbers down and this will make your app perform much better.

What this all boils down to is that the utopia of one application on multiple devices is really not tangible. When building an app, you have to understand the target platform/device you are building to. What is the target devices resolution, pixel depth, GPU speed, CPU speed, memory limitations and capabilities. When building mobile applications, what is the cause of any performance issues? Is your display list too deep, are you rendering video correctly or vectors? Is your content truly optimized for your device?

Flash Player 10.1 is giving us a lot of great tools and features to allow us to apply our skills to new and uncharted realms, but with any tool we have to understand what it is good for and how we should use it. I am really excited to see what doors 10.1 opens for developers but I can already foresee some of the challenges we will face. I think that is why I really enjoy Lee's sessions because he helps layout a lot of the new features of the player but he also points out trouble spots that these new abilities can create, before you may stumble upon them yourself.