Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hi there,

Well i just got my new LG6000, and tried several applications i've done... Wow, deadly SLOW!!! The same code is much much faster on the LG4400, T720, A530... First i thought it was only because the screen size is bigger, but wow that's too slow to be this (even on a screen where i just draw 2 pictures, fill the background, and draw some texts..)

Any idea why it is so slow? (btw i'm using timers between the loops, and tried to change the delay, but nothing really helped..)

/kUfa

That sounds strange. This phone is based on MSM6050 chipsets and according to the documentation it has "improved processing power" over MSM5100. Also according to the documentation MSM6050 has different memory interface so it may be reasonable to compile the code in ARM mode (on MSM5100 THUMB code works faster than ARM due to 16bit memory interface)
I wonder if the processor is actually slower or maybe just implementation of drawing functions is not particulary good?
What graphics interaces are you using? IDisplay? Drawing directly to the screen?
Ziemowit

That sounds strange. This phone is based on MSM6050 chipsets and according to the documentation it has "improved processing power" over MSM5100. Also according to the documentation MSM6050 has different memory interface so it may be reasonable to compile the code in ARM mode (on MSM5100 THUMB code works faster than ARM due to 16bit memory interface)
I wonder if the processor is actually slower or maybe just implementation of drawing functions is not particulary good?
What graphics interaces are you using? IDisplay? Drawing directly to the screen?
Ziemowit

I use CONVERTBMP and BitBlt for drawing pictures..
Maybe i should try to compile in ARM, if i manage to get it working properly using gnude.. ;)
/kUfa

I use CONVERTBMP and BitBlt for drawing pictures..
Maybe i should try to compile in ARM, if i manage to get it working properly using gnude.. ;)
/kUfa

CONVERTBMP may be very slow, so avoid using it. You can use it only once, to prepare all bitmaps when application starts.
About ARM mode, I am not really sure, if it's faster on VX6000, but it's worth to try if you are doing a lot of processing.
Ziemowit

CONVERTBMP may be very slow, so avoid using it. You can use it only once, to prepare all bitmaps when application starts.
About ARM mode, I am not really sure, if it's faster on VX6000, but it's worth to try if you are doing a lot of processing.
Ziemowit

Well, i use CONVERTBMP when the application starts, to prepare all the bitmap (otherwise i would be quiet lame using it every frame hehe) ...
/kUfa

Well, i use CONVERTBMP when the application starts, to prepare all the bitmap (otherwise i would be quiet lame using it every frame hehe) ...
/kUfa

Yeah in my experience the VX6000 is about as slow as the T720. Maybe even slower.

Yeah in my experience the VX6000 is about as slow as the T720. Maybe even slower.

We're still having problems with getting ours dev flashed.
Double check the os software verison of the phone. There was serious speed gains in the LGVX4000 (or samsung 610 either or) when we had the phone re-flashed.
The phone may actually be slower, we may know the chipsets, but we don't know what speed they're running at, they may have dropped the core speed to save battery etc.
Also, the phones ram may be rather slow/unstable, to keep costs down/batter life etc.
I'll post when we get a dev flashed phone back and had a chance to toy with it.

We're still having problems with getting ours dev flashed.
Double check the os software verison of the phone. There was serious speed gains in the LGVX4000 (or samsung 610 either or) when we had the phone re-flashed.
The phone may actually be slower, we may know the chipsets, but we don't know what speed they're running at, they may have dropped the core speed to save battery etc.
Also, the phones ram may be rather slow/unstable, to keep costs down/batter life etc.
I'll post when we get a dev flashed phone back and had a chance to toy with it.

My results match kUfa's.
All my art is pre-loaded and pre-CONVERTBMPed.
I'm rendering a frame in about 60ms (ave) on the T720 and 90ms (ave) on the VX6000.
I have ruled out the "larger screen" issue. My app has partial autoscrolling, just for when the action gets to the edge of an arena approximately 30% longer than the screen. The rest of the time I just do very careful dirty rect management. Since the VX6000 has a larger screen, I end up doing full redraw much less.
My current hypothesis is bit depth. The T720 has bit depth 12 and uses 2 bytes for each pixel but the VX6000 has bit depth 18, which is too big for 2 bytes.
That means the VX6000 is pumping 150-200% as much data to the physical screen on each IDISPLAY_Update(), and may be doing a bunch of shifting and masking, depending on their internal image format.
-Jesse

