Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)

["Christian M. Cepel" <pu...@marshwiggle.org>]

Thanks to a brief, though, informative response to this question on the
Adobe AIR forums, I've been told that when I instantiate a Spark List and
assign it a custom item renderer and a data provider, that the reason
it instantiates four item renderers (one for each item in my DataProvider),
that properly are contextual children of the List control, and then
instantiates a fifth orphaned instance of the renderer is 'for measurement'.

I assume the answer I was given is correct, but the reality (not the
answer) is distinctly distasteful and unsatisfying.

In a day and age when we are trying to optimize programs to run on what
are, frankly, the technological equivalent of 15-20 year old computers
(1ghz processors and limited RAM) with end users expecting them to behave
in a snappy non-latent manner as they would on a desktop machine with
multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of
the load (as unrealistic as that may be... ...one of the major reasons I
believe Adobe gave up on a mobile browser flash player), I cannot
understand why something that seems so very wasteful is necessary.

I don't pretend to understand the nuts and bolts of how the SDK
accomplishes what it does...  that's why it's an Abstract.  I usually don't
need to know...

But I'm faced with a situation where I'm trying to understand why when I
instantiate a view it basically halts an iPad2 for 11-13 seconds before
displaying the new view... and when I investigate, I find that the
processor intensive task I'm trying to complete is made that much more
intensive by a factor of 20%.

If I'm to believe my trace statements, the creationComplete event is being
called on legitimate items 1, 2, 3, and 4, which, I would believe would
make them available to be measured and do layout, starting with the first,
and made all the more simple because my List has been told to use uniform
row height... (which I assume means, 'figure out the first and go with it').

Very grateful for any insight... Especially if it would mean also having a
way to help my extreme latency problem.  I cannot even get a BusyIndicator
to display and rotate before loading the view w/o using a timer to load the
view after a brief time... and then it freezes the BusyIndicator.

Frustrating... very frustrating.

-- 
// Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri


*And the wrens have returned, and are nesting;*

*In the hollow of that oak, where his heart once had been.*

*And he lifts up his arms in a blessing, for being born again.*

Rich Mullins, The Color Green, A Liturgy, a Legacy, & a Ragamuffin Band

Re: Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)

["Christian M. Cepel" <pu...@marshwiggle.org>]

I'll take a look at that and the feedback from Alex.   Thank you gentlemen.
 With all the other things I'm juggling, I thought I was lucky just to
discover the extra instantiation.  Hopefully some other things will fall
into line and I'll get a chance to go a little deeper using these
suggestions.


On Fri, Mar 1, 2013 at 12:35 PM, João Fernandes <
joaopedromartinsfernandes@gmail.com> wrote:

> Christian, have you tried to define a typicalItem in the list? Does it
> behave the same?
>
> If you want a better way to track those performance issues, try to create a
> release version of your app and enable advanced telemetry on it. Then use
> scout to track what's really messing up between view changes.
>
>
> On 1 March 2013 18:06, Christian M. Cepel <puddleglum@marshwiggle.org
> >wrote:
>
> > Thanks to a brief, though, informative response to this question on the
> > Adobe AIR forums, I've been told that when I instantiate a Spark List and
> > assign it a custom item renderer and a data provider, that the reason
> > it instantiates four item renderers (one for each item in my
> DataProvider),
> > that properly are contextual children of the List control, and then
> > instantiates a fifth orphaned instance of the renderer is 'for
> > measurement'.
> >
> > I assume the answer I was given is correct, but the reality (not the
> > answer) is distinctly distasteful and unsatisfying.
> >
> > In a day and age when we are trying to optimize programs to run on what
> > are, frankly, the technological equivalent of 15-20 year old computers
> > (1ghz processors and limited RAM) with end users expecting them to behave
> > in a snappy non-latent manner as they would on a desktop machine with
> > multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of
> > the load (as unrealistic as that may be... ...one of the major reasons I
> > believe Adobe gave up on a mobile browser flash player), I cannot
> > understand why something that seems so very wasteful is necessary.
> >
> > I don't pretend to understand the nuts and bolts of how the SDK
> > accomplishes what it does...  that's why it's an Abstract.  I usually
> don't
> > need to know...
> >
> > But I'm faced with a situation where I'm trying to understand why when I
> > instantiate a view it basically halts an iPad2 for 11-13 seconds before
> > displaying the new view... and when I investigate, I find that the
> > processor intensive task I'm trying to complete is made that much more
> > intensive by a factor of 20%.
> >
> > If I'm to believe my trace statements, the creationComplete event is
> being
> > called on legitimate items 1, 2, 3, and 4, which, I would believe would
> > make them available to be measured and do layout, starting with the
> first,
> > and made all the more simple because my List has been told to use uniform
> > row height... (which I assume means, 'figure out the first and go with
> > it').
> >
> > Very grateful for any insight... Especially if it would mean also having
> a
> > way to help my extreme latency problem.  I cannot even get a
> BusyIndicator
> > to display and rotate before loading the view w/o using a timer to load
> the
> > view after a brief time... and then it freezes the BusyIndicator.
> >
> > Frustrating... very frustrating.
> >
> > --
> > // Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri
> >
> >
> > *And the wrens have returned, and are nesting;*
> >
> > *In the hollow of that oak, where his heart once had been.*
> >
> > *And he lifts up his arms in a blessing, for being born again.*
> >
> > Rich Mullins, The Color Green, A Liturgy, a Legacy, & a Ragamuffin Band
> >
>
>
>
> --
>
> João Fernandes
>



-- 
// Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri


*And the wrens have returned, and are nesting;*

*In the hollow of that oak, where his heart once had been.*

*And he lifts up his arms in a blessing, for being born again.*

Rich Mullins, The Color Green, A Liturgy, a Legacy, & a Ragamuffin Band

Re: Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)

