On 12/29/05, Kent Sandvik <[EMAIL PROTECTED]> wrote: > On 12/29/05, Mike Emmel <[EMAIL PROTECTED]> wrote: > > First start with webkit in particular the port > > http://gtk-webcore.sourceforge.net/ > > > > Next you need to add in the SVG support from the main webkit > > repository that's what I plan to do next. > > My only worry are all the layers put in place, embedded systems will > for a long time be underpowered CPUs with little RAM, small > primary/secondary caches, if ARM rules little support for fast > floating point and so on... It's better to make the middle-layer as > lean as possible, and let the upper-level drawing functions call the > drawing primitives directly, if possible via a graphics driver -- > something that DirectFB makes it possible to do. > > For example, the Glib and Pango layers will add so much object and > other CPU-intensive code, so a possible embedded browser solution > requires a close to 1GHz system -- as a good example, check out the > performance for the new Nokia 770 device. > I'm not suggesting using gtk. And I'm also not saying that in the optimized implementation that it would not be drawing direct. The key is that the optimizations are done within the framework of a svg dom initially they can be done by hand but there is I believe a much better way.
I'm working on another project to add a llvm back end to the gcjx compiler http://llvm.cs.uiuc.edu/ The initial work is for java but I see no reason that I can't continue to work develop a svg and javascript jit for the arm. It can either compile to llvm bytecode or direct to machine code. You need a interpreter at the minimum for javascript and potentially other languages so the next stage is to extend the llvm architecture to support a number of higher level languages. Svg for example would compile to almost directly calls to the low level graphics system. Llvm readily supports AOT compilation and cross module optimizations. I'm betting that I can generate faster code with a optimizing compiler starting with SVG and the low level graphics libraries. When and how this is done is dependent on the abilites of the device use of a proxy server etc etc but the decision is pushed out to deployment time. The 3D drivers already do this there is no reason you can't do it for 2D. Btw I used too work for SavaJe were I lead the team that implemented Swing and Java2D for phones with 32 meg of ram and a 100+ mhz arm cpu. The real problem is the 16 bit memory bus and lack of vram. The performance of the final implementation was very good better then the original all native system. And remember I'm limited by the java2d api's and swing api's to what I can optimize out. I'm just bringing it up to show I have a lot of experience doing this sort of thing. I've certainly pushed poor little phones to the limit :) Mike > --Kent > > -- > Happiness is an inside job. > > _______________________________________________ > directfb-dev mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
