> ImHex requires a GPU with OpenGL 3.0 support in general.
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?
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?
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.
See this [1] for example
[1] https://www.sublimetext.com/blog/articles/hardware-accelerat...
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.
And you are comparing apples with oranges. busybox hexedit is not a GUI app.
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)?
[1] https://github.com/mirror/busybox/blob/2d4a3d9e6c1493a9520b9...
1. Pixels, not glyphs
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.
I am not playing video games. I am not interested in "AI".
I do not need a GPU to use a hex editor. That would be a waste of electricity.
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.
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.
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.
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.
I believe even tools like NVIDIA’s Omniverse are based upon Imgui
> In case you don't have a GPU available, there are software rendered releases available for Windows and macOS