Skip to main content

J2ME Help required (URGENT !!!)

7 replies [Last post]
mobeenkhan
Offline
Joined: 2007-07-24
Points: 0

Hello everyone,
Well I'm a newbie to this J2ME thing, I am working on a project right now which requires me to develop an application for my mobile phone Sony Ericsson W810i. This application accesses the on board camera and take images after every 1 sec and keep on saving the last 2 images in 2 different files or buffers. Once the images are obtained, Sobel Filter (Image processing) is applied on it for edge detection. Can anyone please help me with this all, I am really desperate and time is running out.
At the moment, I found this code on Sony Ericsson Developer forums which works perfectly fine with my W810i, the link to the code is as follows,

http://developer.sonyericsson.com/site/global/techsupport/tipstrickscode...

Well this takes one image and shows it on the canvas, however I am still trying to figure out a way to remove the question it asks whenever i press the button SNAPSHOT, it asks "Do u want to allow the application to access Camera?", is there a way to remove this as well. Please let me know.
Last thing, the getSnapshot is used as vc.getSnapshot(null), i read and changed it to vc.getSnapshot("encoding=jpeg");
This works fine with my mobile as well, but now i cant find any help on how to apply image processing on this encoded jpeg !!! Well please reply, as much as u know, u dun have to answer all the questions, any information regarding this is helpful, I'll be extremely grateful !!!

Thanks a lot,
Regards,
Mubin Khan

Reply viewing options

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

Robin,

I've had the following from Tomi Aarnio the M3G spec lead at Nokia that
I've been asked to pass on:

"I can confirm that there is indeed a VM integration issue in S60 3rd
edition devices that causes memory leaks when using M3G. S40 and the
more recent versions of S60 (i.e. from 3rd Ed Feature Pack 1 onwards)
are not affected."

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Web: www.superscape.com
Terms and conditions for email usage: www.superscape.com/email/

> -----Original Message-----
> From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM]
> On Behalf Of Michael Steliaros
> Sent: 07 August 2007 19:57
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?
>
> Robin,
>
> I don't see this as a limitation of the M3G spec. It is purely a
VM/JSR
> integration issue. I don't think that it should be down to the app
> developer to explicitly manage resources in this way; this is Java
after
> all :)
>
> Having said that, all VMs I've seen do support (native) finalizers,
and
> this is typically how native resources are managed.
>
> I do not pretend to understand why SE & Nokia M3G implementations
behave
> in the way you describe, especially as this is done on load(). I can
> only guess that it is related to Image2Ds and texture memory as no
> rendering is taking place.
>
> In most M3G implementations GL calls would be handled by native code.
If
> the OpenGL driver decides it's run out of memory and you are deep in
the
> middle of a load, you could theoretically call gc() from the native
side
> and hope that some garbage collected objects release enough resources
in
> their finalizers to try again. In some cases gc() would have to be
> called multiple times, so when do you stop? Also although initiating a
> gc() from the native side is possible, it does not mean that the OEM
> will permit it... So I can certainly sympathise if the M3G
> implementation just gives up and throws OutOfMemory, although
admittedly
> it is not ideal.
>
> Out of curiosity, does the behaviour go away if you explicitly call
gc()
> from your loop or is this an actual leak?
>
> Mike
> --
> Dr. Michael K. Steliaros
> Chief Engineer, Superscape Ltd
> Terms and conditions for email usage: www.superscape.com/email/
>
> > -----Original Message-----
> > From: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM]
> > On Behalf Of Robin Chaddock
> > Sent: 07 August 2007 10:31
> > To: KVM-INTEREST@JAVA.SUN.COM
> > Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?
> >
> > > Which additional resources could benefit from explicit cleanup
> methods?
> >
> > Every jsr184 class that could perceivably have finite native
resources
> > associated with it. (such as accelerated graphics memory)
> >
> > Now the number of handsets with hardware acceleration support is
> > increasing
> > I am curious how manufacturers are addressing this innate limitation
> of
> > the
> > jsr184 api.
> >
> > For example:-
> >
> > [code]
> > while(true) {
> > Loader.load("any.m3g");
> > }[/code]
> >
> > Will cause a whole host of recent Nokia and SonyEricsson handsets to
> crash
> > with an OutOfMemoryError (though the heap is far from full), after a
> > relatively small number of iterations.
> > It doesn't appear to be memory leaks within the Loader class either,
> > replacing the use of the native m3g Loader with a java
implementation
> > (that
> > falls back upon api calls) does not circumvent the crashes on most
> > handsets - implying that programatic construction of jsr184 objects
> also
> > leaks some kind of finite system resource.
> >
> > Given that Nokia was the Specification lead for jsr184, it is a
little
> > disheartening to find most of their implementations are
fundamentally
> > broken
> > in such a way.
> >
> > ----- Original Message -----
> > From: "Joe Bowbeer"
> > To:
> > Sent: Tuesday, August 07, 2007 2:46 AM
> > Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?
> >
> >
> > > On 8/3/07, Robin Chaddock wrote:
> > >> I'm curious how the jsr184 api is designed to support underlying
> > hardware
> > >> acceleration when built upon the cldc1.1 platform.
> > >>
> > >> a) CLDC implementations are not required to provide finalizer
> support;
> > so
> > >> the platform cannot guarantee garbage collection of Java objects
> will
> > >> trigger the release of their native resources)
> > >> b) Very few of the Java classes (infact only Graphics3D?) have
> > provision
> > >> for
> > >> explicit dispose()/destroy()/release() methods.
> > >>
> > >> These 2 limitations when coupled together make me think that
> providing
> > a
> > >> reliable implementation of the jsr184 api when built upon a
> platform
> > that
> > >> supports only the minimal feature set for CLDC1.1 compatibility
is
> > >> fundamentally impossible.
> > >>
> > >> Obviously if the CLDC implementation went beyond it's needed
> minimum
> > >> specs,
> > >> such as offering an under-the-hood means of performing object
> > >> finalization,
> > >> or made the garbage collector aware of native graphics resources
-
> then
> > >> implementing a hardware accelerated jsr184 api would not be so
> > difficult.
> > >>
> > >> This observation appears to approximate reality, as a vast number
> of
> > >> handsets that 'support' jsr184 do so in very hap-hazard way -
> typically
> > >> leaking native resources from every proverbial orifice. (Nokias
> tend to
> > >> be
> > >> the primarily culprits, but SE and other manufacturers have their
> fair
> > >> share
> > >> of broken implementations too)
> > >>
> > >
> > > Java's finalize method has been much maligned in Java SE so I find
> it
> > > curious that you're advocating it for Java ME. I view finalize as
a
> > > last ditch cleanup hook that should be avoided in practice (by
> > > explicit cleanup).
> > >
> > > Which additional resources could benefit from explicit cleanup
> methods?
> > >
> > > MIDlets have a few finalize-like notifications already, such as
> > > Canvas.hideNotify(), MIDlet.pauseApp() and MIDlet.destroyApp().
> > >
> > > Is it possible for the cleanup methods to hook into one of these?
> > >
> > > If so, freeing the HW-acc resources on hideNotify and reacquiring
> them
> > > on showNotify is the most conservative approach.
> > >
> > > --
> > > Joe Bowbeer
> > >
> > >
> >
>
========================================================================
> ==
> > =
> > > 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".
>
>
========================================================================
==
> =
> 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".

