Any editor, to be fluid and quick at today's screen resolution, needs hardware rendering. The days of drawing things pixelwise, especially any complex formatting, are noticeably slow.
busybox hexedit is an editor. It's fast for viewing and editing in hex. No GPU required. No need for ncurses either. toybox hexedit adds optional colors.
Yes, if you ignore what I wrote and cut the conditions short, you can change the conclusions. Yet I still don't think you're understanding how even console hardware tends to work.
Busybox hexedit is not drawing pixels. What do you think is drawing those glyphs on the screen? Very few font renderers are pixel based software, even for tiny systems, since that's slow (and font blitters are soooo cheap to embed).
Another way to see it - where in the hexedit code is the font drawing? In busybox? Oh, it relies on something else to do it, and even most of those are hardware accelerated. Here's the hexedit code [1]. Start there, walk back through how it prints, how that is implemented in busybox, how busybox defers that to hardware, back into various supported platforms, look at the chip sets, and voila... Hardware accelerated in most cases (I don't see one offhand that does pixel writes any more).
Pretty much all console hardware now is hardware accelerated. If you log into a device and run SSH from a larger machine, those glyphs are hardware accelerated.
So which combinations do you claim have no hardware acceleration (and if possible, meet other conditions I actually listed, like modern screen resolutions)?
Textmode on pretty much every laptop since the beginning of time uses a GPU to draw characters in textmode. GPU doesn't mean NVidia, it means graphics accelerator, and they've been used since the 1970s or earlier to turn ASCII characters into glyphs onscreen.
The earliest IBM PCs and compatibles used hardware acceleration for textmode, and those ancient BIOS interfaces and successors are still used to draw characters, not pixel by pixel, but with hardware acceleration.
So whether or not you like it, whether or not you understand how your laptop actually works, you're almost certainly using a GPU to render textmode.
The MIPS router that I connect to via SSH does not have a GPU. Nor does the laptop I use to connect to it. I am not a gamer and I have never purchased an expensive graphics card. The first "GPU" went on sale in 1999. In that time period, I used VGA textmode^1 to do hex editing. I still use textmode today. I do not run X11/Wayland/whatever. I do not use a terminal emulator. I am not interested in Unicode; I deliberately avoid UTF-8 where I can. In all the time i have been using computers, I have not needed hardware acceleration for editing hex. I do not forsee that changing before I die.
Your laptop most certainly has a GPU, even if it's not a dedicated one. All modern desktop environments use GPU acceleration, it's just that integrated GPUs are good enough for anything but the most demanding games. They are also enough for ImHex
The first GPU went on sale decades before 1999: all personal computers used dedicated hardware to accelerate text mode - none of them could early on draw pixels fast enough to draw a screen of text at anything usable for text editing.
All laptops use a GPU since the very first PCs used BIOS routines to access the graphics card, which, surprise surprise, accelerate textmode to make it usable. You're proving my point.
Same goes for pretty much any MIPS router that connects to a screen. List your make and model, and I'll find the docs showing you how the GPU in it is used to draw characters in text mode.
Even the term "text mode" is a holdover from those 1970s era cards: they had dedicated graphics modes where you draw pixels, and hardware accelerated modes called textmode where ASCII bytes get drawn, by hardware acceleration, as characters.
The UI is built using Imgui (hence the Im prefix) which is a Ui framework for computer graphics programs.
Though, a couple nits:
1. An OpenGL requirement doesn’t necessitate a GPU. There are software implementations of OpenGL but they tend to be rather mediocre at best for performance.
2. Many platforms now assume some kind of GPU. It’s fairly rare to need a GUI tool without also having a GPU available. Of course there are niches for it, but those aren’t also likely to be running a hex editor and tooling locally.
'GPU' doesn't mean discrete, power-hungry graphics card either (not that you said it did).
OpenGL calls for basic desktop rendering can be reliably handled by the integrated graphics in the CPU. In which case OpenGL can almost be viewed as a parallel instruction set / DSL.
> There are software implementations of OpenGL but they tend to be rather mediocre at best for performance.
This is because OpenGL is made so that you need to run a program to calculate color of every pixel, even if all you want is to copy a glyph. Obviously it will be slow unless you have hundreds of core running in parallel. Software implementations should either learn to convert shaders to non-parallel optimized loops, or something other than OpenGL should be chosen as a basis for rendering GUI.
Also, ImGUI (which is an immediate mode toolkit) is a weird choice for GUI program, isn't it better to use retainted mode library that updates only parts of the window that have changed?
Why does a hex editor require OpenGL? (and therefore a GPU?)
Is there a good reason why it needs OpenGL or is it just for l33t-ness?