Skip to main content

Crazy slow performance using semi-transparent images

13 replies [Last post]
lreyero
Offline
Joined: 2009-02-05
Points: 0

Hi,

Using semi-transparent images in LWUIT is extremely slow!! There must be something wrong with the implementation.

I have made a sample Form with a background and a semi-transparent image (24 bit PNG) in a label. A key is used to toggle the visibility of the label.

Here is the benchmark obtained on a Nokia N95:

When the label is NOT visible: 32 frame per second
When the label is visible: 2 frames per second !!

There is clearly something wrong with the implementation. There is no way I could use LWUIT in my project with such performance.
Please let me know if there is something I could do to get better performances.

I would really appreciate your help!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Arnau Vàzquez

Sorry but this doesn't solve the performance problem we're seeing on
S60, because we're not creating images from a Resources file but
directly from the JAR (like you propose). It is weird that the same app
runs faster and smoother on a low-end S40 than on an N95 (same
resources, same code). Maybe the style tweaks you commented about can
help? I thought these kind of problems had been solved a while ago :s

Arnau

En/na lwuit-users@mobileandembedded.org ha escrit:
> I found the problem !
>
> The performance issue as nothing to do with semi-transparency or 24 bit PNG.
>
> The issue is the Resource Editor !
> I removed all of my images from there, and I load them in the application the traditional way (without using the Resources class). Performances are good, I have more than 10 FPS for most of my screens.
>
> to load an image use :
> Image.createImage(getClass().getResourceAsStream("/image.png"));
>
> There must be a bug in the Resource Editor which causing random images to become extremely slow to paint. While it gets fixed I can work without.
> [Message sent by forum member 'lreyero' (lreyero)]
>
> http://forums.java.net/jive/thread.jspa?messageID=331412
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

lreyero
Offline
Joined: 2009-02-05
Points: 0

I found the problem !

The performance issue as nothing to do with semi-transparency or 24 bit PNG.

The issue is the Resource Editor !
I removed all of my images from there, and I load them in the application the traditional way (without using the Resources class). Performances are good, I have more than 10 FPS for most of my screens.

to load an image use :
Image.createImage(getClass().getResourceAsStream("/image.png"));

There must be a bug in the Resource Editor which causing random images to become extremely slow to paint. While it gets fixed I can work without.

Chen Fishbein

Hi,

lwuit-users@mobileandembedded.org wrote:
> I found the problem !
>
> The performance issue as nothing to do with semi-transparency or 24 bit PNG.
>
> The issue is the Resource Editor !
> I removed all of my images from there, and I load them in the application the traditional way (without using the Resources class). Performances are good, I have more than 10 FPS for most of my screens.
>
>
Is it possible that your images where checked as indexed?indexed images
are lighter in terms of memory, but in terms of performance are slower.

Regards,
Chen

> to load an image use :
> Image.createImage(getClass().getResourceAsStream("/image.png"));
>
> There must be a bug in the Resource Editor which causing random images to become extremely slow to paint. While it gets fixed I can work without.
> [Message sent by forum member 'lreyero' (lreyero)]
>
> http://forums.java.net/jive/thread.jspa?messageID=331412
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

asumma66061
Offline
Joined: 2007-04-12
Points: 0

I set a break point in the IndexedImage constructors and neither get hit for us. I don't think the performance issue is due to having an indexedImage.

Performance on S60/N95 is still poor - slower than S40.

A couple related threads:
http://forums.java.net/jive/thread.jspa?messageID=326393
http://forums.java.net/jive/thread.jspa?messageID=330377

Any other suggestions Chen?

Chen Fishbein

Hi,
I admit we had performance issues in S60 in the past, but I think they
were resolved.
Does the UIDemo preforms well on N95 for you? or are you experiencing
this with your own app only?
If this occurs only in your app can you send a sample code that
reproduce the latency.

Thanks,
Chen

lwuit-users@mobileandembedded.org wrote:
> I set a break point in the IndexedImage constructors and neither get hit for us. I don't think the performance issue is due to having an indexedImage.
>
> Performance on S60/N95 is still poor - slower than S40.
>
> A couple related threads:
> http://forums.java.net/jive/thread.jspa?messageID=326393
> http://forums.java.net/jive/thread.jspa?messageID=330377
>
> Any other suggestions Chen?
> [Message sent by forum member 'asumma66061' (asumma66061)]
>
> http://forums.java.net/jive/thread.jspa?messageID=331567
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

Chen Fishbein