===========================================================================
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".

Michael Steliaros

Robin,

I don't see this as a limitation of the M3G spec. It is purely a VM/JSR
integration issue. I don't think that it should be down to the app
developer to explicitly manage resources in this way; this is Java after
all :)

Having said that, all VMs I've seen do support (native) finalizers, and
this is typically how native resources are managed.

I do not pretend to understand why SE & Nokia M3G implementations behave
in the way you describe, especially as this is done on load(). I can
only guess that it is related to Image2Ds and texture memory as no
rendering is taking place.

In most M3G implementations GL calls would be handled by native code. If
the OpenGL driver decides it's run out of memory and you are deep in the
middle of a load, you could theoretically call gc() from the native side
and hope that some garbage collected objects release enough resources in
their finalizers to try again. In some cases gc() would have to be
called multiple times, so when do you stop? Also although initiating a
gc() from the native side is possible, it does not mean that the OEM
will permit it... So I can certainly sympathise if the M3G
implementation just gives up and throws OutOfMemory, although admittedly
it is not ideal.

Out of curiosity, does the behaviour go away if you explicitly call gc()
from your loop or is this an actual leak?

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Terms and conditions for email usage: www.superscape.com/email/

> -----Original Message-----
> From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM]
> On Behalf Of Robin Chaddock
> Sent: 07 August 2007 10:31
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?
>
> > Which additional resources could benefit from explicit cleanup
methods?
>
> Every jsr184 class that could perceivably have finite native resources
> associated with it. (such as accelerated graphics memory)
>
> Now the number of handsets with hardware acceleration support is
> increasing
> I am curious how manufacturers are addressing this innate limitation
of
> the
> jsr184 api.
>
> For example:-
>
> [code]
> while(true) {
> Loader.load("any.m3g");
> }[/code]
>
> Will cause a whole host of recent Nokia and SonyEricsson handsets to
crash
> with an OutOfMemoryError (though the heap is far from full), after a
> relatively small number of iterations.
> It doesn't appear to be memory leaks within the Loader class either,
> replacing the use of the native m3g Loader with a java implementation
> (that
> falls back upon api calls) does not circumvent the crashes on most
> handsets - implying that programatic construction of jsr184 objects
also
> leaks some kind of finite system resource.
>
> Given that Nokia was the Specification lead for jsr184, it is a little
> disheartening to find most of their implementations are fundamentally
> broken
> in such a way.
>
> ----- Original Message -----
> From: "Joe Bowbeer"
> To:
> Sent: Tuesday, August 07, 2007 2:46 AM
> Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?
>
>
> > On 8/3/07, Robin Chaddock wrote:
> >> I'm curious how the jsr184 api is designed to support underlying
> hardware
> >> acceleration when built upon the cldc1.1 platform.
> >>
> >> a) CLDC implementations are not required to provide finalizer
support;
> so
> >> the platform cannot guarantee garbage collection of Java objects
will
> >> trigger the release of their native resources)
> >> b) Very few of the Java classes (infact only Graphics3D?) have
> provision
> >> for
> >> explicit dispose()/destroy()/release() methods.
> >>
> >> These 2 limitations when coupled together make me think that
providing
> a
> >> reliable implementation of the jsr184 api when built upon a
platform
> that
> >> supports only the minimal feature set for CLDC1.1 compatibility is
> >> fundamentally impossible.
> >>
> >> Obviously if the CLDC implementation went beyond it's needed
minimum
> >> specs,
> >> such as offering an under-the-hood means of performing object
> >> finalization,
> >> or made the garbage collector aware of native graphics resources -
then
> >> implementing a hardware accelerated jsr184 api would not be so
> difficult.
> >>
> >> This observation appears to approximate reality, as a vast number
of
> >> handsets that 'support' jsr184 do so in very hap-hazard way -
typically
> >> leaking native resources from every proverbial orifice. (Nokias
tend to
> >> be
> >> the primarily culprits, but SE and other manufacturers have their
fair
> >> share
> >> of broken implementations too)
> >>
> >
> > Java's finalize method has been much maligned in Java SE so I find
it
> > curious that you're advocating it for Java ME. I view finalize as a
> > last ditch cleanup hook that should be avoided in practice (by
> > explicit cleanup).
> >
> > Which additional resources could benefit from explicit cleanup
methods?
> >
> > MIDlets have a few finalize-like notifications already, such as
> > Canvas.hideNotify(), MIDlet.pauseApp() and MIDlet.destroyApp().
> >
> > Is it possible for the cleanup methods to hook into one of these?
> >
> > If so, freeing the HW-acc resources on hideNotify and reacquiring
them
> > on showNotify is the most conservative approach.
> >
> > --
> > Joe Bowbeer
> >
> >
>
========================================================================
==
> =
> > 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".

