For QNX 6, Photon 2, we have AWT available. AFAIK, this level of os/photon
is only available for x86, not ppc (or any other platform). Our version of
AWT for Photon requires a wad of C code that should be able to compile
anywhere QNX 6, Photon 2 is available. You can actually download the x86
bit from www.embedded.oti.com; look for the “Personal Configuration”, along
with the runtimes for qnx/x86.
We can make AWT for any other platform (ppc,sh?,mips,etc) available as soon
there is a QNX 6 and Photon 2 that can run on that platform.
With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?
Good question.
Swing, well, we haven’t really stepped up to actually say we support Swing
yet. There are some bugs in our AWT we need to fix; and we don’t really
have a licensing story. Our VM, base class libs, and AWT are completely
‘independently developed’, and don’t require a Sun license for your
customers to use. We don’t have our own Swing though. It’s really too big
to be something that we would expect our customers to use, so we haven’t
embarked on the ‘independently developed’ path for Swing yet. So, to run it
at all, you’ll need to go to the Sun web site, and download it, and agree to
their license. And you want Swing 1.1.1 for JDK 1.1, not Swing for a JDK >
1.1. This is because the Swings for > JDK 1.1 (ie, >= JDK 1.2) require the
java2d APIs, which we also don’t support in our AWT (I’ll be kind and just
say it’s too damn big
.
For us Swing is a test-case, and not something we would recommend to
customers. For the moment, anyway.
Swing is quite large also. Both code size and ram usage. It requires AWT,
so take what I say next, and add a few more megabytes to code and ram usage.
Now to AWT. AWT is also unfortunately quite large. Both in terms of code
size and ram usage. Code size is something like ~2M of classes and a ~400K
…so. AWT was designed to be easy for programmers to use, as opposed to a
good performer and ram user. The lack of a threading model in AWT means
that we have to do lots of cross-threaded stuff under the covers. Typical
AWT applications depends on ‘finalization’ to clean up their garbage, which
causes lots of transient garbage, holding onto os resources like GCs,
images, etc longer than you should. There is also a built-in image caching
scheme that has no API, so basically a lot of your images get cached, even
if you just use them once and then never again.
It’s not something >I< would want to deploy on, unless I had lots of RAM
available. One of our customers is shipping with 64M RAM and 32M flash. Of
course it also completely depends on what you want to do with it.
Processor choice is largely orthogonal. Unless you are doing some fancy
image filtering stuff, or your own complex crunching, AWT performance will
scale like any other app. Customer above runs on a 300Mz MediaGX, and I
think the performance is perfectly acceptable.
If not AWT, what graphical interface would that be using?
Besides AWT, we also have a product called MicroView, which is a
bitmap-based UI toolkit. The use is to do panel/console-type displays. It
has some widgety things in it, but it’s really designed to do UIs that look
like a hardware surface, or do branding for your UI. It runs on a lot more
platforms that AWT does. No doubt this is what you saw, if it was running
the J9 VM.
We are going to have a few more UI options available in the next few months
…
In the meantime, visit www.embedded.oti.com for more info on what we are
shipping today …
–
“Alex” <acellarius@systems104.co.za> wrote in message
news:3AEF1BA1.EBF2DB30@systems104.co.za…
I saw a graphical demo running on the RPX Lite red boxes in
the QNX training room (I believe running the OTI Java).
(Runs a mockup of a fancy radio UI)
If not AWT, what graphical interface would that be using?
If one had to have AWT (existing application), any idea when
this would be available?
With AWT, what level of processor would one be needing
(in the x86 world)? And with Swing?
Thanks in advance for the info
Patrick Mueller wrote:
VAME uses a proprietary UI layer (not AWT) which is not yet shipping on
Photon. Trust me, you wouldn’t want to run an IDE under AWT … Swing
maybe, with the current crop of extremely fast processors, but you’d
still
have those niggling non-platform-ish behaviours that would bug the crap
out
of you.