On Fri, 03 Apr 2009 08:25:35 -0400 "Iain B. FIndleton" <ifindle...@videotron.ca> said:
beware of jumping all over 3d as the solution. i have recently been working on a gles2 engine for evas. i have run it on 2 platforms (s3c6410 and omap3530). both with hardware opengles2 (and capable of high res etc.) and software beats gles2. yes - evas software rendering is faster. oddly enough the movial guys and trolltech (qt) guys see the exact same performance problems. gl is slower (i know that i and the trolls have seen about a 1/4 speed of gl vs software). reality bites :( > In my case, the apps I use need space on the screen for buttons, etc > that control the things being done. My typical layout is to use 460 x > 570 for the actual application display, the rest for decorations and > controls. Under these conditions, 512 x 512 would be fine, even if I had > to cut the display by a few lines. > > Even the 2D accelerations items would probably make things much better > as I do my own conversion from 3D to 2D. > > Are there any instructions as to how to get the xorg driver running? I > currently use whatever came with the phone run time images > > > > Thomas White wrote: > > On Thu, 02 Apr 2009 11:17:42 -0400 > > "Iain B. FIndleton" <ifindle...@videotron.ca> wrote: > > > > > >> A significant issue for me is the performance of the graphics display > >> on the FR. I recall some discussions a while back about making use of > >> the XGlamo acceleration features. Has any progress been made here? It > >> appears to me that the graphics performance on the FR is poor > >> compared to, for instance, the iPhone or iTouch, both of which have > >> slower CPUs. When applications running on the FR have their X output > >> routed to a machine with accelerated graphics, it is apparent that > >> the FR processor can deliver the X events fast enough, but the FR > >> graphics chip interface can't keep up. > >> > > > > [I wrote this before the other replies came through, so it re-covers a > > bit of ground.] > > > > We do have some acceleration already - both XGlamo (the Kdrive X server) > > and xf86-video-glamo (the Glamo driver for Xorg) make use of Glamo's 2D > > engine to accelerate tasks such as flood-filling large areas and moving > > blocks of data around the screen or onto the screen from offscreen. > > > > However, I do agree that we can do a lot more. So far, we've > > concentrated on trying to implement conventional acceleration protocols > > while being limited by what Glamo can't do. Instead, I think we should > > look at what the little chip CAN do, and really make it work, HARD, for > > us. Particularly its 3D engine. With that, we could do things like > > (dare I say it, iPhone-style) flying launcher icons, or alpha-blended > > overlays, or other things I can't even imagine right now... > > > > There are many limitations of the chip, but I don't see them as a > > reason to give up on this kind of thing. For example, it's often > > mentioned that the 3D engine won't render to a buffer larger than > > 511x511 pixels. That would seem to rule out such graphical fanciness > > at the native resolution of 480x640, but how about we just cover a > > 480x511 region of the screen with accelerated graphics and make the > > remaining area into some kind of tool or status bar? Maximum texture > > size of 256x256? Then design the UI so that the accelerated parts of > > the UI split into blocks of that size or less. And so on. > > > > I see more potential in working 3D acceleration than just Quake, and > > I'm not in the least bit put off by the knowledge that the chip is a > > "one-off"... > > > > Tom > > > > _______________________________________________ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community