You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2013/05/05 13:07:04 UTC
Re: 480 DPI density mobile support
Hi,
>> Does anyone know how these .fxg were generated (not by hand right?) and can we
>> get hold of the original assets?
> Even in the Adobe SVN they are checked in as FXG and I don't see any history
> of how they were created.
Anyone with some design skills on the list willing to help out with this?
Thank,
Justin
Re: 480 DPI density mobile support
Posted by Alex Harui <ah...@adobe.com>.
On 5/9/13 2:55 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
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?
>
I don't think so. The files donated came from [1]. The history there shows
FXG files being checked in and no .fla or .ai or anything like that. But we
might have missed something so feel free to snoop around there and see if
you can find the "originals".
[1] http://opensource.adobe.com/svn/opensource/flex/sdk/branches/4.y/
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: 480 DPI density mobile support
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, May 9, 2013 at 2:02 PM, Alex Harui <ah...@adobe.com> wrote:
>
> On 5/9/13 12:38 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> > On Wed, May 8, 2013 at 12:49 AM, Justin Mclean
> > <ju...@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
>
>
Re: 480 DPI density mobile support
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> I wrote a small tool to upconvert the 320dpi to 420dpi.
Nice.
> Can I check it into the 480dpi branch for others to test as well?
Sure. Always good if code is in the open.
Thanks,
Justin
Re: 480 DPI density mobile support
Posted by Alex Harui <ah...@adobe.com>.
On 5/9/13 12:38 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
> On Wed, May 8, 2013 at 12:49 AM, Justin Mclean
> <ju...@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.
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.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: 480 DPI density mobile support
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, May 8, 2013 at 12:49 AM, Justin Mclean <ju...@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?
I did some random testing and the new skins look okay to my naked eye. But
I want to do more thorough testing.
What would be the best way to test these new skins? Can I check it into
the 480dpi branch for others to test as well?
Thanks,
Om
Re: 480 DPI density mobile support
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Re: 480 DPI density mobile support
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Any luck with this?
If you let me know the related files, I can take a stab at it.
Thanks,
Om
On Sun, May 5, 2013 at 11:24 PM, OmPrakash Muppirala
<bi...@gmail.com>wrote:
> I did a quick test and scaleX="2" scaleY="2" works fine with the examples
> you provided. I think a scale transform on all the fxg elements (or even
> on just the parent element) would make it work. If a top level element
> already has a scale value, multiply it by 2.
>
> Let me know if that does not work, I will look into it when I get a
> chance.
>
> Thanks,
> Om
>
>
> On Sun, May 5, 2013 at 10:54 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>>
>> On 5/5/13 10:14 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>>
>> > Hi,
>> >
>> >> I was able to import the FXG files into Flash Pro CS5. But I am not
>> >> artistic enough to muck with them after that.
>> >
>> > Is it easy enough to resample/export at double the size?
>> >
>> Don't know. That's designer stuff. :-)
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
Re: 480 DPI density mobile support
Posted by OmPrakash Muppirala <bi...@gmail.com>.
I did a quick test and scaleX="2" scaleY="2" works fine with the examples
you provided. I think a scale transform on all the fxg elements (or even
on just the parent element) would make it work. If a top level element
already has a scale value, multiply it by 2.
Let me know if that does not work, I will look into it when I get a chance.
Thanks,
Om
On Sun, May 5, 2013 at 10:54 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 5/5/13 10:14 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> > Hi,
> >
> >> I was able to import the FXG files into Flash Pro CS5. But I am not
> >> artistic enough to muck with them after that.
> >
> > Is it easy enough to resample/export at double the size?
> >
> Don't know. That's designer stuff. :-)
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: 480 DPI density mobile support
Posted by Alex Harui <ah...@adobe.com>.
On 5/5/13 10:14 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I was able to import the FXG files into Flash Pro CS5. But I am not
>> artistic enough to muck with them after that.
>
> Is it easy enough to resample/export at double the size?
>
Don't know. That's designer stuff. :-)
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: 480 DPI density mobile support
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I was able to import the FXG files into Flash Pro CS5. But I am not
> artistic enough to muck with them after that.
Is it easy enough to resample/export at double the size?
Justin
Re: 480 DPI density mobile support
Posted by Alex Harui <ah...@adobe.com>.
Yup, I guess the paths would be hard to figure out.
I was able to import the FXG files into Flash Pro CS5. But I am not
artistic enough to muck with them after that.
On 5/5/13 9:15 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> Just wondering. Are there any bitmaps involved?
> Not 100% sure not many if there is any.
>
>> Otherwise, how ugly does it get if you simply double all of the values in the
>> 240 dpi assets?
> May be difficult.
>
> Probable easy enough (but tedious) to double values like x, y, height, width,
> scaleGrid etc etc but there's a lot of them.
>
> But then you run into paths like this:
> <Path winding="nonZero" data="M56 48C56 52.418 52.418 56 48 56L8
> 56C3.58203 56 0 52.418 0 48L0 7.93848C0 3.521 3.58203 0 8 0L48 0C52.418 0 56
> 3.521 56 7.93848L56 48ZM54.667 8C54.667 4.31836 51.6821 1.3335 48 1.3335L8
> 1.3335C4.31836 1.3335 1.3335 4.31836 1.3335 8L1.3335 48 C1.3335 51.6826
> 4.31836 54.667 8 54.667L48 54.667C51.6821 54.667 54.667 51.6826 54.667
> 48L54.667 8Z">
>
> The files had to be generated in some way going on the values inside them. eg
> <Rect x="1.3335" y="1.3335" width="53.3335" height="53.3335"
> radiusX="6.66885" radiusY="6.66885">
> <fill>
> <LinearGradient x="26.667" y="0" scaleX="30.1528" rotation="90">
> <GradientEntry ratio="0" alpha="0.25"/>
> <GradientEntry ratio="1" alpha="0"/>
> </LinearGradient>
> </fill>
> </Rect>
>
> Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: 480 DPI density mobile support
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Just wondering. Are there any bitmaps involved?
Not 100% sure not many if there is any.
> Otherwise, how ugly does it get if you simply double all of the values in the 240 dpi assets?
May be difficult.
Probable easy enough (but tedious) to double values like x, y, height, width, scaleGrid etc etc but there's a lot of them.
But then you run into paths like this:
<Path winding="nonZero" data="M56 48C56 52.418 52.418 56 48 56L8 56C3.58203 56 0 52.418 0 48L0 7.93848C0 3.521 3.58203 0 8 0L48 0C52.418 0 56 3.521 56 7.93848L56 48ZM54.667 8C54.667 4.31836 51.6821 1.3335 48 1.3335L8 1.3335C4.31836 1.3335 1.3335 4.31836 1.3335 8L1.3335 48 C1.3335 51.6826 4.31836 54.667 8 54.667L48 54.667C51.6821 54.667 54.667 51.6826 54.667 48L54.667 8Z">
The files had to be generated in some way going on the values inside them. eg
<Rect x="1.3335" y="1.3335" width="53.3335" height="53.3335" radiusX="6.66885" radiusY="6.66885">
<fill>
<LinearGradient x="26.667" y="0" scaleX="30.1528" rotation="90">
<GradientEntry ratio="0" alpha="0.25"/>
<GradientEntry ratio="1" alpha="0"/>
</LinearGradient>
</fill>
</Rect>
Justin
Re: 480 DPI density mobile support
Posted by Alex Harui <ah...@adobe.com>.
On 5/5/13 4:07 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>>> Does anyone know how these .fxg were generated (not by hand right?) and can
>>> we
>>> get hold of the original assets?
>> Even in the Adobe SVN they are checked in as FXG and I don't see any history
>> of how they were created.
>
> Anyone with some design skills on the list willing to help out with this?
>
Just wondering. Are there any bitmaps involved? Otherwise, how ugly does
it get if you simply double all of the values in the 240 dpi assets?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui