Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
Developer
kmitchell
Posts: 41
Registered: ‎11-01-2010
My Device: BlackBerry Bold 9780, PlayBook 16GB, PlayBook 32GB
Accepted Solution

Is everyone's List pathetically slow?!!!!!!!!

Hi everyone,

 

I have wrote a few apps  now and all on appworld. After a few releases and OS updates, they are all still visibly slow. I did notice that most are slow because of the List (I use QNX API)  The fastest one uses a simple cell renderer with one label. So I expect it to be faster. The list is perceived to be fast because I only tested 50 rows; probably should do more testing to see whats happens if its 100, 200, 1000 rows!

 

The other lists are not that fancy either. Each row has lets say 10 labels.  The more labels, the slower it becomes. The scrolling feature then hesitates so much, its embarrassing. Basically, I have to touch, wait a couple seconds (slight exaggeration) , then slowly move the list. No simple swiping here :smileyhappy:  I am alone? 

 

So, now, I'm wondering, is anyone else having this issue. Did anyone else spend time analyizing whats the most efficient way of creating cell renderers and skins. I'm only interested in ways to develop custom cell renderers/skins

 

I execute a custom skin in the cell renderer. Maybe I need a different approach to gain some performance. 

 

Also, based on the reviews so far, I dont think upgrading to 2.7 is going to help this!!!! 

 

 

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: Is everyone's List pathetically slow?!!!!!!!!

I have a few apps in development with List using a custom CellRenderer subclass, one with three labels and some special positioning code and my own version of the new truncationMode support (truncating to fit and adding "...").  All are working identically in performance after the 1.0.6 update.

 


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
jtegen
Posts: 6,541
Registered: ‎10-27-2010
My Device: HTC One, PlayBook, LE Z10, DE Q10

Re: Is everyone's List pathetically slow?!!!!!!!!

The ScrollPane, which I assume is used in things likes lists, can become slow if it gets very large with content.
Developer
kmitchell
Posts: 41
Registered: ‎11-01-2010
My Device: BlackBerry Bold 9780, PlayBook 16GB, PlayBook 32GB

Re: Is everyone's List pathetically slow?!!!!!!!!

Hi Peter9477,

 

Thanks for replying. Are you finding your apps to be much slower than the AIR desktop and even the simulator? Maybe I need to buy an XT pc  so I can simulate better :smileyhappy:  (couldnt resist)

 

Is the performance ok? How many rows?   ... just trying to get a sense of performance. could be my code. I am going to rewrite one list renderer and skin today/tomorrow and see if it improves.

 

 

 

 

 

 

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: Is everyone's List pathetically slow?!!!!!!!!

I never use the desktop or simulator any more...

 

Performance is excellent... as fast as any of the fastest lists in the RIM-supplied apps.

 

If your renderer is designed/implemented properly, the performance of the list should basically not be related to the number of rows in the list, but only to the complexity of the renderer itself (i.e. what you show in a given row).  That statement would be false if your DataProvider is more dynamic than simply wrapping an Array of objects with various attributes such as 'label'... but a "static" DataProvider should have no impact on speed either.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: Is everyone's List pathetically slow?!!!!!!!!

@jtegen, List actually doesn't use a ScrollPane, though it does use an internal ScrollManager class (undocumented) which I expect is also used by the ScrollPane class.

