Re: GUI using the Framebuffer API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hi Rutger,

Am Freitag, den 03.09.2010, 21:01 +0200 schrieb Rutger Hofman:
> We chose a slightly convoluted solution: use Java for the GUI -- we 
> already had a Java app to do GUI stuff. I adapted and upgraded MiKa 
> (formerly Wonka) to suit my needs. It has an AWT implementation that 
> integrates quite nicely w/ the eCos framebuffer, and it has itself 
> implemented fonts, shapes, widgets, etc etc. This MiKa JVM is spawned 
> from the eCos C application. Like your microwindows port, the JVM seems 
> to need a network stack.

All this sounds quite fancy ;) But I somewhat start to like this
approach. Writing the Java-App and let it run on the target as well as
on any computer on the network. Doing the GUI just once.

As it's currently only a project in my free-time (well, lightly coupled
to my work...), the rough edges won't be a problem at all.

The network-stack isn't a problem at all. My application needs
networking anyway.


> Needless to say, this will make your application memory- and CPU-hungry 
> (interpreter without JIT compiler, bunches of threads for small tasks 
> like timeouts etc).

Well yes, I didn't expect anything else ;) I've got an ARM926 running at
200 MHz with at least 8MB of (external) SDRAM, so I guess this will be
enough for first tests.

I don't know if I'll use it for my free-time project, but I'd definitely
like to try it out. Seems to be quite a good stress-tester for my new
HAL on the target CPU!

And if I'm gonna "lick blood" in the project, I'll see what I can feed
back to your efforts!


Manuel Borchers

eMail: manuel@xxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part

[Index of Archives]     [Linux Embedded]     [U-Boot V2]     [Linux Kernel]     [Linux MIPS]     [Linux ARM]     [Linux for the Blind]     [Linux Resources]     [Photo]     [Yosemite]     [ISDN Cause Codes]     [eCos Home]

  Powered by Linux