===========================================================================
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".

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Mike,

It's great to see ISVs and component vendors participate on the forums - Superscape is a key partner in the 3D space. I really appreciate you taking the time to get involved. This is a very valuable communication channel for developers and community members.

Thanks much!

-- Terrence

Terrence Barr
Evangelist, Java Mobile & Embedded Community
Sun Microsystems, Germany
www.mobileandembedded.org

terrencebarr
Offline
Joined: 2004-03-04
Points: 0
Robin Chaddock

I'm curious how the jsr184 api is designed to support underlying hardware
acceleration when built upon the cldc1.1 platform.

a) CLDC implementations are not required to provide finalizer support; so
the platform cannot guarantee garbage collection of Java objects will
trigger the release of their native resources)
b) Very few of the Java classes (infact only Graphics3D?) have provision for
explicit dispose()/destroy()/release() methods.

These 2 limitations when coupled together make me think that providing a
reliable implementation of the jsr184 api when built upon a platform that
supports only the minimal feature set for CLDC1.1 compatibility is
fundamentally impossible.

Obviously if the CLDC implementation went beyond it's needed minimum specs,
such as offering an under-the-hood means of performing object finalization,
or made the garbage collector aware of native graphics resources - then
implementing a hardware accelerated jsr184 api would not be so difficult.

This observation appears to approximate reality, as a vast number of
handsets that 'support' jsr184 do so in very hap-hazard way - typically
leaking native resources from every proverbial orifice. (Nokias tend to be
the primarily culprits, but SE and other manufacturers have their fair share
of broken implementations too)

________________________________________________________________________
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".

Joe Bowbeer

