Writing my first post to the list got me fired up and I did a bit more research.
> 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.
Thanks for the link.
> 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.
Looks like this is the only way to do what I want. I am a bit doubtful I will be able to build a
decent engine that will allow enough space/speed for the main app to run against, but I am going to
give it a whirl. My current thought on the matter leads me to think that I can write a gif->meta
file converter in c/c++ which will analyse an image and generate the fewest possible calls to the
available api(drawline,rect,poly). I can then generate byte streams which will be read in to render
a custom canvas reproducing an original image. Whether it will prove real world practical is yet to
be seen, but I'm not optimistic. Quite an ugly hack to a fairly common task.
> 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.
I downloaded a class decompiler and opened up the DoJa ui package. There are some interesting
factors, the most unfortunate of which is that all of the implementation of the publicly available
interface are private. For example, the Image object is instantiated in the ImageImpl class which
simply sends a byte array to a native call named "createImage" aptly enough. The fact that the
function that I need is built natively into the KVM and is sitting right under my nose but
inaccessable due to the almighty java class hierarchy is extremely annoying. The same is true for
every other class in the UI package one might want low level access to. I tried a few things to see
if I could fake it, but even when I was able to compile an override of the Image class I wasn't able
to access the native createImage method.
As far as writing bytecode, well, I have written enough assembly to know that bytecode is not a
problem. The problem is that bytecode is not assembly. The java->class compilation is not a mirror
of the c->asm compilation. I did not know enough about bytecode when I wrote my first post, but
after a few hours of tinkering I am disappointed. From what I have been able to disassemble it
doesn't look like there is much room for optimization. I could be wrong, but it looks like bytecode
is just a binary representation of a java statement. Again, that is quite different from the c->asm
step, so unlike assembly, I don't think bytecode will provide much optimization.
I'm still looking for a better solution, but there simply may not be one. I thank everyone who
responds and will make an effort to contribute more than just questions in the future.
Douglas MacDougall
GNA Inc. Japan
[ Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/ ]
Received on Sun Dec 2 20:35:12 2001