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

Java Development

Reply
New Developer
Posts: 18
Registered: ‎09-03-2008
My Device: Not Specified
Accepted Solution

Lots of LabelFields = very slow :-(

Hi all,

 

I've got a screen with a VerticalFieldManager. I'm running into speed issues in two common cases:

 

1) Creating the labelfields to put into the VFM. Here's some pseudocode of what I do:

 

labels = new LabelField[200];
// this for loop takes a couple of seconds on a real device
for (int i=0; i < 100; i++) {
  title = new LabelField("Title", FOCUSABLE);
  title.setFont(bold font);
  subtitle = new LabelField("Subtitle", NON_FOCUSABLE);
  labels[i*2] = title;
  labels[i*2+1] = subtitle;
}

// this next part goes quick, no problem
vfm = new VerticalFieldManager();
vfm.addAll(labels);
myScreen.add(vfm);

 

 

A look in the profiler indicates that 90+% of the time is being spent in UI code during the for loop, lots of Field.applyTheme() time, lots of setText() time as well. (I'm not on the event thread at this point.)

 

2) Eliminating one pair of labelfields (title and subtitle) from the VFM takes a couple of seconds. I'm using deleteRange(x, 2), and it's very slow, unfortunately.

 

I've done some research in the forums but haven't been able to find ways to speed this up. Any hints would be appreciated.

 

Thanks,

 

Steve

Developer
Posts: 19,633
Registered: ‎07-14-2008
My Device: Not Specified

Re: Lots of LabelFields = very slow :-(

[ Edited ]

Looking at you code, I would not suspect the time was taken in the for loop.  Until these are added to the Screen, my experience is that creating a load of Fields does not take that long.  I thought it was the process of laying these out on the Screen once they have been added, that takes the time.  If the loop was directly adding them to the Manager and the Manager was already on Screen, I can imagine that taking a very long time.

 

To get best performance from something like this, I recommend that you look at the ListField.  It is a little more complicated to start with, but the performance boost you will get is significant. 

New Contributor
Posts: 3
Registered: ‎01-21-2011
My Device: Not Specified

Re: Lots of LabelFields = very slow :-(

I have an app that uses up to 700 label fields on a screen.  This includes custom colors and style changes on some labels.  Total loading time on a Bold is about 2 -3 sec., but there are very heavy calculations to get the label values, formatting on most, etc.  I have multiple levels of managers and add each field to its manager when it is created. 

 

My problem was trying to rewrite the label fields after a sort.  This is very slow and was taking about 15 sec. on the simulator.  I does not redo the calculations, just rewrite the labels.  The solution was to pop the screen and push a new one.  This seems crude, but it works.  I have no idea why rewriting labels takes so much more time than creating them, but it does. 

 

If you need to make alot of changes to you screen, you might be better off doing the same. 

Developer
Posts: 19,633
Registered: ‎07-14-2008
My Device: Not Specified

Re: Lots of LabelFields = very slow :-(

"I have no idea why rewriting labels takes so much more time than creating them"

 

It is not the rewriting that takes the time.  Because you have added these Labels to a displayed screen, each time you change the content of the label, it must re-layout itself, which in turn means it has to relayout everything around it.  This is why it takes the time.

 

Your option of creating a new screen works because the Fields are only laid out once. 

 

Alternatively, you could have removed the highest level Manager from the Screen, updated the Fields, then added the Manager again.  Then the layout processing would only take place when the Manager is added.  I would suggest that this is a more efficient approach than creating a whole set of new Labels and Managers and Screen, but your code is working now, so I'm not sure I would recommend that you change it. 

 

Hope this is clear.

New Developer
Posts: 18
Registered: ‎09-03-2008
My Device: Not Specified

Re: Lots of LabelFields = very slow :-(

Thanks for the replies, guys. Mike, your tip led me to try creating a new VFM when I wanted to update the screen, which helped. However, some other operations were still too slow, which led me to go with Peter's suggestion.

 

Thanks Peter, switching to a ListField did the trick. Works very quickly now. Happy New Year! :-)

 

Steve

Developer
Posts: 723
Registered: ‎03-12-2009
My Device: Playbook

Re: Lots of LabelFields = very slow :-(

[ Edited ]

peter_strange wrote:

"I have no idea why rewriting labels takes so much more time than creating them"

 

It is not the rewriting that takes the time.  Because you have added these Labels to a displayed screen, each time you change the content of the label, it must re-layout itself, which in turn means it has to relayout everything around it.  This is why it takes the time.

 

Your option of creating a new screen works because the Fields are only laid out once. 

 

Alternatively, you could have removed the highest level Manager from the Screen, updated the Fields, then added the Manager again.  Then the layout processing would only take place when the Manager is added.  I would suggest that this is a more efficient approach than creating a whole set of new Labels and Managers and Screen, but your code is working now, so I'm not sure I would recommend that you change it. 

 

Hope this is clear.


One "hack" that is very fast and does not require a relayout is to change the y coordinatesof the fields by hand versus calling a layout.

 

Same can be done to height of the field as well Smiley Wink   This is the basis of creating FAST fisheye lists.

 

Doing so does not force a layout, just force a repaint after you're done.

 

Another cool trick is to subclass fields to detect if they have "updated" and only relayout if they did.

 

I always found it stupid to have to relayout the whole screen when the text got update but the label did not need to be resized.