[flexcoders] Re: ItemRenderer gets invalidated when List is scrolled

[Florian]

Hi Alex, yes that WAS my observation. But the cause were side effects triggered 
by calling contentWidth of the item renderer.

Everything is fine now and works like a charm.

--- In flexcoders@yahoogroups.com, Alex Harui  wrote:
>
> Are you saying you are seeing extra invalidation calls when scrolling?  If 
> the renderer is using autosizing text controls there can be extra 
> invalidation calls.  We are looking at issues related to that right now.  Not 
> sure we can always optimize them away.
> 
> 
> On 8/9/10 1:05 PM, "Florian"  wrote:
> 
> 
> 
> 
> 
> 
> No, i'm aware of the component live cycle. What i was not aware of: creating 
> a loop when accessing contentWidth in updateDisplayList... it just hit me 
> right into my face.
> 
> Just for the record: my observation of the additional invalidation cycles was 
> when the renderer was moved in the viewport AFTER new data has been 
> referenced. So scrolling the list was causing the trouble. But neither the 
> owner nor the layout was responsible for this behavior, it was the component 
> itself.
> 
> Thanx for taking the time though :)
> 
> --- In flexcoders@yahoogroups.com  , 
> dorkie dork from dorktown  wrote:
> >
> > With useVirtualLayout set to true the list will create a set number of
> > renderers. As you scroll the list will recycle these item renderers. In this
> > scenario you are never guaranteed that the renderer associated with your
> > data will remain with that data.
> >
> > If you want to guarantee that the renderer always remains connected with the
> > data item then set useVirtualLayout to false.
> >
> > Alex can correct me, but you may also be able to check if the data is the
> > same data in the set data override and if so prevent setting the super.data
> > property. Although, I think once it is decided a renderer will be recycled
> > the data property is set to null before hand.
> >
> > On Mon, Aug 9, 2010 at 4:26 AM, Florian  wrote:
> >
> > >
> > >
> > > My thoughts more specifically:
> > > - the data property is set -> an invalidation should occur.
> > > - a renderer is reused -> an invalidation should occur.
> > > - a renderer is scrolled within the view port -> no invalidation should
> > > occur, after its size is determined.
> > >
> > > Or am i wrong?
> > >
> > >
> > > --- In flexcoders@yahoogroups.com   
> > > ,
> > > "Florian"  wrote:
> > > >
> > > > Yes, i understand this aspect of the component model. But since nothing
> > > happens after the renderer references a new "data", why is there the
> > > invalidation of renderers which have a correct state already?
> > > >
> > > > --- In flexcoders@yahoogroups.com  
> > > >  , Alex
> > > Harui  wrote:
> > > > >
> > > > > When useVirtualLayout=true, renderers are being recycled so more
> > > invalidation does go on. It pretty much has to. You might be able to block
> > > some of it, depending on your scenario.
> > > > >
> > > > >
> > > > > On 8/9/10 12:12 AM, "Florian"  wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > When scrolling my custom item renderer, which inherits from
> > > ItemRenderer, i notice significant performance problems, when scrolling 
> > > the
> > > list. It seems like the list's layout is invalidating the component when 
> > > the
> > > list is scrolled.
> > > > >
> > > > > I configured the list's layout with the following parameters:
> > > > >
> > > > >  > > paddingBottom="0" paddingLeft="0" paddingRight="0" paddingTop="0"
> > > rowHeight="82" useVirtualLayout="true", variableRowHeight="false" />
> > > > >
> > > > > I also overwrote the renderer's measuredWidth and measuredHeight
> > > properties:
> > > > >
> > > > > override public function set measuredHeight(value:Number):void
> > > > > {
> > > > > height = super.measuredHeight = value;
> > > > > }
> > > > >
> > > > > override public function set measuredWidth(value:Number):void
> > > > > {
> > > > > width = super.measuredWidth = value;
> > > > > }
> > > > >
> > > > > The question for me now popping up is, how to avoid those unnecessary
> > > invalidation cycles? I'd expect the layout to be at least as smart as
> > > handling size changes only when the item renderer's owner changes it's
> > > width, since the rowHeight is set.
> > > > >
> > > > > Best regards
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alex Harui
> > > > > Flex SDK Team
> > > > > Adobe System, Inc.
> > > > > http://blogs.adobe.com/aharui
> > > > >
> > > >
> > >
> > >
> > >
> >
> 
> 
> 
> 
> 
> 
> --
> Alex Harui
> Flex SDK Team
> Adobe System, Inc.
> http://blogs.adobe.com/aharui
>

Re: [flexcoders] Re: ItemRenderer gets invalidated when List is scrolled

