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: 94
Registered: ‎03-06-2009
My Device: Not Specified

Screen slow inside application

Hi,

 

The screen of our application is very slow on 8900. But the same screen is running fine when using bold.

 

we are trying to make screen faster on 8900.Our application is huge which uses WiFi,GSM, and lots of our things. So our guess was that the screen is working slow inside our HEAVY application. To test this, we made a dummy program (very light which only shows the screen) and created exactly the same screen. The observations show that the same screen (with all the fields) works fast inside dummy application.

 

We dont know why screen is running slow in our application.

 

So it seems like the native is allocating it lesser CPU or refresh rate etc. Blind guess could be that the native starts penalizing if a particular application uses too much CPU or something like that. Since our various components like Call Manager, Wifi Engine use some CPU to do their jobs, the Screens of our Application get lesser CPU/event thread time.

A point to be noted is that I have run our RADialer App, and the Test App together on the Device too. RADialer was slow, Test App was fast. So it is not a case of overall CPU shortage, but something like “If process A uses more than 20% CPU, native will allocate it lesser event thread time” or something like that.

 

 

Any help would be of great value.

 

 

rgds

Krishn2

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

Re: Screen slow inside application

You can set the priority of your worker Threads, I normally set mine to low.  See Thread API, especially setPriority(..) and MIN_PRIORITY.

 

That said, I would also go round your UI Threads and Worker Threads and make sure that they are not tying up the Event Thread when they don't need to.  I would stick some test code like this

 

if ( Application.isEventDispatchThread() ) {

throw RuntimeException("Running on Event Thread and should not be");

}

 

where you don't think the code should be running on the Event Thread.  You have removed this interaction in your 'light' program, so as well as taking away something that could have been using your cycles, you took away something that could have been running on the Event Thread.  Both will make your application seem sluggish, the Event Thread is actually I t suspect the more likely culprit.

 

Finally I would do some profiling work.  I do however remember some vague comment that the profiler did not work very well with multiple Threads, but that could have been an old JDE.  Try it and let us know how you get on with it using a later JDE. 

 

But this is all general stuff and does not address the fact that it is slow on the Curve and not on the Bold.  You don't say which Bold you are talking about here, but I presume you mean the 9000.  So you suggestion that the later OS in the Curve is trying to be clever with its cycles might be correct.  SO I would definitely try the Priority thing first since it is the easiest test.

 

Hope this helps.

Developer
Posts: 157
Registered: ‎02-18-2009
My Device: Not Specified

Re: Screen slow inside application

I experience a similar problem. My application is fast on Storm 4.7, Storm 5, Bold 9000, Pearl 8100 etc. but slow on the 8900. In the screen which is slow I override the paint event so I can paint on the main screen. This however seems to be extremely slow on the 8900. The paint screen is slow even with the following code:

 

 

protected void paint(final Graphics g)
{
    super.paint(g);

    if (getFieldWithFocus() == recipientsField)
    {
    }
}

On all other devices the paint code does a lot more and is much faster.

 

Have you found a solution already?

 

Developer
Posts: 91
Registered: ‎05-13-2009
My Device: Not Specified

Re: Screen slow inside application

Check whether you properly close all connections (FileConnections, HttpConnections, etc) if it were used at all.

Developer
Posts: 157
Registered: ‎02-18-2009
My Device: Not Specified

Re: Screen slow inside application

The screen is only slow when I override the paint method and the screen is created from an application menu event (ApplicationMenuItemRepository.MENUITEM_MESSAGE_LIST).

 

If I do not override the paint method or I create the screen in a 'normal' way (i.e. from an application icon) that the same screen is not slow. This only happens on a 8900.

 

Somehow it looks like the paint is behaving differently when the screen is created from an application menu item event.

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

Re: Screen slow inside application

What OS is the 8900 running.

 

Can you give us an idea on what you are doing in the paint method?

 

I have had OS level specific oddities in my UI processing, these generally turned out to be things that I could get away with in lower level OS's that the later levels tightened up on.  So generally I could recode the offending thing so that it worked in all levels.  Perhaps something like that is happening here?  Doubt it mind you, given that it works as a normal screen, just not as a Menu item. 

 

ACtually of course the on difference between the menu item and the ordinary screen in this case, is that the menu tem will be running in the process space of the Messaging application.  Maybe you could consider using IPC to get the processing back into your own application and that would solve the problem?

New Developer
Posts: 4
Registered: ‎02-01-2010
My Device: 8900, 9000, 9550, 8320
My Carrier: Airtel

Re: Screen slow inside application

I work with Krishn2 and I will add an observation from an experiment:

 

I added a lot (dozens) of big String variables in some test classes in the Test Application, and also added a lot of junk public methods. This made the Screen very slow, just like in our actual application.

So it seems that if an application uses a lot of memory, or its cod file is very large, the device penalises the application by giving it a poor UI refresh rate.

 

Note that if I run a light application (small memory use) ALONG with a big application: the small application is fast, while the big application is slow. So it is NOT that the device is running out of memory as a whole, but that it is choosing and penalising big applications.

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

Re: Screen slow inside application

In your experiment, did you notice the 'hour glass' icon displaying while your application was running slowly? 

 

Also have you looked at the Event Log while it is running slowly to see if there is any unusual activity in there?

New Developer
Posts: 4
Registered: ‎02-01-2010
My Device: 8900, 9000, 9550, 8320
My Carrier: Airtel

Re: Screen slow inside application

I didnt see the hourglass when running the Test Application alone (without my actual Application). I had made sure that the objects reference each other and dont get garbage collected.

Also, GC should slow down all applications, and also only when the garbage collector is running. But when I run 2 applications together, only the one with lot of variables is getting slow, and that too continuously.

Developer
Posts: 157
Registered: ‎02-18-2009
My Device: Not Specified

Re: Screen slow inside application

[ Edited ]

The OS version is 4.1.6.310. I tried to run the same code on a simulator with the exact same version without any problems.

 

I tried the see whether it was caused by my specific screen but the same problem occurs with any other screen. If I override paint() the screen is suddenly extremely slow. It really makes no difference what the paint is actually doing. Just adding a log statement results in a sluggish screen. I checked whether the paint was called multiple times in shot succession but it was not. If the paint is overridden every user action on that screen is slow. Moving the cursor, typing etc.

 

I also checked whether there was a difference in thread priority when the screen was created from an application menu event or created from a normal application but there was no difference (priority was 5 in both cases).