4 ms·

> 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 Op

> 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?

dagmx 2y ago
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.
- anotherhue 2y ago
  '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.
- codedokode 2y ago
  > 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.
- codedokode 2y ago
  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?
  - dagmx 2y ago
    ImGUI is quite popular for many tools unrelated to graphics. I’d recommend checking out the gallery posts on the repo for Dear,Imgui for examples. I believe even tools like NVIDIA’s Omniverse are based upon Imgui
SideQuark 2y ago
> Why does a hex editor require ... a GPU? 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-accelerated-rendering https://www.sublimetext.com/blog/articles/hardware-accelerat...
- 1vuio0pswjnm7 2y ago
  "Any editor..." 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.
  - SideQuark 2y ago
    > "Any editor..." 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/2d4a3d9e6c1493a9520b907e07a41aca90cdfd94/miscutils/hexedit.c https://github.com/mirror/busybox/blob/2d4a3d9e6c1493a9520b9...
  - 1vuio0pswjnm7 2y ago
    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. 1. Pixels, not glyphs
9029 2y ago
they probably just picked the opengl renderer for imgui
salicideblock 2y ago
FYI, from the project's Readme: > In case you don't have a GPU available, there are software rendered releases available for Windows and macOS

> 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?

dagmx 2y ago

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.

anotherhue 2y ago
'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.
codedokode 2y ago
> 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.
codedokode 2y ago
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?
- dagmx 2y ago
  ImGUI is quite popular for many tools unrelated to graphics. I’d recommend checking out the gallery posts on the repo for Dear,Imgui for examples. I believe even tools like NVIDIA’s Omniverse are based upon Imgui

SideQuark 2y ago

> Why does a hex editor require ... a GPU? 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-accelerated-rendering https://www.sublimetext.com/blog/articles/hardware-accelerat...

1vuio0pswjnm7 2y ago
"Any editor..." 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.
- SideQuark 2y ago
  > "Any editor..." 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/2d4a3d9e6c1493a9520b907e07a41aca90cdfd94/miscutils/hexedit.c https://github.com/mirror/busybox/blob/2d4a3d9e6c1493a9520b9...
- 1vuio0pswjnm7 2y ago
  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. 1. Pixels, not glyphs

9029 2y ago

they probably just picked the opengl renderer for imgui

salicideblock 2y ago

FYI, from the project's Readme: > In case you don't have a GPU available, there are software rendered releases available for Windows and macOS