[Alex Harui]

Are you saying you are seeing extra invalidation calls when scrolling?  If the 
renderer is using autosizing text controls there can be extra invalidation 
calls.  We are looking at issues related to that right now.  Not sure we can 
always optimize them away.


On 8/9/10 1:05 PM, "Florian"  wrote:






No, i'm aware of the component live cycle. What i was not aware of: creating a 
loop when accessing contentWidth in updateDisplayList... it just hit me right 
into my face.

Just for the record: my observation of the additional invalidation cycles was 
when the renderer was moved in the viewport AFTER new data has been referenced. 
So scrolling the list was causing the trouble. But neither the owner nor the 
layout was responsible for this behavior, it was the component itself.

Thanx for taking the time though :)

--- In flexcoders@yahoogroups.com  , 
dorkie dork from dorktown  wrote:
>
> With useVirtualLayout set to true the list will create a set number of
> renderers. As you scroll the list will recycle these item renderers. In this
> scenario you are never guaranteed that the renderer associated with your
> data will remain with that data.
>
> If you want to guarantee that the renderer always remains connected with the
> data item then set useVirtualLayout to false.
>
> Alex can correct me, but you may also be able to check if the data is the
> same data in the set data override and if so prevent setting the super.data
> property. Although, I think once it is decided a renderer will be recycled
> the data property is set to null before hand.
>
> On Mon, Aug 9, 2010 at 4:26 AM, Florian  wrote:
>
> >
> >
> > My thoughts more specifically:
> > - the data property is set -> an invalidation should occur.
> > - a renderer is reused -> an invalidation should occur.
> > - a renderer is scrolled within the view port -> no invalidation should
> > occur, after its size is determined.
> >
> > Or am i wrong?
> >
> >
> > --- In flexcoders@yahoogroups.com   
> > ,
> > "Florian"  wrote:
> > >
> > > Yes, i understand this aspect of the component model. But since nothing
> > happens after the renderer references a new "data", why is there the
> > invalidation of renderers which have a correct state already?
> > >
> > > --- In flexcoders@yahoogroups.com   
> > > , Alex
> > Harui  wrote:
> > > >
> > > > When useVirtualLayout=true, renderers are being recycled so more
> > invalidation does go on. It pretty much has to. You might be able to block
> > some of it, depending on your scenario.
> > > >
> > > >
> > > > On 8/9/10 12:12 AM, "Florian"  wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > When scrolling my custom item renderer, which inherits from
> > ItemRenderer, i notice significant performance problems, when scrolling the
> > list. It seems like the list's layout is invalidating the component when the
> > list is scrolled.
> > > >
> > > > I configured the list's layout with the following parameters:
> > > >
> > > >  > paddingBottom="0" paddingLeft="0" paddingRight="0" paddingTop="0"
> > rowHeight="82" useVirtualLayout="true", variableRowHeight="false" />
> > > >
> > > > I also overwrote the renderer's measuredWidth and measuredHeight
> > properties:
> > > >
> > > > override public function set measuredHeight(value:Number):void
> > > > {
> > > > height = super.measuredHeight = value;
> > > > }
> > > >
> > > > override public function set measuredWidth(value:Number):void
> > > > {
> > > > width = super.measuredWidth = value;
> > > > }
> > > >
> > > > The question for me now popping up is, how to avoid those unnecessary
> > invalidation cycles? I'd expect the layout to be at least as smart as
> > handling size changes only when the item renderer's owner changes it's
> > width, since the rowHeight is set.
> > > >
> > > > Best regards
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alex Harui
> > > > Flex SDK Team
> > > > Adobe System, Inc.
> > > > http://blogs.adobe.com/aharui
> > > >
> > >
> >
> >
> >
>






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

[flexcoders] Re: ItemRenderer gets invalidated when List is scrolled

[Florian]

No, i'm aware of the component live cycle. What i was not aware of: creating a 
loop when accessing contentWidth in updateDisplayList... it just hit me right 
into my face.

Just for the record: my observation of the additional invalidation cycles was 
when the renderer was moved in the viewport AFTER new data has been referenced. 
So scrolling the list was causing the trouble. But neither the owner nor the 
layout was responsible for this behavior, it was the component itself.

Thanx for taking the time though :)

--- In flexcoders@yahoogroups.com, dorkie dork from dorktown 
 wrote:
