flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Scout - What does this mean?
Date Fri, 18 Nov 2016 20:30:13 GMT
Hi,

A better way to go about this would be to create variables for each
relevant width, height, offset variable that would be required in the
layout.

Then, you could simply set different values for each DPI value.  You get
your layout manually perfect for one DPI.  Then all you have to do is
multiply each value by the corresponding scale factor of the DPI.  As an
example, if you figure out all the variables for 160 DPI, the values for
240 DPI would be 1.5 x the value in 160 DPI, the values for 320 DPI would
be 2x and so on...

We do something like this for all our ios and Android skins.  As a sample,
take a look at the RadioButtonSkin class for iOS7:

First, we define variables like offsetX, offsetY, width, height etc.
https://github.com/apache/flex-sdk/blob/develop/frameworks/projects/mobiletheme/src/spark/skins/ios7/RadioButtonSkin.as#L59

Then, we set these values for each DPI value:
https://github.com/apache/flex-sdk/blob/develop/frameworks/projects/mobiletheme/src/spark/skins/ios7/RadioButtonSkin.as#L99

Then, we have only one draw routine that simply uses these variables to
draw the objects on the screen:
https://github.com/apache/flex-sdk/blob/develop/frameworks/projects/mobiletheme/src/spark/skins/ios7/RadioButtonSkin.as#L205

This way your layout will look perfect in all supported DPIs.  Hope you can
do something similar to this in your code.

Thanks,
Om



On Fri, Nov 18, 2016 at 11:59 AM, bilbosax <waspence41@comcast.net> wrote:

> I believe that everything was off by a factor of 2. What would be awesome
> is
> if regardless of screen resolution or DPI, I could always assume that the
> scaling magic was related to a width of 768, which I could create as a
> constant and problem solved. That is what I did for the renderer and it
> worked like a charm, but I don't know if that will work for android or all
> iPads??
>
> I have a bigger issue now. The TypeErrors are gone, and all of the
> measuring
> seems to have been massively reduced, but the performance is not much
> better, only slightly. When tethered to Scout, the iPad button click still
> takes about 5000ms to slide the list onto the screen. Untethered, I would
> estimate it to be about 3000ms. So now the question comes down to two
> parts:
>
> 1) Would an actionscript itemrenderer make a noticeable difference? I am a
> little daunted to try it because I never have, and you already know that I
> have 30 labels and radiobutton and I know there will be a lot of overrides.
> But if you believe it will make a significant improvement, I could give it
> a
> try.
>
> 2) When the list moves up and completely covers the content behind it, how
> much does the content that it covers affect performance? I always assumed
> that it all stayed in the display list and was simply covered up
> temporarily. But on the main screen, I have 20 dropdownbuttons, buttons,
> and
> textinputs in heavily nested groups as well as 3 lists with itemrenderers,
> only one of which is visible at a time. If that all has to be removed and
> redrawn when the list transitions in and out, then maybe I need to trim the
> fat out of that code as well???
>
> Any thoughts are appreciated. The desktop version works great, but right
> now, the mobile version just does not feel like a professional app :(
>
>
>
> --
> View this message in context: http://apache-flex-users.
> 2333346.n4.nabble.com/Scout-What-does-this-mean-tp14126p14156.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message