Hi,
Would you mind run a small performance test for us and post the results.
Use the same image once stored in a resource file(marked as 'RGB') and
once loaded from jar, make sure the image is in the screen bounds.

Thanks

class MyPerformanceTest extends Form {
private Image resImage;
private Image physicalImage;
MyPerformanceTest() {
try {
resImage = Resources.open("/resource.res");
physicalImage = Image.create("/img.png");
if(resImage.getHeight() != physicalImage.getHeight() ||
resImage.getWidth() != physicalImage.getWidth() ||
resImage.getHeight()) {
System.out.println("FAIL!!!: height must be identical!");
}
registerAnimated(this);
} catch(Exception err) {
err.printStackTrace();
}
}
public boolean animate() {
return true;
}
public void paintBackground(Graphics g) {}
public void paint(Graphics g) {
long t = System.currentTimemillis();
for(int iter = 0 ; iter < 1000 ; iter++) {
g.drawImage(0, 0, resImage);
}
long d1 = System.currentTimemillis() - t;
t = System.currentTimemillis();
for(int iter = 0 ; iter < 1000 ; iter++) {
g.drawImage(0, 0, physicalImage);
}
long d2 = System.currentTimemillis() - t;
System.out.println("d1: " + d1 + " d2: " + d2);
}
}

Chen Fishbein wrote:
> Hi,
> I admit we had performance issues in S60 in the past, but I think they
> were resolved.
> Does the UIDemo preforms well on N95 for you? or are you experiencing
> this with your own app only?
> If this occurs only in your app can you send a sample code that
> reproduce the latency.
>
> Thanks,
> Chen
>
>
> lwuit-users@mobileandembedded.org wrote:
>> I set a break point in the IndexedImage constructors and neither get
>> hit for us. I don't think the performance issue is due to having an
>> indexedImage.
>>
>> Performance on S60/N95 is still poor - slower than S40.
>> A couple related threads:
>> http://forums.java.net/jive/thread.jspa?messageID=326393
>> http://forums.java.net/jive/thread.jspa?messageID=330377
>>
>> Any other suggestions Chen?
>> [Message sent by forum member 'asumma66061' (asumma66061)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=331567
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
[att1.html]

asumma66061
Offline
Joined: 2007-04-12
Points: 0

I loaded up the December drop of the demo on a N95 and a SE Z750i. Sitting them side by side for comparisons the SE is approx. twice as fast in the few actions I tried:

*press menu from main screen - about 1.5 seconds on N95, SE is sub-second.

*choose fonts menu item - about 1 second on N95, sub-second SE (roughtly twice as fast). May be interesting to note that the redrawing of the button pressed down is nearly instantaneous, but the new screen doesn't show for another second.

*choose buttons menu item - about 1 second on N95, sub-second on SE (roughly twice as fast). Same note about button press vs. screen display.

*choose back menu item from buttons - quicker than entering buttons for sure but N95 still noticably and consistently slower than SEz750i

Chen Fishbein

Hi,
There is a big difference saying lwuit is slow on S60 or saying SE
devices preforms better then S60.
SE java VM is much faster then the symbian brother, it is not something
lwuit can resolve.
We have done in the past 1/2 year tremendous performance updates to the
framework, and we think the performance is reasonable and satisfying.

Regards,
Chen

lwuit-users@mobileandembedded.org wrote:
> I loaded up the December drop of the demo on a N95 and a SE Z750i. Sitting them side by side for comparisons the SE is approx. twice as fast in the few actions I tried:
>
> *press menu from main screen - about 1.5 seconds on N95, SE is sub-second.
>
> *choose fonts menu item - about 1 second on N95, sub-second SE (roughtly twice as fast). May be interesting to note that the redrawing of the button pressed down is nearly instantaneous, but the new screen doesn't show for another second.
>
> *choose buttons menu item - about 1 second on N95, sub-second on SE (roughly twice as fast). Same note about button press vs. screen display.
>
> *choose back menu item from buttons - quicker than entering buttons for sure but N95 still noticably and consistently slower than SEz750i
> [Message sent by forum member 'asumma66061' (asumma66061)]
>
> http://forums.java.net/jive/thread.jspa?messageID=331594
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

signal3

Yeah, out of curiosity I ran the test you suggested too Chen. I needed to
modify the form a bit to get it to compile but I'm pretty sure it is close
to what you intended (see attached source code).

The image I used was a 16x16 32bpp rgb/alpha png (actually my application's
icon). The image does include semi-transparent areas. I ran the test 6
times on each of 6 different phones (unfortunatley none are s40 devices). I
haven't calculated any standard deviations or confidence intervals... this
is left as an exercise to the reader ;-)