On 8/3/07, Robin Chaddock wrote:
> I'm curious how the jsr184 api is designed to support underlying hardware
> acceleration when built upon the cldc1.1 platform.
>
> a) CLDC implementations are not required to provide finalizer support; so
> the platform cannot guarantee garbage collection of Java objects will
> trigger the release of their native resources)
> b) Very few of the Java classes (infact only Graphics3D?) have provision for
> explicit dispose()/destroy()/release() methods.
>
> These 2 limitations when coupled together make me think that providing a
> reliable implementation of the jsr184 api when built upon a platform that
> supports only the minimal feature set for CLDC1.1 compatibility is
> fundamentally impossible.
>
> Obviously if the CLDC implementation went beyond it's needed minimum specs,
> such as offering an under-the-hood means of performing object finalization,
> or made the garbage collector aware of native graphics resources - then
> implementing a hardware accelerated jsr184 api would not be so difficult.
>
> This observation appears to approximate reality, as a vast number of
> handsets that 'support' jsr184 do so in very hap-hazard way - typically
> leaking native resources from every proverbial orifice. (Nokias tend to be
> the primarily culprits, but SE and other manufacturers have their fair share
> of broken implementations too)
>

Java's finalize method has been much maligned in Java SE so I find it
curious that you're advocating it for Java ME. I view finalize as a
last ditch cleanup hook that should be avoided in practice (by
explicit cleanup).

Which additional resources could benefit from explicit cleanup methods?

MIDlets have a few finalize-like notifications already, such as
Canvas.hideNotify(), MIDlet.pauseApp() and MIDlet.destroyApp().

Is it possible for the cleanup methods to hook into one of these?

If so, freeing the HW-acc resources on hideNotify and reacquiring them
on showNotify is the most conservative approach.

--
Joe Bowbeer

===========================================================================
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".

Robin Chaddock

> Which additional resources could benefit from explicit cleanup methods?

Every jsr184 class that could perceivably have finite native resources
associated with it. (such as accelerated graphics memory)

Now the number of handsets with hardware acceleration support is increasing
I am curious how manufacturers are addressing this innate limitation of the
jsr184 api.

For example:-

[code]
while(true) {
Loader.load("any.m3g");
}[/code]

Will cause a whole host of recent Nokia and SonyEricsson handsets to crash
with an OutOfMemoryError (though the heap is far from full), after a
relatively small number of iterations.
It doesn't appear to be memory leaks within the Loader class either,
replacing the use of the native m3g Loader with a java implementation (that
falls back upon api calls) does not circumvent the crashes on most
handsets - implying that programatic construction of jsr184 objects also
leaks some kind of finite system resource.

Given that Nokia was the Specification lead for jsr184, it is a little
disheartening to find most of their implementations are fundamentally broken
in such a way.

----- Original Message -----
From: "Joe Bowbeer"
To:
Sent: Tuesday, August 07, 2007 2:46 AM
Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?

> On 8/3/07, Robin Chaddock wrote:
>> I'm curious how the jsr184 api is designed to support underlying hardware
>> acceleration when built upon the cldc1.1 platform.
>>
>> a) CLDC implementations are not required to provide finalizer support; so
>> the platform cannot guarantee garbage collection of Java objects will
>> trigger the release of their native resources)
>> b) Very few of the Java classes (infact only Graphics3D?) have provision
>> for
>> explicit dispose()/destroy()/release() methods.
>>
>> These 2 limitations when coupled together make me think that providing a
>> reliable implementation of the jsr184 api when built upon a platform that
>> supports only the minimal feature set for CLDC1.1 compatibility is
>> fundamentally impossible.
>>
>> Obviously if the CLDC implementation went beyond it's needed minimum
>> specs,
>> such as offering an under-the-hood means of performing object
>> finalization,
>> or made the garbage collector aware of native graphics resources - then
>> implementing a hardware accelerated jsr184 api would not be so difficult.
>>
>> This observation appears to approximate reality, as a vast number of
>> handsets that 'support' jsr184 do so in very hap-hazard way - typically
>> leaking native resources from every proverbial orifice. (Nokias tend to
>> be
>> the primarily culprits, but SE and other manufacturers have their fair
>> share
>> of broken implementations too)
>>
>
> Java's finalize method has been much maligned in Java SE so I find it
> curious that you're advocating it for Java ME. I view finalize as a
> last ditch cleanup hook that should be avoided in practice (by
> explicit cleanup).
>
> Which additional resources could benefit from explicit cleanup methods?
>
> MIDlets have a few finalize-like notifications already, such as
> Canvas.hideNotify(), MIDlet.pauseApp() and MIDlet.destroyApp().
>
> Is it possible for the cleanup methods to hook into one of these?
>
> If so, freeing the HW-acc resources on hideNotify and reacquiring them
> on showNotify is the most conservative approach.
>
> --
> Joe Bowbeer
>
> ===========================================================================
> 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".