>
> With useVirtualLayout set to true the list will create a set number of
> renderers. As you scroll the list will recycle these item renderers. In this
> scenario you are never guaranteed that the renderer associated with your
> data will remain with that data.
> 
> If you want to guarantee that the renderer always remains connected with the
> data item then set useVirtualLayout to false.
> 
> Alex can correct me, but you may also be able to check if the data is the
> same data in the set data override and if so prevent setting the super.data
> property. Although, I think once it is decided a renderer will be recycled
> the data property is set to null before hand.
> 
> On Mon, Aug 9, 2010 at 4:26 AM, Florian  wrote:
> 
> >
> >
> > My thoughts more specifically:
> > - the data property is set -> an invalidation should occur.
> > - a renderer is reused -> an invalidation should occur.
> > - a renderer is scrolled within the view port -> no invalidation should
> > occur, after its size is determined.
> >
> > Or am i wrong?
> >
> >
> > --- In flexcoders@yahoogroups.com ,
> > "Florian"  wrote:
> > >
> > > Yes, i understand this aspect of the component model. But since nothing
> > happens after the renderer references a new "data", why is there the
> > invalidation of renderers which have a correct state already?
> > >
> > > --- In flexcoders@yahoogroups.com , Alex
> > Harui  wrote:
> > > >
> > > > When useVirtualLayout=true, renderers are being recycled so more
> > invalidation does go on. It pretty much has to. You might be able to block
> > some of it, depending on your scenario.
> > > >
> > > >
> > > > On 8/9/10 12:12 AM, "Florian"  wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > When scrolling my custom item renderer, which inherits from
> > ItemRenderer, i notice significant performance problems, when scrolling the
> > list. It seems like the list's layout is invalidating the component when the
> > list is scrolled.
> > > >
> > > > I configured the list's layout with the following parameters:
> > > >
> > > >  > paddingBottom="0" paddingLeft="0" paddingRight="0" paddingTop="0"
> > rowHeight="82" useVirtualLayout="true", variableRowHeight="false" />
> > > >
> > > > I also overwrote the renderer's measuredWidth and measuredHeight
> > properties:
> > > >
> > > > override public function set measuredHeight(value:Number):void
> > > > {
> > > > height = super.measuredHeight = value;
> > > > }
> > > >
> > > > override public function set measuredWidth(value:Number):void
> > > > {
> > > > width = super.measuredWidth = value;
> > > > }
> > > >
> > > > The question for me now popping up is, how to avoid those unnecessary
> > invalidation cycles? I'd expect the layout to be at least as smart as
> > handling size changes only when the item renderer's owner changes it's
> > width, since the rowHeight is set.
> > > >
> > > > Best regards
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alex Harui
> > > > Flex SDK Team
> > > > Adobe System, Inc.
> > > > http://blogs.adobe.com/aharui
> > > >
> > >
> >
> >  
> >
>

Re: [flexcoders] Re: ItemRenderer gets invalidated when List is scrolled

[dorkie dork from dorktown]

With useVirtualLayout set to true the list will create a set number of
renderers. As you scroll the list will recycle these item renderers. In this
scenario you are never guaranteed that the renderer associated with your
data will remain with that data.

If you want to guarantee that the renderer always remains connected with the
data item then set useVirtualLayout to false.

Alex can correct me, but you may also be able to check if the data is the
same data in the set data override and if so prevent setting the super.data
property. Although, I think once it is decided a renderer will be recycled
the data property is set to null before hand.

On Mon, Aug 9, 2010 at 4:26 AM, Florian  wrote:

>
>
> My thoughts more specifically:
> - the data property is set -> an invalidation should occur.
> - a renderer is reused -> an invalidation should occur.
> - a renderer is scrolled within the view port -> no invalidation should
> occur, after its size is determined.
>
> Or am i wrong?
>
>
> --- In flexcoders@yahoogroups.com ,
> "Florian"  wrote:
> >
> > Yes, i understand this aspect of the component model. But since nothing
> happens after the renderer references a new "data", why is there the
> invalidation of renderers which have a correct state already?
> >
> > --- In flexcoders@yahoogroups.com , Alex
> Harui  wrote:
> > >
> > > When useVirtualLayout=true, renderers are being recycled so more
> invalidation does go on. It pretty much has to. You might be able to block
> some of it, depending on your scenario.
> > >
> > >
> > > On 8/9/10 12:12 AM, "Florian"  wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > When scrolling my custom item renderer, which inherits from
> ItemRenderer, i notice significant performance problems, when scrolling the
> list. It seems like the list's layout is invalidating the component when the
> list is scrolled.
> > >
> > > I configured the list's layout with the following parameters:
> > >
> > >  paddingBottom="0" paddingLeft="0" paddingRight="0" paddingTop="0"
> rowHeight="82" useVirtualLayout="true", variableRowHeight="false" />
> > >
> > > I also overwrote the renderer's measuredWidth and measuredHeight
> properties:
> > >
> > > override public function set measuredHeight(value:Number):void
> > > {
> > > height = super.measuredHeight = value;
> > > }
> > >
> > > override public function set measuredWidth(value:Number):void
> > > {
> > > width = super.measuredWidth = value;
> > > }
> > >
> > > The question for me now popping up is, how to avoid those unnecessary
> invalidation cycles? I'd expect the layout to be at least as smart as
> handling size changes only when the item renderer's owner changes it's
> width, since the rowHeight is set.
> > >
> > > Best regards
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Alex Harui
> > > Flex SDK Team
> > > Adobe System, Inc.
> > > http://blogs.adobe.com/aharui
> > >
> >
>
>  
>