My results match kUfa's.
All my art is pre-loaded and pre-CONVERTBMPed.
I'm rendering a frame in about 60ms (ave) on the T720 and 90ms (ave) on the VX6000.
I have ruled out the "larger screen" issue. My app has partial autoscrolling, just for when the action gets to the edge of an arena approximately 30% longer than the screen. The rest of the time I just do very careful dirty rect management. Since the VX6000 has a larger screen, I end up doing full redraw much less.
My current hypothesis is bit depth. The T720 has bit depth 12 and uses 2 bytes for each pixel but the VX6000 has bit depth 18, which is too big for 2 bytes.
That means the VX6000 is pumping 150-200% as much data to the physical screen on each IDISPLAY_Update(), and may be doing a bunch of shifting and masking, depending on their internal image format.
-Jesse

This is probably right--every 16-bit BREW phone is dog slow. This isn't as bad as the 9500--but the 9500 is insuffrable.

This is probably right--every 16-bit BREW phone is dog slow. This isn't as bad as the 9500--but the 9500 is insuffrable.

Jesse, where did you get this information about 18-bit colour on VX6000? According to the datasheet it's actually 16bit. Also according to may observations it's 16bit.
I have also found out that IDISPLAY_Update works in different way than on other phones. Normally IDISPLAY_Update just copies the whole screen bitmap to the screen. On VX6000 it's a bit more clever - VX6000 actually remembers what areas were affected by drawing functions and then only copies that.
So if you for example clear the screen and draw the whole screen then IDISPLAY_Update will be slow, but if you just update single detail - it will be much faster.
I have found it out because I am normally drawing directly on screen bitmap data and then calling IDISPLAY_Update, but on VX6000 this approach just didn't work and I had to manually persuade IDISPLAY_Update to copy the whole screen.
Ziemowit

Jesse, where did you get this information about 18-bit colour on VX6000? According to the datasheet it's actually 16bit. Also according to may observations it's 16bit.
I have also found out that IDISPLAY_Update works in different way than on other phones. Normally IDISPLAY_Update just copies the whole screen bitmap to the screen. On VX6000 it's a bit more clever - VX6000 actually remembers what areas were affected by drawing functions and then only copies that.
So if you for example clear the screen and draw the whole screen then IDISPLAY_Update will be slow, but if you just update single detail - it will be much faster.
I have found it out because I am normally drawing directly on screen bitmap data and then calling IDISPLAY_Update, but on VX6000 this approach just didn't work and I had to manually persuade IDISPLAY_Update to copy the whole screen.
Ziemowit

Quote:So if you for example clear the screen and draw the whole screen then IDISPLAY_Update will be slow, but if you just update single detail - it will be much faster
Well, that's maybe why all my applications are running very slowly on the lg6000, since games usually repaint the whole screen...
/kUfa

Quote:So if you for example clear the screen and draw the whole screen then IDISPLAY_Update will be slow, but if you just update single detail - it will be much faster
Well, that's maybe why all my applications are running very slowly on the lg6000, since games usually repaint the whole screen...
/kUfa

To verify the screen size is the problem, try telling your game that the screen is actually the size of the 4400. Maybe you just can't use the entire (large) display for the action, and need to limit it to a smaller region and then put up some banners on top/bottom.
-Aaron

To verify the screen size is the problem, try telling your game that the screen is actually the size of the 4400. Maybe you just can't use the entire (large) display for the action, and need to limit it to a smaller region and then put up some banners on top/bottom.
-Aaron

That's what i will try to do, i will post here the results..
/kUfa

That's what i will try to do, i will post here the results..
/kUfa

ziemowit: I'm looking at the data sheet now and under Display Configurations it definitely says "LCD color depth: 18 bit". Later, under Media and MIME Type Support, it says "BMP: Yes, 1/2/4/8/16 bit color".
My copy calls itself "80-D4036-xx, Rev B" from 6/19/2003. Do you have a different version?
Frankly I'm a bit surprised about that "BMP" entry. BMP format only supports bitdepths 1/4/8 (palettized) and 24 (RGB) according to:
http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html
...as well as other sources I found when I started playing with it.
-Jesse

ziemowit: I'm looking at the data sheet now and under Display Configurations it definitely says "LCD color depth: 18 bit". Later, under Media and MIME Type Support, it says "BMP: Yes, 1/2/4/8/16 bit color".
My copy calls itself "80-D4036-xx, Rev B" from 6/19/2003. Do you have a different version?
Frankly I'm a bit surprised about that "BMP" entry. BMP format only supports bitdepths 1/4/8 (palettized) and 24 (RGB) according to:
http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html
...as well as other sources I found when I started playing with it.
-Jesse

16-bit color can mean two different things. Is it a pallete of 2^16 colors, or is it RGB packed as 5 bits of Red, 6 bits of Green, and 5 bits of blue?
18-bit color is probably packed at 6 bits of Red, Green, and Blue, with either 18-bit, 24-bit or 32-bit padding.
-Aaron

16-bit color can mean two different things. Is it a pallete of 2^16 colors, or is it RGB packed as 5 bits of Red, 6 bits of Green, and 5 bits of blue?
18-bit color is probably packed at 6 bits of Red, Green, and Blue, with either 18-bit, 24-bit or 32-bit padding.
-Aaron

