On Thu, May 9, 2013 at 2:02 PM, Alex Harui <aha...@adobe.com> wrote: > > On 5/9/13 12:38 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > > On Wed, May 8, 2013 at 12:49 AM, Justin Mclean > > <jus...@classsoftware.com>wrote: > > > >> HI, > >> > >>> If you let me know the related files, I can take a stab at it. > >> > >> It's everything under > >> frameworks/projects/mobiletheme/src/spark/skins/mobile/mobile480 in the > >> 480dpi branch, files there are just a copy of the the 320 dpi files. > Free > >> free to delete everything in that directory and start from scratch if > you > >> want. > >> > >> Thanks, > >> Justin > > > > > > I wrote a small tool to upconvert the 320dpi to 420dpi. Essentially I > > scaled up each first level child element in every skin by a factor of > 1.5. > > Anyone see any problems with this logic? > Seems like a reasonable first start. > > In theory, making a single pixel line that was on a pixel boundary become > 1.5 pixels wide should cause the colors in the pixels that are now half > covered to be less intense than the full covered pixels. My eyes have > never > been good enough to see it even on a desktop monitor, but we have had bugs > filed about that sort of thing in the past. However, at 480dpi, I'm not > sure anyone can see it. > > It might have been better to convert 240 dpi assets by a factor of 2. But > again, it may not really matter. >
I inspected the differences between the 160, 240 and 320 dpi assets. It seems like 160 and 240 have the same elements but only the width/height, etc. changes. Whereas, the 320 dpi assets, more number of elements per graphic layer have been introduced. I think the same logic was applied when the 320dpi assets were created. They could have taken the 160dpi assets and doubled them, but they went ahead and made more complex changes so that they are more accurate. For example, you can look at the ActionBarBackground.fxg file in the three current dpis to see the difference. Because of this, I think using the 320 dpi assets as a base and scaling them by 1.5 makes more sense. > > The other theoretical "flaw" is in the line-thickness and font area in > general. A 24px "T" is not guaranteed to cover the same pixels as a 12px > or > 18px "T" scaled up. Again, not clear humans can see that at this density, > but some folks seem to have much more sensitivity to these things than me. > > Good point, but I have not seen an instance of RichText (or TextGraphic) in these fxg files. Any other text nodes I should be looking for? All that said, I would love to see the original files (.fla or .ai) for these graphics. Are you sure you dint skip those binaries when processing the original code donation? Thanks, Om > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
