Skip to main content

Graphics.drawImage() vs Graphics.drawRGB()

7 replies [Last post]
Anonymous

Hi,

I am (finally) looking to ditch support for MIDP1.0 only handsets and
am looking at the extra functionality / optimisations that I can gain
from this.

Interested in the Graphics.drawRGB() method. Does anyone have any
info (however vague) about how practical this is to use in 'real
world' situations and how fast it tends to be compared to
Graphics.drawImage()? The documentation says 'The mapping from ARGB
values to the device-dependent pixels is platform-specific and may
require significant computation' which sounds pretty ominous!

Any feedback appreciated...

cheers

====

James Closs, Director, bitBull Ltd

http://www.bitbull.com

07771 991171

====

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Robin Chaddock

From my porting experience it's much the same story.

Typical things that behave inconsistently due to bugs in rendering pipeline are :

1) transparency - some handsets lose it when manipulating rgb int[]'s - most notably the NokiaN80 and some of it's relatives.
2) transformations - The pixel format of Images sometimes effects the rendering pipeline used, leading to different results when applying transforms. Some handsets handle images sourced from int[]'s via pipelines & pixel formats that are seldom used.
3) clipping - behaviour of both screen clip & user clip have been known to vary according to the Images underlying pixel format. (early Sharps, some Samsungs etc etc)

drawRegion has much the same inconsistencies:
A few handsets don't implement it (SamsaungE710 and compats),
some others do clipping incorrectly when using it, or don't support some/all of the rotation types.
However, you can always fall back onto clipRect/drawImage/setClip if need be.

It sounds like you might not be using it correctly on the k800, as I'm fairly sure drawRegion is bug free on that handset.

----- Original Message -----
From: James Closs
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Tuesday, January 15, 2008 3:39 PM
Subject: Re: Graphics.drawImage() vs Graphics.drawRGB()

Unimplemented on some handsets, buggy on many others, slow on some.

It's broken on more handsets than it is slow on.

Groan - and there was me getting all excited. Thanks very much though.

What about...

Graphics.drawRegion()
Image.createRGBImage()
Image.getRGB()

?

Last two seem to be OK for me on the SEk800, drawRegion seems to be doing strange things but it could be my code...

cheers

====

James Closs, Director, bitBull Ltd

http://www.bitbull.com

07771 991171

====

=========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff KVM-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help".

________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

captainfreedom
Offline
Joined: 2007-01-10
Points: 0

> 1) transparency - some handsets lose it when manipulating rgb int[]'s - most notably the NokiaN80 and some of it's relatives.

What function specifically?
I use createRGBImage with devices in the same family and have no problems with transparancy.

marcin_milczarz
Offline
Joined: 2008-02-22
Points: 0

I do not use nokia phones, but experienced such problems on samsung sgh phones.
Here is link to my post about it:
http://forum.java.sun.com/thread.jspa?forumID=76&threadID=5230953
(btw: any sugestions will be welcome :) )

Message was edited by: marcin_milczarz

Robin Chaddock

Unimplemented on some handsets, buggy on many others, slow on some.

It's broken on more handsets than it is slow on.

----- Original Message -----
From: James Closs
To: KVM-INTEREST@JAVA.SUN.COM
Sent: Tuesday, January 15, 2008 2:38 PM
Subject: Graphics.drawImage() vs Graphics.drawRGB()

Hi,

I am (finally) looking to ditch support for MIDP1.0 only handsets and
am looking at the extra functionality / optimisations that I can gain
from this.

Interested in the Graphics.drawRGB() method. Does anyone have any
info (however vague) about how practical this is to use in 'real
world' situations and how fast it tends to be compared to
Graphics.drawImage()? The documentation says 'The mapping from ARGB
values to the device-dependent pixels is platform-specific and may
require significant computation' which sounds pretty ominous!

Any feedback appreciated...

cheers

====

James Closs, Director, bitBull Ltd

http://www.bitbull.com

07771 991171

====

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

James Closs

> Unimplemented on some handsets, buggy on many others, slow on some.
>
> It's broken on more handsets than it is slow on.

Groan - and there was me getting all excited. Thanks very much though.

What about...

Graphics.drawRegion()
Image.createRGBImage()
Image.getRGB()

?

Last two seem to be OK for me on the SEk800, drawRegion seems to be
doing strange things but it could be my code...

cheers

====

James Closs, Director, bitBull Ltd

http://www.bitbull.com

07771 991171

====

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Elliot Sumner

Graphics.drawRegion()

Ok, if you don't use the rotation facilities.
But clipRect/drawImage for MIDP 1.0 generally works just as well...

Image.createRGBImage()

Again, ok from what I have seen. Can be very slow if not done right.

Image.getRGB()

Seen some issues with memory leaks.

I recommend not using the RGB specific code on a per frame basis, but
generating the required assets
at load time and using standard drawImage() calls.

I generally work around this by loading the raw PNG bytes and
adding/modifying chunks if I need to
change the pallete or image alpha.

James Closs wrote:
>> Unimplemented on some handsets, buggy on many others, slow on some.
>>
>> It's broken on more handsets than it is slow on.
>
> Groan - and there was me getting all excited. Thanks very much though.
>
> What about...
>
> Graphics.drawRegion()
> Image.createRGBImage()
> Image.getRGB()
>
> ?
>
> Last two seem to be OK for me on the SEk800, drawRegion seems to be
> doing strange things but it could be my code...
>
> cheers
>
> ====
>
>
> James Closs, Director, bitBull Ltd
>
>
> http://www.bitbull.com
>
>
> 07771 991171
>
>
> ====
>
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

--
Elliot Daniel Sumner
Mobile Developer
Emote Games Ltd.
telephone : +44 (0)151 224 7767
mobile : +44 (0)777 324 0527
skype : elliot.sumner
email : elliots@emotegames.co.uk

--
Emote Games Ltd. is a company registered in England and Wales No.
05504381. Registered office: 27 Old Haymarket, Manchester Street,
Liverpool, Merseyside L1 6ER http://www.emotegames.co.uk/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

James Closs

Thanks Eliot and Robin for your input. I'm not really worried about
supporting some of the much older handsets. Motorola v525 is about as
old / low spec as I go now.

I seem to have drawRegion() working OK on the k800 now, was just
thought it would be a bit more elegant (and possibly faster) than the
old clipRect/drawImage scenario which often involves a lot of method
calls to remember and reset the original clip. Not really worried
about transformations.

I'm particularly interested in the RGB stuff for creating semi-
mutable transparent images, ie create a mutable image / do some
drawing / make an immutable image from it and add transparency. This
will be very useful particularly when rendering graphical fonts and
the like and seems to work OK so far, thought it would probably be
too much of a 'sledghammer' approach to do every frame. Shame about
Graphics.drawRBG(), that would have been cool, too good to be true I
guess...

Haven't tried messing about with raw PNG data but it's probably
something I should look into.

cheers

> I recommend not using the RGB specific code on a per frame basis,
> but generating the required assets
> at load time and using standard drawImage() calls.
>
> I generally work around this by loading the raw PNG bytes and
> adding/modifying chunks if I need to
> change the pallete or image alpha.

====

James Closs, Director, bitBull Ltd

http://www.bitbull.com

07771 991171

====

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]