Interestingly, the SE k550i seemed to perform the best... but this is a
rather specific test. We all now how useful benchmarks are... they really
should be taken with a grain of salt. Indeed, the SE performs rather well
on my app overall (actually the LG KU380 is probably the fastest in terms of
FPS). But, we have other factors to consider too, e.g. the differences in
screen size; the Nokias I have are 320x240 devices, the SE & LG are closer
to 176x220, same for SGH-L760 I think.

My real gripe isn't so much with speed, but with the vast differences in
rendering artifacts produced by each M3G implementation. Too bad LWUIT
can't do anything about this either! My nokia 6120c draws quite a beautiful
image at reasonable frame rates... and, of the 6 phones, the sony k550i
produces BY FAR the ugliest image.

For example, the 6120c can draw a fantastically smooth gradient given the
number of color supported by the display, all the other phones experience
rather horrible banding and encourage me to create a dithered gradient,
ugh. Also, the sony k550i (AFAIK) does not support bilinear filtering. Of
course, I'm not 100% sure of this though... mostly because it creates so
many artifacts on my textured quads (even after perspective correction) I
can hardly tell if any filtering is working at all.

In terms of price to overall-performance, I think the 6120c kills the
competition (at least of the 6 phones I use for testing). Just my opinion
of course. It's a bit more expensive too... as they say, you get what you
pay for.

Anyway... you can look at the attached spreadsheet if you want. Ultimately,
I agree and I wouldn't call any of the phones performances "crazy slow"
(even the ancient e680i).

Best wishes,
Dino

On Thu, Feb 12, 2009 at 11:54 AM, Chen Fishbein wrote:

> Hi,
> There is a big difference saying lwuit is slow on S60 or saying SE devices
> preforms better then S60.
> SE java VM is much faster then the symbian brother, it is not something
> lwuit can resolve.
> We have done in the past 1/2 year tremendous performance updates to the
> framework, and we think the performance is reasonable and satisfying.
>
> Regards,
> Chen
>
>
> lwuit-users@mobileandembedded.org wrote:
>
>> I loaded up the December drop of the demo on a N95 and a SE Z750i.
>> Sitting them side by side for comparisons the SE is approx. twice as fast
>> in the few actions I tried:
>>
>> *press menu from main screen - about 1.5 seconds on N95, SE is sub-second.
>>
>> *choose fonts menu item - about 1 second on N95, sub-second SE (roughtly
>> twice as fast). May be interesting to note that the redrawing of the button
>> pressed down is nearly instantaneous, but the new screen doesn't show for
>> another second.
>>
>> *choose buttons menu item - about 1 second on N95, sub-second on SE
>> (roughly twice as fast). Same note about button press vs. screen display.
>>
>> *choose back menu item from buttons - quicker than entering buttons for
>> sure but N95 still noticably and consistently slower than SEz750i
>> [Message sent by forum member 'asumma66061' (asumma66061)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=331594
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
[att1.html]
[timings.ods]
[MyPerformanceTest.java]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

lreyero
Offline
Joined: 2009-02-05
Points: 0

It seems the performance issue depends on some image properties.
By changing slightly the image, I was able to get great performance (30+ frames/sec). Fast and slow pictures are both 24 bit PNG, but tweaking the transparency a little bit changed everything.

gruelfin
Offline
Joined: 2010-03-11
Points: 0

hey i have a probably related problem: i have ~50 partly transparent images in the resource file and the app takes about 20 seconds to start, although i load only 5 images at startup. can you please tell me what you did to improve the performance? i search for a solution since days!

or if anyone else knows something, please tell me!

greetings!

asumma66061
Offline
Joined: 2007-04-12
Points: 0

Can you provide any guidance on the 'tweaking' - I would love to find a way to make N95 usable - it is way slow.

Arnau Vàzquez

Yes, please, can you explain your solution to this problem? We're also
using these kind of images and the application is quite slow, so it
might help us.

Thanks in advance,
Arnau

En/na lwuit-users@mobileandembedded.org ha escrit:
> Can you provide any guidance on the 'tweaking' - I would love to find a way to make N95 usable - it is way slow.
> [Message sent by forum member 'asumma66061' (asumma66061)]
>
> http://forums.java.net/jive/thread.jspa?messageID=330692
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net