Show HN: kiUi – Lightweight auto-layout stylable UI toolkit(novembermonk.github.io)
novembermonk.github.io
Show HN: kiUi – Lightweight auto-layout stylable UI toolkit
http://novembermonk.github.io/kiui/article.html
43 comments
This is wonderful. Thank you for building this. Your emphasis on modern C++ and small dependencies is especially appreciated, especially in a world where an Emscripten bundle size matters.
What's your rendering performance like, such as when you update 50 static text fields or images every frame?
What's your rendering performance like, such as when you update 50 static text fields or images every frame?
Thank you. As to the draw calls, NanoVG draws everything directly each frame so this is constant whether or not you are updating. As to the overhead, not too long ago everything was updated each frame regardless of whether it was modified or not, and performance was fine. Worse than it is now, but okay. So I guess it could handle it.
But then again, that's only the default renderer. You can always roll your own and plug it in, kiUi has been designed to permit that.
But then again, that's only the default renderer. You can always roll your own and plug it in, kiUi has been designed to permit that.
Gotcha. I ask because, on my machine, kiUi takes 8-9ms every frame regardless of what I'm doing (e.g., typing, dragging windows, resizing things). If I'm trying to maintain 60 FPS with Emscripten, 8-9ms is a significant portion of my 16.7ms frame budget.
By comparison, a basic Emscripten libRocket demo takes 6-8ms (mostly due to Freetype rendering and its layout system, see http://forums.librocket.com/viewtopic.php?f=2&t=5223), and ImGui takes 1ms (probably due to its monospaced bitmap fonts and simple widgets, demo: http://floooh.github.io/oryol/ImGuiDemo.html).
Just some thoughts in case you're planning on adding complicated game logic every frame :)
By comparison, a basic Emscripten libRocket demo takes 6-8ms (mostly due to Freetype rendering and its layout system, see http://forums.librocket.com/viewtopic.php?f=2&t=5223), and ImGui takes 1ms (probably due to its monospaced bitmap fonts and simple widgets, demo: http://floooh.github.io/oryol/ImGuiDemo.html).
Just some thoughts in case you're planning on adding complicated game logic every frame :)
statico: you can load a different TTF with ImGui, it doesn't have to be monospaced and they can be smooth. The perf differences are due to designing the library with performances as a major pillar, lots of things are optimised. A visual redesign is planned but it'll take a bit of time to get it done to keep the perf up.
That's great information. Thanks!
I think it's funny how many xml based UI frameworks have been made over the years that are better composed better than html with more strict rules and consistency that are continuously overlooked at times.
I would like to think that for some UI projects that things like XAML(WPF/Silverlight) or Flex(Flash) would be some of the first things to reach for... IIRC there are similar tooling for building for GTK and QT applications. Why build your own?
I would like to think that for some UI projects that things like XAML(WPF/Silverlight) or Flex(Flash) would be some of the first things to reach for... IIRC there are similar tooling for building for GTK and QT applications. Why build your own?
I have a simple answer but it may not suit you :
After spending quite some time writing UI, I believe doing it in either XML or HTML is just pure madness.
UI is a very complex structure with complex wiring and interactions between components, and so it is very prone to human error. To represent such a complex system in anything else than a statically typed language like C++ is, to me, incredibly counter-productive.
You may like to write them in XML, but I want to write them in code and I wrote kiUi just for that. It's more concise, less error prone.
More essentially, I think it comes from a "fallacy" or "false dream" that a designer could design a reactive UI in XML or HTML without knowing anything about code.
The back of the coin, is that to code a real UI you need both HTML and javascript, or XML and another language. XML and HTML are just here for the layout.
But kiUi takes a rather different approach at layout, which is that you may not even need to specify layout in the first place. It's done for you already, but, the designer can still tweak it if needed.
So, kiUi inverted relationship of the primacy of layout over the rest. In kiUi the primacy is to the native code, and to the logical elements (the widgets).
After spending quite some time writing UI, I believe doing it in either XML or HTML is just pure madness.
UI is a very complex structure with complex wiring and interactions between components, and so it is very prone to human error. To represent such a complex system in anything else than a statically typed language like C++ is, to me, incredibly counter-productive.
You may like to write them in XML, but I want to write them in code and I wrote kiUi just for that. It's more concise, less error prone.
More essentially, I think it comes from a "fallacy" or "false dream" that a designer could design a reactive UI in XML or HTML without knowing anything about code.
The back of the coin, is that to code a real UI you need both HTML and javascript, or XML and another language. XML and HTML are just here for the layout.
But kiUi takes a rather different approach at layout, which is that you may not even need to specify layout in the first place. It's done for you already, but, the designer can still tweak it if needed.
So, kiUi inverted relationship of the primacy of layout over the rest. In kiUi the primacy is to the native code, and to the logical elements (the widgets).
I think that things like React, and React-Native show the opposite is true... composition of UI elements that are meant to be rendered in relative terms doesn't tend to work out well when you are trying to use absolute measurements in something like C++ with lower-level constructs.
The fact that it is XML is more convention in this case... even with React, it's translated to coded controls via strict rules.. and is relatively easy to manage and reason with.
The fact that it is XML is more convention in this case... even with React, it's translated to coded controls via strict rules.. and is relatively easy to manage and reason with.
One thing you misunderstood :
You don't specify any absolute measurement when using kiUi from C++.
The whole point is to get rid of them. They are calculated under the hood.
The style gives the necessary hints. And this is done in a way entirely separate from the UI code itself.
Think of the C++ code doing what is regularly done in both HTML and Javascript, and the kiUi style sheet as what is regularly done in CSS.
You don't specify any absolute measurement when using kiUi from C++.
The whole point is to get rid of them. They are calculated under the hood.
The style gives the necessary hints. And this is done in a way entirely separate from the UI code itself.
Think of the C++ code doing what is regularly done in both HTML and Javascript, and the kiUi style sheet as what is regularly done in CSS.
two issues:
1. it doesn't accept asian language inputs. 2. the scrolling direction doesn't respect my system settings. (I have unchecked natural scrolling direction on my mac)
1. it doesn't accept asian language inputs. 2. the scrolling direction doesn't respect my system settings. (I have unchecked natural scrolling direction on my mac)
It seems to be hardcoded natural scrolling - I'm getting it on a Windows desktop with a mouse wheel.
Still wrong. The scrolling direction is the opposite of your system settings.
I have my mac set to "natural" scrolling and for me the demo scrolls conventionally.
I have my mac set to "natural" scrolling and for me the demo scrolls conventionally.
Issue seems to come from Emscripten
https://github.com/kripken/emscripten/issues/3171
the input and scrolling is handled by GLFW, I'll look into the issue.
also it's specific to the web version which is weird
Many game developers seem to build their own UI libraries from scratch. Wouldn't it make sense to use Chromium Embedded Framework[0] or Awesomium[1] instead? I haven't used them myself (yet), but writing a UI in HTML+CSS sounds a lot easier than learning a new API.
[0] https://bitbucket.org/chromiumembedded/cef [1] http://www.awesomium.com
[0] https://bitbucket.org/chromiumembedded/cef [1] http://www.awesomium.com
Writing UIs in HTML+CSS is only easy for people who know it already, to be honest. It's not a great UI layer.
I've been using it for almost 20 years now, and I'm still easily confused by the completely unintuitive interactions of CSS parameters like floats and clears, position:relative, box model nuances, etc. (I'm sure that someone is now itching to chime in and tell me I'm not a "real web developer", sort of like the argument on HN the other day about whether "real developers" are allowed to write <br/> ...)
Game development teams don't tend to include CSS wizards. Writing a new API can be a reasonable choice given the expertise available... Not to mention the substantial runtime overhead of loading a complete browser just to display some UI widgets.
I've been using it for almost 20 years now, and I'm still easily confused by the completely unintuitive interactions of CSS parameters like floats and clears, position:relative, box model nuances, etc. (I'm sure that someone is now itching to chime in and tell me I'm not a "real web developer", sort of like the argument on HN the other day about whether "real developers" are allowed to write <br/> ...)
Game development teams don't tend to include CSS wizards. Writing a new API can be a reasonable choice given the expertise available... Not to mention the substantial runtime overhead of loading a complete browser just to display some UI widgets.
You are somewhat right in that HTML and CSS heavily inspired what kiUi became.
But there are two major concerns that are not adressed by your solution :
- Embedding a whole browser in your app just to display a few widgets is not my definition of "lightweight"
- Often coding UI in native code (C++) makes a lot more sense, integrate with exiting code in a much cleaner way
Game developpers would much less tend to build their own libraries from scratch, if there was at least one that satisfied all of these 'basic' requirements : lightweight, skinnable, auto-layout
- Embedding a whole browser in your app just to display a few widgets is not my definition of "lightweight"
- Often coding UI in native code (C++) makes a lot more sense, integrate with exiting code in a much cleaner way
Game developpers would much less tend to build their own libraries from scratch, if there was at least one that satisfied all of these 'basic' requirements : lightweight, skinnable, auto-layout
I agree, embedding a browser doesn't seem lightweight at all. What it does give, however, is a common and comprehensive framework for laying out and styling your UI elements. Every web developer can now be a game UI designer.
Some of the benefits I see with HTML+CSS(+JS) based UI:
Some of the benefits I see with HTML+CSS(+JS) based UI:
* Comprehensive feature set
* Easy prototyping
* Easy modding
* No recompilation required
* Web full of documentation & examples
* Common skill for developers/designers
HTML is not good for UI.
AAA studios use Flash.
http://gameware.autodesk.com/scaleform
http://gameware.autodesk.com/scaleform
Or HTML. http://coherent-labs.com/
[deleted]
How about IMGUI?
https://github.com/ocornut/imgui
https://github.com/ocornut/imgui
ImGui looks decent but is "designed and optimised to create debug tools." If you're building a game that doesn't look like a debug tool, you'll want to do some kind of skinning or at least make the UI fit into the aesthetic.
Also, FWIW -- here's ImGui running in the browser: http://floooh.github.io/oryol/ImGuiDemo.html
It's great and I actually borrowed ideas from his examples.
Immediate mode and retained mode UIs are entirely different beasts though, with different targets / use cases. Something like dockable windows would be much harder to implement in a IMGUI lib
RM vs IM is entirely about where the name (id, pointer, whatever) of the widgets comes from. In RM it comes from the library, and is typically a pointer to some data that represents the 'widget', and in IM it comes from the user and is frequently a string or other local pointer (sometimes macros are used to generate IDs).
Anyway, there's no reason this would be harder to do in IM, other than that a lot of people are more familiar implementing RM than IM.
Anyway, there's no reason this would be harder to do in IM, other than that a lot of people are more familiar implementing RM than IM.
Funny thing, I've been scheming and plodding with seemingly identical idea. I've been approaching it with a bit more experimental angle (more declarative way to generate the ui? what approach for auto layout? etc.), so I've yet to make much progress.
Need to take a closer look if this happens to match my needs
Need to take a closer look if this happens to match my needs
I'm interested to know more about your plans for a declarative model.
I think many things in kiUi, especially the layout and style, can be seen as declarative, in a way.
But the individual widgets and interaction between them are not. And I'm curious as to how it could be different. Also you want to collaborate on something or just discuss, I'm interested.
I think many things in kiUi, especially the layout and style, can be seen as declarative, in a way.
But the individual widgets and interaction between them are not. And I'm curious as to how it could be different. Also you want to collaborate on something or just discuss, I'm interested.
Hey, I'd love to chat with you about this. Please send me an email! (Address in my profile.)
The webpage says that it's MIT licensed, but the GitHub page says that it's zlib licensed. Which is it?
Shouldn't it be "a UI toolkit" instead of "an UI toolkit"?
Yes. It's about phonetics, not the first letter. The y sound in "you" is a consonant, like "a ukulele", whereas the h in "an hour" is not.
yup, fixed (non-native speaker here)
This is really cool. One thing - I'm on a work laptop, so a not particularly impressive Dell, and I get some mouse slowdown in the demo.
[deleted]
[deleted]
i.e weird scrolling (slow, direction), ghosting, crashing chrome, etc.
I was under the impression that this isn't really meant to be a web project, so the fact that LLVM is being imperfectly converted to JavaScript is probably the reason for most of these.