A few people asked me about what eDriven.Gui actually brings to the table.
This question is primarily about eDriven sitting on top of the UnityGUI (Immediate Mode GUI or IMGUI for reference) and how it relates to IMGUI limitations.
To be exact, this question is about two things:
1. high draw call count provided by the IMGUI
2. the IMGUI being a 2D GUI
Not a renderer
The important thing to realize is that eDriven.Gui is not meant to be a renderer.
It is the system built on top of the renderer (provided by Unity, or eventually the 3rd party).
Since the IMGUI is the latest and stable version of the GUI system provided by Unity out-of-the-box, it was a natural choice for wrapping the framework around.
The problem with GUI systems is: people don’t know much about their internals.
And without knowing about the internals – they presume these do not exist, or are not needed (“over-engineering”).
However, some of the user interfaces we are using daily would be really hard to accomplish if not having a sub-system built especially for this purpose.
This kind of system is called a GUI framework, and is built on top of the low-level rendering routines provided by the system.
Computer engineers specialized for user interfaces are able to recognize weak and strong points of the system in question, and are building frameworks which solve low-level problems.
The framework encourages the usage of the particular techniques, while discourages the use of others (preferably bad) techniques.
It also provides the consistent way of writing – preferably short – code.
The framework has to be expressive: small code snippets – written by the developer using the framework – should do a ton of work.
What the framework developer does is he is trying to solve this problem from “the outside”. He’s surely got no access to browser internals and cannot possibly fix its internal problems. He relies on the functionality provided by the browser, and he’s working with the number of APIs sprovided by the browser: DOM, CSS etc.
So, what’s in a GUI system except the renderer itself?
Contrary to the popular belief, there are many things to build upon the core rendering system.
Let’s mention some of them:
eDriven is about interactivity. It’s about the publish-subscribe event-driven paradigm.
This core provides nuts and bolts for the user interface built on top.
eDriven is also about styling. It provides the unique way of targeting components throughout the application and applying the specific GUI style (from any GUISkin) to specified component(s).
The separation of styles is important because of the quick change of look&feel of the overal application.
By tweeking the StyleMapper – which is a kind of proxy between eDriven.Gui components and GUISkins/GUIStyles – you can change the look of the specified component throughout the application.
Automatic layout is an important part of all of today’s modern GUI frameworks.
Rather than setting component coordinates and sizes manually, layout does it automatically after the child is added or removed from the parent container.
Layout logic is not hardcoded into containers: layout objects are plugg-able into any container. Also a new layout class could easily be written, and it could arrange child components in its own particular way.
It is also about the animation and tweening.
eDriven has a tweening engine capable of handling multiple paralel and sequenced tweens.
You could use various easing curves, as well as various interpolators to do the work.
Although coming with a basic set of components, eDriven.Gui provides using of custom components, that could be built by yourself or the 3rd party author.
These components could as well have their style mappers bundled as a prefab that could easily be dragged to the scene – and dramatically changing the application look and feel.
You can have your custom component (built from scratch) show up in eDriven.Gui Designer within minutes.
As many others, I’m also waiting for the release of the next GUI system provided by Unity – the New new GUI.
I call it a “New new” GUI, because sources say it will be very different from the New GUI presented at Unite 2012.
I’d be very happy if this system provides the API that is so huge success as the UnityGUI API!
The part I’m pretty sure about (so no worries there) is that this will be a 3D GUI, having a low draw call count.
So, I’m hoping to wrap up the eDriven.Gui around this system – someday after it is released.
Never say never
However, if the “New new GUI” doesn’t happen (anytime soon) I just might go for creating my own low-level 3D renderer
I have to say that 3D (quads, meshes..) is a very interesting stuff. I’d love to have more time for diving into it!