@kmitchell, I shouldn't sound so certain about number of rows having no impact actually. The implementation of List *could* have code which performs a linear search of the DataProvider under certain conditions, in which case it would be affected by number of items. If it does that, I'd say it's a serious design flaw, but they may have taken a shortcut on that front out of expediency, or a belief that it wouldn't matter in any real situation. (For example, I doubt a List with 10,000 items could be used effectively on a small touch device like this, so if the slowdown only shows up above, say, 2000 items they might have said "what the hey" and ignored it. That's all theory for now though... would have to inspect the bytecode or decompile.)

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
pyth
Posts: 508
Registered: ‎01-19-2011
My Device: My Trusty Red Plane

Re: Is everyone's List pathetically slow?!!!!!!!!

The problem you describe, is, as jtegen said, similar to the one occurring in ScrollPanes. I also have like 50+ items in my pane, and the scrolling was very annoying when you had items with at least 5 components each (4 labels and an image in my case)

 

though i don't know if it applies to self defined cell renderers, you ca try two things: one, if and only if your list item is static, it may help to set the flag "cacheAsBitmap = true". Secondly, if not, I added another invisible layer on top of the whole item, just a simple sprite with alpha = 0 (depends on if you have clickable objects)

 

see here

http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Scrolling-issues-on-PlayBook-devi... 

-----------------------------------------------------------------------
I'm a bird from outer space. But I'm not flappy o.o
Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: Is everyone's List pathetically slow?!!!!!!!!

@kmitchell, just rereading your first post.  The List with a single label, in other words using the default CellRenderer (?), works fine?  But your own, which subclasses CellRenderer and adds many labels, works slowly?

 

I'm thinking you may have followed some of the wrong advice posted in here many months ago.  I've studied the List, DataProvider, and CellRenderer (not to mention some of ScrollManager) implementations fairly extensively at this point, and have concluded that much of the earliest advice in this forum was based on mistaken assumptions about how things were implemented, admittedly caused in part by the limited and/or absent documentation on the relevant aspects of these widgets.

 

I think a properly implemented CellRenderer probably will have no major issues, but I could well imagine that many out there are seriously sluggish at this point.

 

Can you briefly describe your implementation, maybe show some sample snippets of which methods you override and what you do in them?  Or when you add/remove/modify the additional Labels you added?  Or just point to the one or two posts in this forum which guided you?


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
kmitchell
Posts: 41
Registered: ‎11-01-2010
My Device: BlackBerry Bold 9780, PlayBook 16GB, PlayBook 32GB

Re: Is everyone's List pathetically slow?!!!!!!!!

@peter9477,  

 

Ok, that might be the case. I wrote the cell renderers a long time ago!   But I thought it was very simple in what I was coding, something like this. Any help in a new design is better. I was thinking about following a blog I found and see if it helps("

 

   Cell renderer:



  override public function set data($Objectbject):void 
  {
     _SkinableComp.setSkin(new ListSkin($Object));
     _SkinableComp.drawNow();
     _SkinableComp.skin.state = "up"; 
     addChild(_SkinableComp);
  }

 

Skin:

 

override protected function initializeStates():void 
  {
   
   upSkin = new Sprite();
   seSkin = new Sprite();
   
   setSkinState(SkinStates.UP, upSkin );
   setSkinState(SkinStates.SELECTED,seSkin );
  }
  override protected function draw():void
  {
   fillUpSkin();
   fillSeSkin();
  }
  
  private function fillUpSkin():void
  {

    upSkin.addchild(alabel1)
    upSkin.addchild(alabel2)
    upSkin.addchild(alabel3)
  }  
  private function fillSeSkin():void
  {
    seSkin.addchild(alabel1)
    seSkin.addchild(alabel2)
    seSkin.addchild(alabel3)
  }  

 

 

Developer
peter9477
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10

Re: Is everyone's List pathetically slow?!!!!!!!!

Okay, I'd say it's a near certainty that explains the performance problems.

 

I need to write a longer article explaining how the whole thing works, I think, but for now, here's a link to a short post (not on precisely the same topic) which explains some of the background.  It alone might help you understand what's really doing on.

 

The key thing is to understand that the List creates only enough CellRenderer instances for what the number of rows displayed at any one time, plus a few extras to account for when you're scrolling (more if you're scrolling quicker), and then it REUSES those instances over and over, mostly just calling the set data() accessor on them.  As one gets scrolled (for example) off the top of the list, it basically moves it to the bottom (simply adjusting its .x or .y position as needed), and sets its data to the object from the DataProvider at that appropriate index position.

 

That means you should pre-create and addChild() all the Labels and such that you need in an individual renderer in its constructor, or some routine that is not called repeatedly. 

 

If you constantly construct new objects in set data(), and are constantly and unnecessarily doing add/removeChild() calls all over the place, you'll definitely suffer performance issues.  Notice that in Ryan Stewart's code, he does not create or add things in the set data() call, but merely updates the items that are already there by reading data from the "data" object that is passed in.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!