What are the downsides of using ebiten as a gui software?

[ShadiestGoat]

If I wanted to create an app, say for example a text editor, why not to use ebiten?

[shrmpy]

You are not alone. In Discord, Nicolas posted in #show-and-tell a preview of their progress for their own text editor (02/19/22)
Maybe a downside is a need to obtain the system fonts? I think this question is mentioned in the Etxt package readme. For example on Linux there is fontconfig, but what about OSX, Android? I have no clue what you do on diff platforms.

[ShadiestGoat]

Doesn't ebiten have utils for rendering text?

[shrmpy]

Yes, Ebitengine already has support. So you can build, package, and ship fonts with your Ebitengine program. This is the normal path. When I say system fonts, I mean the scenario where you expect to allow the user to use existing fonts that already are part of their device. Typically the user has a few (>10 ?) fonts to choose from on their system. It's more interesting to consider different languages. For a user in a non-english language, if I can't access their system font then I need to ship a font that supports their language glyphs with my Ebitengine program.

[ShadiestGoat]

Ah I see.. like downloaded fonts? Wouldn't you just use font-config for linux, and uh.. native things for other oses? Have the user set their default font. I think I'll go with something like gio

[shrmpy]

Yes, I'm certain there are options. You just reminded me of the webview (?) package. There are two that I can remember, but I'm thinking of the one that launches your default browser. That package doesn't want to implement a HTML engine, its goal is to hand over the URI to the web browser that is already on the device.

[tinne26]

Simply, because Ebitengine is not oriented to those use-cases. First, the UI libraries for Ebitengine are usually not general purpose UI libraries, but libraries oriented to games. There's ebitenui, but you will find better libraries on environments focused on general purpose application development. Another example is text. System fonts are not actually a big problem, but there are many other important issues if you want to support multiple languages: text shaping is currently not possible on Ebitengine. Mostly because /x/font/sfnt doesn't support it. Gio and Fyne use libraries developed for them, porting HarfBuzz or others precisely because Golang support on that front is very lacking.

Another important concern is performance. Ebitengine will be less performant, simply because it makes other trade-offs in pro of portability, it handles many kinds of inputs, and it's basically a single-man project where you can't expect things to be as well optimized as on bigger projects. Maybe it will get better in the future, but from what I can tell and tests on raw glfw, there's a lot of room for improvement there.

With all that being said... if you don't intend to support complex scripts for languages like Arabic and you are not trying to build the next big text editor but rather an experimental tool or a tool for yourself and a few others only, then developing on Ebitengine may allow you to move forward more quickly due to the simplicity of the API.

I generally think your choice of using gio is a good idea here. Consider also fyne. Beyond that, I was only replying to add more context and be potentially helpful to anyone else that may search for this in the future.

EDIT / 2023 Update

• Since v2.5.0, there's now a way to make applications more efficient by using SetScreenClearedEveryFrame(false). While this already existed before, now Ebitengine optimizes the cases when you don't draw anything, alleviating the performance concerns.
• ebitenui was archived for a short while, but Mark Carpenter has become the new maintainer and the library is receiving many updates and improvements. The repo has been moved to https://github.com/ebitenui/ebitenui.

The general conclusion doesn't change a lot, but some things have indeed improved a bit.