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

Developer

Forums

Forums:

As a test, I created a brew 3.1.5 build which runs fine on my LG8600 but if i put the same build on the LG VN150 (brew mp phone), it runs significantly slower. Has anyone encounted this kind of problem? The LGVN150 uses the QSC6055 processor but I dont know if that's inherently slow or not. I dont know where to find qualcomm processor comparison charts.

 

 

what sort of category your application belongs to ex. video playback, games, download content etc? 

what sort of category your application belongs to ex. video playback, games, download content etc? 

games. I'm using PNG files which gets converted to IBitmaps and then I use IDisplay_BitBlt to draw. I also use dirty rects so Im not redrawing the entire screen unless the scene or an interrupt happens. I can understand if the phone's color depth is 32-bit, but the LG VN150 is 16-bit (262,000 colors). I don't see any reason why it would behave so poorly. I also use IShell_GetUpTimeMS() and figure out how much longer to wait to get 25 frames per second. If the code+rendering takes longer than 40 ms, I call IShell_setTimer to 10ms to give brew at least some time to do its thing.
 

games. I'm using PNG files which gets converted to IBitmaps and then I use IDisplay_BitBlt to draw. I also use dirty rects so Im not redrawing the entire screen unless the scene or an interrupt happens. I can understand if the phone's color depth is 32-bit, but the LG VN150 is 16-bit (262,000 colors). I don't see any reason why it would behave so poorly. I also use IShell_GetUpTimeMS() and figure out how much longer to wait to get 25 frames per second. If the code+rendering takes longer than 40 ms, I call IShell_setTimer to 10ms to give brew at least some time to do its thing.
 

Ok...on each tick, are you converting PNG to IBitmap? I think instead of using PNG, you should try using BMP images and call CONVERTBMP and then IDisplay_BitBlt to draw. Try calling IDISPLAY_UpdateEx() instead of IDISPLAY_Update(). Can you create one sample application using ISHELL_SetTimer() which displays images continously and see if still you see the issue? Further I don't see issue with QSC6055 processor as many device has been launched on this chipset and we didn't get this kind of issue on these devices. One potential reason could be that BrewMP code base takes more memory footprint on ROM and is heavier than legacy Brew. 

Ok...on each tick, are you converting PNG to IBitmap? I think instead of using PNG, you should try using BMP images and call CONVERTBMP and then IDisplay_BitBlt to draw. Try calling IDISPLAY_UpdateEx() instead of IDISPLAY_Update(). Can you create one sample application using ISHELL_SetTimer() which displays images continously and see if still you see the issue? Further I don't see issue with QSC6055 processor as many device has been launched on this chipset and we didn't get this kind of issue on these devices. One potential reason could be that BrewMP code base takes more memory footprint on ROM and is heavier than legacy Brew. 

Im only converting my PNGs once before the scene starts. I keep an IBitmap reference so I can use IDisplay_BitBlt on each tick, or whenever i need to refresh the screen. I am using IDisplay_UpdateEx with a 60ms timer, which runs fine on regular 3.1.5 phones (15 frames per second is fine) but the speed dramatically slows down when the same code is place on the LGVN150. Since the code is 3.1.5 only, I shouldnt experience the heavier footprint from brew mp. I'll see if i can do some benchmark(?) tests to see how fast it is to draw a full screen ibitmap, etc.
 

Im only converting my PNGs once before the scene starts. I keep an IBitmap reference so I can use IDisplay_BitBlt on each tick, or whenever i need to refresh the screen. I am using IDisplay_UpdateEx with a 60ms timer, which runs fine on regular 3.1.5 phones (15 frames per second is fine) but the speed dramatically slows down when the same code is place on the LGVN150. Since the code is 3.1.5 only, I shouldnt experience the heavier footprint from brew mp. I'll see if i can do some benchmark(?) tests to see how fast it is to draw a full screen ibitmap, etc.
 

I hope issue may have been resolved, let me know if you still see issue.

I hope issue may have been resolved, let me know if you still see issue.

nope this phone is still giving me problems. Using the Logger, the phone constantly sends in a EVT_APP_SLEEP event. If I rapidly press keys on the keypad, the frame rate noticeably gets faster. I tried sending a ISHELL_SendEvent + EVT_KEY to maybe trick the phone to virtually press keys when the user isnt doing it, but that doesnt seem to work.
I have no idea why the phone keeps sending eCode=1029 or the EVT_APP_SLEEP event. It also does this on the LG VN150.
When I checked AEEDeviceInfo, the dwSleepDefer value is 0. Also, I dont know of any way to keep the phone active longer. Changing the backlight timer in the phone settings doesnt work and there is no sleep timer option.
the current phone SW version I have is VN251V3. HW version is Revision 1.1. Im also using brew 3.1.5 to compile.
 

nope this phone is still giving me problems. Using the Logger, the phone constantly sends in a EVT_APP_SLEEP event. If I rapidly press keys on the keypad, the frame rate noticeably gets faster. I tried sending a ISHELL_SendEvent + EVT_KEY to maybe trick the phone to virtually press keys when the user isnt doing it, but that doesnt seem to work.
I have no idea why the phone keeps sending eCode=1029 or the EVT_APP_SLEEP event. It also does this on the LG VN150.
When I checked AEEDeviceInfo, the dwSleepDefer value is 0. Also, I dont know of any way to keep the phone active longer. Changing the backlight timer in the phone settings doesnt work and there is no sleep timer option.
the current phone SW version I have is VN251V3. HW version is Revision 1.1. Im also using brew 3.1.5 to compile.
 

Are you returning TRUE from EVT_APP_NO_SLEEP? Returing TRUE from EVT_APP_NO_SLEEP prevents device to go in sleep mode.

Are you returning TRUE from EVT_APP_NO_SLEEP? Returing TRUE from EVT_APP_NO_SLEEP prevents device to go in sleep mode.