I’m going to be rewriting a Windows editor application of mine with a lot more flair in the presentation and presentation effects, trying to separate it a bit from the standard Winforms look and feel. Trying to do that in a Winforms projects and GDI+ isn’t tremendously feasible out of the box, and WPF has a steep enough learning curve that I’ve already deemed it too high a cost.
After attending a Unity dev event, watching some tutorial videos, and seeing Unity UI, I’m considering the Unity platform for my editor application. It’s a visually based application, but would be entirely 2D with reliance on standard Windows visual elements (checkboxes, scroll bars, labels, textboxes, etc), which Unity UI supports. I’d also have to implement familiar mechanisms such as drag-and-drop, which I’m guessing I’d have to roll my own to do, but I’m OK with that.
Basically, I don’t want to have to worry about the fine-grained details of implementing a better presentation than what Winforms generally provides and am wondering if Unity could be a good platform.
Has anyone tried this and have feedback about their experience?
No, it’s not really a good idea since Unity runs in a game loop. Unity is fine for non-game apps, but they still should be “game-ish” in some way (architectural visualization, 3D simulators, etc.), where it would make sense to run in a game loop.
But does Unity’s game loop necessarily mean it’s going to be burning up the CPU or have other adverse side effects? On the surface, I don’t see anything wrong with there being an update loop if you’re maintaining the UI based on the states of the elements being represented. Especially if there is some sort of a preview; that could be very beneficial.
Yes. Every frame, everything on the screen has to be culled and submitted to the GPU. Even if you’re doing “nothing”, actually quite a bit is happening behind the scenes. The underlying assumption is that stuff will be generally changing a lot every frame, so Unity is built with that in mind. It’s not a good fit for “business” apps where you spend 99% of the time waiting for user input.
Ooh, I actually get to (at least partially) disagree with @Eric5h5 for once! There may be a lot going on, but I wonder if that really matters. What does matter though is whether Unity is the best choice, and the best provider of the funcionality that you need. Have you looked at any other solutions out there yet? Java has some UI and form libraries that I couldn’t name, Python has wxWidgets, Kivy and a bunch of others; heck perhaps there’s a fancy UI library for plain old .NET out there. I would just take a look around and pick whichever seems most efficient to use. I wouldn’t immediately worry about the overhead (be with processing from Unity or memory from Java), though it could be important depending on your context (type of app, hardware it should run on, etc.)
Doesn’t the Unity editor application use the Unity UI libraries? So that would be an example of a desktop editor application using the Unity platform. Granted, it’s doing a lot more than the average editor, but I don’t remember it pegging my CPU significantly. Heck, my existing editor has a graphical preview that updates at 50 fps and it hardly registers on the task manager. Surely the Unity platform is trying to be responsible with CPU usage and management when they’re able.
Getting into management and utilization of the GPU is outside my realm of experience, but I would imagine/hope that that would take some of the load off the CPU and not add to it.
This application being rewritten isn’t a data-entry form-based sort of application, but one that uses graphical display of its elements, a lot of drag-and-drop of those elements, some (at current) elementary animation within those elements. I’d like to elaborate the graphical side of it more, but I’m finding that doing that in Winforms is almost requiring implementing my own presentation framework to work around GDI limitations. So I thought of Unity, whose got the presentation down and brings a lot more to the table than I could ever dream of implementing myself.
The editor behaves much differently from a build, and is not run in a game loop, unless you’re in Play mode. Otherwise it only updates when something changes. It’s not possible to do that with a Unity-built app (that I’m aware of). The idea of the game loop is to use as much CPU/GPU as possible, so games run fast. This can be limited with vsync or Application.targetFrameRate, but neither of those are comparable to “only update when something changes”.
Eric does have a point, and it could be a lot of waste/overhead because of the general purpose of Unity.
On the other hand I really doubt its going to be an issue for you at the bottom line as long as your target hardware is better than a modern cell-phone. I’ve made UI centric “apps” that have run great as well as 3d simulators in a commercial non-game related context and they have performed fine.
So the question is more like ‘do you want to deal with the Unity pipeline/environment and accept some overhead instead of what you are currently doing which is probably way more catered to your needs?’
Thanks for the active participation, guys. Given all of the feedback and input, I’m going to throw together an application this weekend to test a couple of concepts I’m using in my editor and see what it’s like to implement them in Unity and how it taxes the system. I agree that the platform is overkill for the purpose, but it also opens up a lot of possibilities. It may be that the overhead is acceptable, or maybe its not. I’m not married to the idea, but more wanting to explore options.