Hello,
Graphics speed on the various i-mode Java phones differs. You will find the
best performance out of the S503i series. From what you have been sugesting
for using assembly or c level function calls, you migth as well just
restrict your application to one phone instead of trying to write optimised
assembly/c code for each possible phone that has their own implementations.
The security implications of letting a third party have such low level
access are too much to debate here.
If you want to find info on the KVM and write your own and convince a phone
manufacturer to use it go to www.javasoft.com and look around for the CLDC
package (not MIDP). Down load the CLDC package and you will get c code for
a reference KVM and documentation.
> What are the
>limitations of the DoJa model, and can they be overridden? Is there any way
to build your >own
>instance of an Image object without using MediaManager?
Don't use the Image object, you have to use the MediaManager to load an
Image.
Roll your own images with the lots of calls to the provided Graphics
function, such as draw line, and use that on your custom Canvas. Using the
Graphics lock and unlock Double Buffering function may help improve your
applications performance too.
>I haven't had enough time to
>research this field thoroughly but tentatively I can only find two
solutions. One is that >there is a
>way to override the DoJa supplied classes and get direct access to the KVM
calls to the >native
>firmware. The other less effective method would be to bypass the
.java->.class step and just write
>bytecode using a hex editor. By optimizing the bytecode to do what would
likely generate compiler
>errors, you may be able to speed up the code enough to actually render
separate tiles.
Your first solution is not possible, because most of the classes are final
and thus cannot be subclassed.
If you think you can write your own bytecode that compiles and passes the
preverifier that is fast go for it. It might work, but I have my
reservations.
Regards,
Zev
--- Original Message---
From: "Douglas MacDougall" <mac@gnajp.com>
Subject: Doja limitations
Date: Fri, 30 Nov 2001 21:40:35 +0900
Hello,
I am an American CTO of a Japanese corporation. I've read a lot of the
archives but this is my first
time posting. We develop web applications, but have just begun probing the
iAppli market. I am
trying to develop a tile based rendering engine, but cannot find any
tolerable way to do this with
the Doja Graphics class. The project requires that the user download lots of
scenes and I have
developed a method to reduce the packet transfer to the bare minimum, but
there is no way to render
the graphical data except using Graphics.drawLine(). I read the specs on the
KVM and it basically
states that the DoJa layer provides an interface to the KVM which implements
the native calls.
What I need is a lower level access into the phone API. From what I have
read in the public docs
this is not possible, but perhaps someone here has hacked in deeper. I
haven't had enough time to
research this field thoroughly but tentatively I can only find two
solutions. One is that there is a
way to override the DoJa supplied classes and get direct access to the KVM
calls to the native
firmware. The other less effective method would be to bypass the
.java->.class step and just write
bytecode using a hex editor. By optimizing the bytecode to do what would
likely generate compiler
errors, you may be able to speed up the code enough to actually render
separate tiles.
What I want to be able to do is to generate images from within the iAppli by
decoding tile data read
from bitstreams. I can do this on any hardware that supplies a decent
graphics API, but with DoJa I
so far have only been able to draw an image which is read from a file
(either resource:// or
http://). This is highly inefficient and completely unacceptable for the
level of application I am
attempting to build. By the time the maps, tiling and sprites are loaded and
rendered there won't be
enough app memory space to actually do anything with the graphics.
I am not a fan of Java and never use it in any other development project,
but as far as I can tell,
none of the phones provide a native API. Why the phone makers don't use
assembly or at least a tight
c api is completely beyond me except that Java carries marketing weight. The
whole "standards" theme
is a joke considering the fact that near every phone has different size,
color, memory and native
calls. In any event, that debate is a lost cause. Perhaps some of you who
have more Java experience
know of ways to take it to the limits?
If there is anyone out there developing bleeding edge iAppli's please
respond. What are the
limitations of the DoJa model, and can they be overridden? Is there any way
to build your own
instance of an Image object without using MediaManager? Does anyone know
where I can get the KVM
specs, I searched around sun.com but to no avail. Obviously the hardware
makers have this info, so
it must be floating around somewhere. I plan to email Sun on this one, but
if anyone here has them,
I would love a peak.
Douglas MacDougall
GNA Inc. Japan
_______________________________________________________
[ Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/ ]
Received on Sun Dec 2 17:44:46 2001