On 15 November 2012 15:11, Arne Eilermann <eilerm...@lavabit.com> wrote:
> A few words on the company: The bevuta IT GmbH is a software company based > in cologne, Germany. We are like 10 Geeks in an office to which Moritz > Heidkamp – you may know him – in 2010 brought chicken. We did a few smaller > project in chicken but now the first bigger one knocks on our door. > > This project involves the development of a framework to create cross > platform GUI applications in chicken on Android and iOS. The bindings for > JNI to access Android's API is mostly done. The next step will be doing > something like that for iOS. With this bindings we want to create an > abstraction layer to get a common interface. > All of this is part of a bigger commercial and proprietary contract work, > but the emerging framework shall be released to the community. > > We already got some experiences with chicken on mobile devices. In 2011 we > did some OpenGL stuff on Android and iOS. Moritz was significantly involved > in this. It was mostly experimenting, but it did quite well. > > If anybody of you is interested to join, feel free. We would be glad. > That sounds quite interesting, and similar to what I have tried to do in my spare time, but there's never enough of that. It took me too long to realize that I really needed to use OpenGL, with which I didn't have enough experience yet (and only the last couple of years have I had hardware which could support Linux and ES 2.0, anyway); and it's a big change compared to just "painting stuff". The concept of a scene graph is a funny thing in a way, because OpenGL is fundamentally procedural: you make API calls in the right order, and the shaders are procedural code too; but the scene graph is a declarative abstraction for that: it exists statically in memory (except when changes are made to it, during animations and such). (The only items which can exist statically in graphics memory are pixmaps and vertices, or other types of data disguised as those, which can be manipulated in the shaders; so parts of the scene graph can be converted into a form which does not need to be regenerated for each frame, but not the whole thing.) Then you have to write more procedural code to manage the scene graph. And then you probably have another declarative abstraction or collection of some sort of model objects, for the GUI or the game objects or whatever. My gut feeling is that's too many layers, even though I understand why it is that way right now. I don't like the lack of transparency; it takes too long to understand all the layers. And I think OpenGL is still too primitive: the scene graph cannot be transferred wholesale into graphics memory; and there is no way to generate geometry on the GPU from more-compact representations, unless you have geometry shader and tesselation shader suport, which has not trickled down to ES yet. Even rendering text is still a big deal. AFAICT the scene graph concept exists to facilitate fast traversal for the purpose of generating the per-frame OpenGL calls. If a Scheme implementation was fast enough, maybe we could go back to just doing the rendering in an expose callback (like the opengl egg makes possible); but it's not necessarily fast enough, depending on the complexity of what you draw and the frame rates you expect; so having a scene graph encapsulates the optimizations necessary to get good frame rates, at the cost of being limited to the kinds of primitives that the scene graph supports. If you use a per-frame callback then you have to write optimal frame-generating code yourself, and that's hard work, especially if you have to do it for every application. I'm thinking maybe a scene graph could be made of Scheme objects though. Just the code to traverse it and generate the OpenGL calls would need to be optimized. Kristian decided to use Chipmunk, which is a scene graph with an integrated physics engine, right? That's maybe a different optimization than you need for doing basic 2D GUI applications, but I do wonder if it could work for that purpose too. FWIW Qt is in process of getting fully-supported Android and iOS ports. So maybe Chicken could make use of that. At one point I thought maybe the Qt egg was going to be the way to go for GUIs, but nowadays widgets are being deemphasized in favor of QML. Of course the official scripting language for that is Javascript. Personally I'd like Scheme to be an alternative. I like the declarative QML syntax itself, but it has to be augmented with some kind of procedural language. QML is based on a custom scene graph which has been used mostly for 2D purposes (GUIs and 2D games). The text rendering is probably unmatched compared to any other OpenGL implementation: fast, scalable, antialiased and with full Unicode support. So since everybody who uses a scene graph writes his own, I guess that means we don't really have a standard or a known-best all-purpose one. It's hard to see at this time what is the future-proof foundation to base anything on. As cool as the graphics are that the current technology enables, there are such obvious holes in it. I wouldn't be surprised if in a few years we will be writing CSP processes to run directly on the GPU cores, to get more freedom rather than being constrained to the OpenGL API. When that happens, will it mean things like Chipmunk are obsolete too? So what is your architecture like? Did you guys start over with just OpenGL, or reuse a scene graph from something else?
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