[flexcoders] Re: ItemRenderer gets invalidated when List is scrolled

[Florian]

My thoughts more specifically:
- the data property is set -> an invalidation should occur.
- a renderer is reused -> an invalidation should occur.
- a renderer is scrolled within the view port -> no invalidation should occur, 
after its size is determined.

Or am i wrong?

--- In flexcoders@yahoogroups.com, "Florian"  wrote:
>
> Yes, i understand this aspect of the component model. But since nothing 
> happens after the renderer references a new "data", why is there the 
> invalidation of renderers which have a correct state already?
> 
> --- In flexcoders@yahoogroups.com, Alex Harui  wrote:
> >
> > When useVirtualLayout=true, renderers are being recycled so more 
> > invalidation does go on.  It pretty much has to.  You might be able to 
> > block some of it, depending on your scenario.
> > 
> > 
> > On 8/9/10 12:12 AM, "Florian"  wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> > When scrolling my custom item renderer, which inherits from ItemRenderer, i 
> > notice significant performance problems, when scrolling the list. It seems 
> > like the list's layout is invalidating the component when the list is 
> > scrolled.
> > 
> > I configured the list's layout with the following parameters:
> > 
> >  > paddingBottom="0" paddingLeft="0" paddingRight="0" paddingTop="0" 
> > rowHeight="82" useVirtualLayout="true", variableRowHeight="false" />
> > 
> > I also overwrote the renderer's measuredWidth and measuredHeight properties:
> > 
> > override public function set measuredHeight(value:Number):void
> > {
> >  height = super.measuredHeight = value;
> > }
> > 
> > override public function set measuredWidth(value:Number):void
> > {
> >  width = super.measuredWidth = value;
> > }
> > 
> > The question for me now popping up is, how to avoid those unnecessary 
> > invalidation cycles? I'd expect the layout to be at least as smart as 
> > handling size changes only when the item renderer's owner changes it's 
> > width, since the rowHeight is set.
> > 
> > Best regards
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe System, Inc.
> > http://blogs.adobe.com/aharui
> >
>

[flexcoders] Re: ItemRenderer gets invalidated when List is scrolled

[Florian]

Yes, i understand this aspect of the component model. But since nothing happens 
after the renderer references a new "data", why is there the invalidation of 
renderers which have a correct state already?

--- In flexcoders@yahoogroups.com, Alex Harui  wrote:
>
> When useVirtualLayout=true, renderers are being recycled so more invalidation 
> does go on.  It pretty much has to.  You might be able to block some of it, 
> depending on your scenario.
> 
> 
> On 8/9/10 12:12 AM, "Florian"  wrote:
> 
> 
> 
> 
> 
> 
> When scrolling my custom item renderer, which inherits from ItemRenderer, i 
> notice significant performance problems, when scrolling the list. It seems 
> like the list's layout is invalidating the component when the list is 
> scrolled.
> 
> I configured the list's layout with the following parameters:
> 
>  paddingLeft="0" paddingRight="0" paddingTop="0" rowHeight="82" 
> useVirtualLayout="true", variableRowHeight="false" />
> 
> I also overwrote the renderer's measuredWidth and measuredHeight properties:
> 
> override public function set measuredHeight(value:Number):void
> {
>  height = super.measuredHeight = value;
> }
> 
> override public function set measuredWidth(value:Number):void
> {
>  width = super.measuredWidth = value;
> }
> 
> The question for me now popping up is, how to avoid those unnecessary 
> invalidation cycles? I'd expect the layout to be at least as smart as 
> handling size changes only when the item renderer's owner changes it's width, 
> since the rowHeight is set.
> 
> Best regards
> 
> 
> 
> 
> 
> 
> --
> Alex Harui
> Flex SDK Team
> Adobe System, Inc.
> http://blogs.adobe.com/aharui
>