Well, my version of LGE VX6000 data sheet is 80-D4036-xx, Rev. B, dated 7/23/2003, so I think it's newer and it definitely says that colour depth is 16bit, so probably there was a mistake in older version of the document. Anyway, 18-bit colour wouldn't make much sense...
And about BMP files. They have definitelly nothing to do with display configiration.
Ziemowit

Well, my version of LGE VX6000 data sheet is 80-D4036-xx, Rev. B, dated 7/23/2003, so I think it's newer and it definitely says that colour depth is 16bit, so probably there was a mistake in older version of the document. Anyway, 18-bit colour wouldn't make much sense...
And about BMP files. They have definitelly nothing to do with display configiration.
Ziemowit

BMP files support 1,2,4,8,16,24,32 bit color directly. You could even get multilple layers (biPlanes), though I don't think anyone uses this.
There's quite a bit you can do with the BMP format, it's just that most apps don't use it all, or generate images that can. However, with PhotoShop 7.0 you can save 5551, 565, and byte ordered variants into BMPs. Sadly they still don't deal with dithering down to those from 24-bit.
For the phones, there's very little reason to go to full 16-bit, and I seem to recall that there aren't many phones that support it.
Tom

BMP files support 1,2,4,8,16,24,32 bit color directly. You could even get multilple layers (biPlanes), though I don't think anyone uses this.
There's quite a bit you can do with the BMP format, it's just that most apps don't use it all, or generate images that can. However, with PhotoShop 7.0 you can save 5551, 565, and byte ordered variants into BMPs. Sadly they still don't deal with dithering down to those from 24-bit.
For the phones, there's very little reason to go to full 16-bit, and I seem to recall that there aren't many phones that support it.
Tom

The VX-6000 would be the first device in the world with 18-bit color depth - at least as far as I know. I am almost certain that the information you have is incorrect. According to my information, the VX-6000 has a 16-bit display.

The VX-6000 would be the first device in the world with 18-bit color depth - at least as far as I know. I am almost certain that the information you have is incorrect. According to my information, the VX-6000 has a 16-bit display.

Yep, zeimowit was right. I recently re-downloaded all my device spec sheets and found a number of minor surprises like that.
That kills my hypothesis about memory-to-screen bandwidth accounting for the draw slowdown between the T720 and the VX6000. They're both looking at 2 bytes per pixel, so the mystery is still open.
I guess the next thing to check would be profiling the individual IDISPLAY_ and IGRAPHICS_ methods to see if the culprit can be isolated at a higher level.

Yep, zeimowit was right. I recently re-downloaded all my device spec sheets and found a number of minor surprises like that.
That kills my hypothesis about memory-to-screen bandwidth accounting for the draw slowdown between the T720 and the VX6000. They're both looking at 2 bytes per pixel, so the mystery is still open.
I guess the next thing to check would be profiling the individual IDISPLAY_ and IGRAPHICS_ methods to see if the culprit can be isolated at a higher level.

Here is how i tried to have "better performance" on the lg6000..
- main loop
>> update everything, but no paint
>> If no separate paiting, paint
>> set timer for main loop
>> If separate paiting & first launch, set timer for paint
- paint loop
>> paint everything
>> if not (app->exit) set timer for paint
I use the following parameters:
- timer for main loop : 5ms
- got separate paint, with timer : 10ms
Some frames will be skipped, but it still looks ok..
/kUfa

Here is how i tried to have "better performance" on the lg6000..
- main loop
>> update everything, but no paint
>> If no separate paiting, paint
>> set timer for main loop
>> If separate paiting & first launch, set timer for paint
- paint loop
>> paint everything
>> if not (app->exit) set timer for paint
I use the following parameters:
- timer for main loop : 5ms
- got separate paint, with timer : 10ms
Some frames will be skipped, but it still looks ok..
/kUfa

Well, i'm just back from the UK test center...
Sounds like the lags come when there is no network.... (the phone probably keeps trying to find one, and uses alot of cpu for it...)
So i just changed the parameters of my prev post, using 5ms for both, and i have *acceptable* framerate..
Btw tooooo bad!
Hope this will help,
/kUfa

Well, i'm just back from the UK test center...
Sounds like the lags come when there is no network.... (the phone probably keeps trying to find one, and uses alot of cpu for it...)
So i just changed the parameters of my prev post, using 5ms for both, and i have *acceptable* framerate..
Btw tooooo bad!
Hope this will help,
/kUfa

It's still not faster than the T720 though. I've been using an activated one all along and I'm rather unimpressed with the performance.

It's still not faster than the T720 though. I've been using an activated one all along and I'm rather unimpressed with the performance.