Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DearPyGui

github.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: DearPyGui

#51

Post by cma »

smaddox wrote: post #48
cma wrote: post #44

Earlier quoted context omitted.

Hitches are still bad, but consistency is less needed with variable refresh rate monitors. Also, battery life/power usage is an important factor that can push you away from focusing only on consistency.

Variable refresh rate monitors don't solve hitching due to variable computation. In order to render an animation smoothly, you have to know precisely when a frame will be displayed ahead of time, so that you can render the simulation precisely at that point.

I suppose if you know UI cache of some element will be invalidated this frame you can inject a delay up to expected upper bound in frame time increase it will cause and artificially hold back next frame flip by a variable amount if it takes less than the max expected delay. It could be tricky to get that from the GPU with all the queuing it can potentially do and stuff though.

Re: DearPyGui

#52

Post by flohofwoe »

nightcracker wrote: post #46
Jasper_ wrote: post #43

Earlier quoted context omitted.

Correct. In order to tell if a button is clicked, you need to know whether it was clicked last frame, which means keeping around state. One difficulty with immediate-style GUIs is that it's difficult to tell whether two widgets are "the same". Dear ImGUI mostly uses a widget's label as its core identifier, which can cause issues if the button label changes. There's actually a lot more in common between React and ImGU…

This isn't true. All state you need to keep track of is purely the input state: e.g. whether a button is pressed, keys are pressed, etc. And very importantly, you also need to store the edges of the input signal. That is, you need to store whether left mouse has changed from not pressed to pressed this frame, and whether it has changed from pressed to not pressed. Then, the Button(...) call computes the hitbox of the…

At least in the case of Dear ImGui, things like the current window position and size is widget state that's owned and persisted between frames by the library, otherwise windows wouldn't be moveable or resizeable by the UI user.

Other immediate mode UIs may decide to delegate this "state housekeeping" to the user (that's how rxi's microui works), but IMHO this isn't quite as convenient for the library user, it keeps the library implementation very simple though.

Re: DearPyGui

#53

Post by uryga »

mjevans wrote: post #39
jsharf wrote: post #8

Oh, I love Dear Imgui -- it's very simple to use and has a nice... "engineering"/scientific aesthetic. Good to hear it's been ported to python. If you're looking for an end-user product, this may not give you the control you're looking for. But if you're looking for a dead-simple way to create a quick GUI for a side project, this is perfect.

The underlying "imgui" https://github.com/ocornut/imgui project: From the github page - EDIT: Read the bindings / frameworks page too, https://github.com/ocornut/imgui/wiki/Bindings It's still c++ like. """ Officially maintained bindings (in repository): Renderers: DirectX9, DirectX10, DirectX11, DirectX12, OpenGL (legacy), OpenGL3/ES/ES2 (modern), Vulkan, Metal. Platforms: GLFW, SDL2, Win32, Glut, OSX. Frameworks: E…

> Note that C bindings (cimgui) are auto-generated, you can use its json/lua output to generate bindings for other languages.

note about this. the C++ imgui library uses stuff like out-arguments (pass a pointer that gets filled out with a result) almost everywhere, which makes wrapping it with a pointer-less language non-trivial – in python, you want an interface that just returns a tuple and you'll have to code that part up manually anyway (or come up with a really clever generator)

[source: i've contributed to pyimgui, another imgui wrapper, and we looked at auto-generating wrappers at some point, but decided against it because of how much work you'd have to do on top to make it "pythonic". i think they're looking at that again now though.]

Re: DearPyGui

#54

Post by joshvm »

DizzyDoo wrote: post #38
formerly_proven wrote: post #36

Earlier quoted context omitted.

Native, if cross-plattform then Qt or wx (only "old" widgets).

A semi-related question; what is the current 'correct way' to package up Python projects and all their dependencies as native executables for Windows/OSX/Linux? I haven't done any desktop Python since 2.5 and then it was a fiddly process of 'freezing' exe's, is that still the recommended way with Python 3?

It sounds cynical, but I've found that porting Python code to C++ and using Qt is much less headache than trying to make a clean Python "app" that can be run by non-technical users. However a simple solution is to distribute a local copy of Python with all the packages pre-installed. That's not as clean as a single exe, but generally you're going to need DLLs or whatever anyway, and to the end user, running a bat file that calls Python hides most of the mess. The bigger problem with that is hiding code, if you need to do that, but you can always distribute pyc files on their own.

This may have changed, but the last time I tried freezing it took a lot of massaging to get it to work reliably. So I've always opted to just ship a complete python env. I've seen big commercial products do the same when they need to provide python support - you may have experienced this when some new install accidentally adds a new python interpreter to your PATH.

Re: DearPyGui

#55

Post by blt »

uryga wrote: post #53
mjevans wrote: post #39

Earlier quoted context omitted.

The underlying "imgui" https://github.com/ocornut/imgui project: From the github page - EDIT: Read the bindings / frameworks page too, https://github.com/ocornut/imgui/wiki/Bindings It's still c++ like. """ Officially maintained bindings (in repository): Renderers: DirectX9, DirectX10, DirectX11, DirectX12, OpenGL (legacy), OpenGL3/ES/ES2 (modern), Vulkan, Metal. Platforms: GLFW, SDL2, Win32, Glut, OSX. Frameworks: E…

> Note that C bindings (cimgui) are auto-generated, you can use its json/lua output to generate bindings for other languages. note about this. the C++ imgui library uses stuff like out-arguments (pass a pointer that gets filled out with a result) almost everywhere, which makes wrapping it with a pointer-less language non-trivial – in python, you want an interface that just returns a tuple and you'll have to code that…

SWIG can sometimes help with this.

Re: DearPyGui

#56

Post by montecarl »

DizzyDoo wrote: post #38
formerly_proven wrote: post #36

Earlier quoted context omitted.

Native, if cross-plattform then Qt or wx (only "old" widgets).

A semi-related question; what is the current 'correct way' to package up Python projects and all their dependencies as native executables for Windows/OSX/Linux? I haven't done any desktop Python since 2.5 and then it was a fiddly process of 'freezing' exe's, is that still the recommended way with Python 3?

I use pyinstaller to build windows executables directly from Linux using this docker image: https://github.com/cdrx/docker-pyinstaller

Between Qt and Python there is a huge amount of cross platform support. For example, I found out that Qt supports bluetooth, which currently has no other cross platform support in python (the unmaintained pybluez has all sorts of issues).

Re: DearPyGui

#57

Post by milesvp »

cma wrote: post #44
corysama wrote: post #28

Earlier quoted context omitted.

In games it is far more important that performance be consistent than that it is be better on average . Spikes in performance mean hitches in the presentation. Hitches are terrible user experience. Better to run a solid 30 fps 100.0% of the time than to run 60 99% of the time and hitch every 2 seconds.

Hitches are still bad, but consistency is less needed with variable refresh rate monitors. Also, battery life/power usage is an important factor that can push you away from focusing only on consistency.

Something that people don’t realize is that standard deviation in framerate trumps frame rate in perception of smoothness of animation. It’s something that NaughtyDog has blogged about, and something really well known in the Amiga demo scene.

I’ve seen 8 fps marquees that looked smooth as silk the frame rate SD was so low. It’s amazing what the brain and eye tracking will do to make things look right.

Re: DearPyGui

#58

Post by emmanueloga_ »

mellosouls wrote: post #9

I can't find a clear explanation of "immediate mode" GUI creation (which this library enables) but it appears to be the sort of paradigm that pre-dated object-oriented and event-driven interaction handling that became the norm in the mid 90s (especially after the popularising of dev tools from Borland and Microsoft eg. Visual Basic etc), so I guess it is a formalisation of the procedural (?) methods from the era prec…

from the docs [1]:

"A common misunderstanding is to mistake immediate mode gui for immediate mode rendering, which usually implies hammering your driver/GPU with a bunch of inefficient draw calls and state changes as the gui functions are called. This is NOT what Dear ImGui does. Dear ImGui outputs vertex buffers and a small list of draw calls batches. It never touches your GPU directly. The draw call batches are decently optimal and you can render them later, in your app or even remotely."

This is cool, I had that misunderstanding myself (immediate mode vs immediate rendering)

1: https://github.com/ocornut/imgui#how-it-works

Re: DearPyGui

#60

Post by snypher »

Jhchimaira14 wrote: post #59

Pretty crazy how this library blew up in the last 48 hours. Lol

Is this due to being posted here or am I missing something? As an aside, it would be nice if the title was or similar to:

'DearPyGui: A GPU Accelerated Python GUI Framework'

Post reply on HN