[João Fernandes <jo...@gmail.com>]

Christian, have you tried to define a typicalItem in the list? Does it
behave the same?

If you want a better way to track those performance issues, try to create a
release version of your app and enable advanced telemetry on it. Then use
scout to track what's really messing up between view changes.


On 1 March 2013 18:06, Christian M. Cepel <pu...@marshwiggle.org>wrote:

> Thanks to a brief, though, informative response to this question on the
> Adobe AIR forums, I've been told that when I instantiate a Spark List and
> assign it a custom item renderer and a data provider, that the reason
> it instantiates four item renderers (one for each item in my DataProvider),
> that properly are contextual children of the List control, and then
> instantiates a fifth orphaned instance of the renderer is 'for
> measurement'.
>
> I assume the answer I was given is correct, but the reality (not the
> answer) is distinctly distasteful and unsatisfying.
>
> In a day and age when we are trying to optimize programs to run on what
> are, frankly, the technological equivalent of 15-20 year old computers
> (1ghz processors and limited RAM) with end users expecting them to behave
> in a snappy non-latent manner as they would on a desktop machine with
> multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of
> the load (as unrealistic as that may be... ...one of the major reasons I
> believe Adobe gave up on a mobile browser flash player), I cannot
> understand why something that seems so very wasteful is necessary.
>
> I don't pretend to understand the nuts and bolts of how the SDK
> accomplishes what it does...  that's why it's an Abstract.  I usually don't
> need to know...
>
> But I'm faced with a situation where I'm trying to understand why when I
> instantiate a view it basically halts an iPad2 for 11-13 seconds before
> displaying the new view... and when I investigate, I find that the
> processor intensive task I'm trying to complete is made that much more
> intensive by a factor of 20%.
>
> If I'm to believe my trace statements, the creationComplete event is being
> called on legitimate items 1, 2, 3, and 4, which, I would believe would
> make them available to be measured and do layout, starting with the first,
> and made all the more simple because my List has been told to use uniform
> row height... (which I assume means, 'figure out the first and go with
> it').
>
> Very grateful for any insight... Especially if it would mean also having a
> way to help my extreme latency problem.  I cannot even get a BusyIndicator
> to display and rotate before loading the view w/o using a timer to load the
> view after a brief time... and then it freezes the BusyIndicator.
>
> Frustrating... very frustrating.
>
> --
> // Christian M. Cepel - Programmer/Analyst, Sr., University of Missouri
>
>
> *And the wrens have returned, and are nesting;*
>
> *In the hollow of that oak, where his heart once had been.*
>
> *And he lifts up his arms in a blessing, for being born again.*
>
> Rich Mullins, The Color Green, A Liturgy, a Legacy, & a Ragamuffin Band
>



-- 

João Fernandes

Re: Spark List instantiates an extra orphaned ItemRenderer (ostensibly for measuring)

[Alex Harui <ah...@adobe.com>]

If you can get the profiler performance sample, it should show you where the
time is being spent.  I would hope one extra renderer isn't the culprit, but
you never know.  But yes, in many cases it isn't necessary so we shouldn't
always create it.

If you have further questions about profiling, please use the
users@flex.apache.org mailing list.  I'm sure others will be interested.
You can even post links to screenshots of the profiler screens and we'll try
to help you interpret it.  One tip:  turn off all the default filters on the
profiler snapshots (there's a button/icon the right hand side).


On 3/1/13 10:06 AM, "Christian M. Cepel" <pu...@marshwiggle.org> wrote:

> Thanks to a brief, though, informative response to this question on the
> Adobe AIR forums, I've been told that when I instantiate a Spark List and
> assign it a custom item renderer and a data provider, that the reason
> it instantiates four item renderers (one for each item in my DataProvider),
> that properly are contextual children of the List control, and then
> instantiates a fifth orphaned instance of the renderer is 'for measurement'.
> 
> I assume the answer I was given is correct, but the reality (not the
> answer) is distinctly distasteful and unsatisfying.
> 
> In a day and age when we are trying to optimize programs to run on what
> are, frankly, the technological equivalent of 15-20 year old computers
> (1ghz processors and limited RAM) with end users expecting them to behave
> in a snappy non-latent manner as they would on a desktop machine with
> multi-multi-gHz cores, several GB of memory, and a GPU handling a lot of
> the load (as unrealistic as that may be... ...one of the major reasons I
> believe Adobe gave up on a mobile browser flash player), I cannot
> understand why something that seems so very wasteful is necessary.
> 
> I don't pretend to understand the nuts and bolts of how the SDK
> accomplishes what it does...  that's why it's an Abstract.  I usually don't
> need to know...
> 
> But I'm faced with a situation where I'm trying to understand why when I
> instantiate a view it basically halts an iPad2 for 11-13 seconds before
> displaying the new view... and when I investigate, I find that the
> processor intensive task I'm trying to complete is made that much more
> intensive by a factor of 20%.
> 
> If I'm to believe my trace statements, the creationComplete event is being
> called on legitimate items 1, 2, 3, and 4, which, I would believe would
> make them available to be measured and do layout, starting with the first,
> and made all the more simple because my List has been told to use uniform
> row height... (which I assume means, 'figure out the first and go with it').
> 
> Very grateful for any insight... Especially if it would mean also having a
> way to help my extreme latency problem.  I cannot even get a BusyIndicator
> to display and rotate before loading the view w/o using a timer to load the
> view after a brief time... and then it freezes the BusyIndicator.
> 
> Frustrating... very frustrating.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui