haha, yes - it’s just a quick copy/paste of a bit of old code to see if it worked…
I know very little about how GUIs and frame buffers work, but instead of the CPU, can a GPU be used to compute the frame buffer instead? I would imagine that’s much faster? Would the transfer of data from GPU to CPU really slow it down?
I’m getting 140fps displaying 600*400
Life with DynamicGrids.jl.
Seems very stable so far. This is awesome.
This looks really cool, and I’m so glad you are playing . It’s always been on the back of my mind that MiniFB would make a great backend for Luxor, allowing Luxor to provide realtime visualisations, and simple interactivity. It’s really nice to see that the integration is so simple.
If you don’t mind, I’d like to add this code as an example in the MiniFB repo. Thanks!
can a GPU be used to compute the frame buffer instead?
Yes, of course you could. Things like GLFW mentioned upthread help you do that, Many parts of modern operating systems do frame buffer calculations on the GPU. However, the point of MiniFB is that it is very simple, and that is it’s appeal. So it is good that it does not have any advanced functionality – if you wanted that, there are many other existing libraries that do those things very well.
Just tried it out. So straightforward and easy to get the example working. Suggestion - put the random noise second and the colorful animation first in the manual.
Yes, it’s a nice simple extension that will be very useful. I’ve tidied the code a bit (removed global variables…:)) so I’m very happy for you to use it…!
I think most GUI frameworks use complicated scenes structure to avoid redrawing as much as possible, that’s why they were already quite snappy 20 years ago. That said I think there’s some moderns libraries that tries the “redraw everything” route on the GPU, which simplify things but also risk to make your laptop sound like a reactor.
Not a MiniFB question as such but it works well even in WSL2 which is great.
But if I run the MiniFB code in VSCODE’s repl by starting “julia” from bash then MiniFB.jl works via the xserver that I set up
But if I run it through the Julia extension and send code to the Julia repl via Ctrl-Enter then the windows doesn’t show up. And there is no error message.
Just in case someone has this worked out. Otherwise I will file an issue with vscode extension later since it’s not an issue with VScode but how vscode julia start the julia repl.
and therein lies the question.
Why didn’t miniFB just build around OpenGL using GLFW in the first place ?
At this point OpenGL is ubiquitous and i’ve never had problems bringing up GLFW in any language I’ve tried it in.
Then you would have the GPU taking care of the bit display (which is a big win!) AND you could use miniFB with 3D graphics.
I absolutely LOVE the idea of MiniFB, but I really think this is an interface problem. We didn’t need a miniFB library, we need a MiniFB interface sitting on top of something like GLFW.
This sounds like a comment that should make me volunteer to write some code, doesn’t it ?
Well, that already exist in big parts in Makie & GLMakie, which is exactly this…
Could be more modular to tailor to use cases outside plotting - I never got around to do these refactors, but should be fairly trivial to factor out the windowing bits.
Btw, I also tried to make Observables.jl the goto signal abstractions for UI, which is also used across the Interact ecosystem & in WidgetsBase.jl.
So it’d be quite easy to swap out the windowing library, and make other widget libraries rely on a window event struct like: https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/types.jl#L23
It’s funny you should mention this , because i often look at Makie wishing i could use it as a general purpose 3D graphics library.
Admittedly I haven’t looked very hard to see if this is possible, I tend to get lost as i go through the code. it’s kind of a large project isn’t it ? lol
Yeah, I does seem so^^
I can see how it would be hard to see from outside, but the core could be factored out quite easily in a week or so (by me I guess)…
I currently in the feature phase, so no backend work will be done for quite some time… Maybe next summer or so, I will have time to factor out the OpenGL parts nice and square
I plan to heavily use ShaderAbstraction, to make a framework that works nicely with WebGL/OpenGL/Vulkan alike
If you just want to display an image you have in RAM you shouldn’t really need to go through the GPU. But yeah, for more complex application it makes sense to use the GPU, it’s just not what MiniFB is for.
I believe the point of minifb is minimalism and reduction of dependencies. GLFW and OpenGL rely on having a reasonably large number of libraries available and working (which isn’t always the easiest to set up if you’re on a less common system), but minifb relies on much fewer working pieces. For many simple projects, especially those which don’t need a GPU for rendering (or do, but don’t mind the extra data copy), minifb is more than sufficient.