Hi people, i made makepad. i can answer questions
# of-graphics
r
Hi people, i made makepad. i can answer questions
🔥 1
👋🏼 1
🎉 5
g
@Will asked:
I’m actually mystified at the real-time compilation. Is that because it’s a completely different compiler using a Rust skin?
a
@Rik Arends Couple of questions came up in the original thread you might want to look at.
r
oh right. this thing has threads
So the realtime compilation is only inside what we call 'live macros' its little chunks of the rust code that i can hot-swap in a running process. Its shaders, styling, layout. that kinda stuff
Not actual Rust code
you need the desktop IDE and recompile
@Aria Minaei i hope i answered things
i
What strategy did you use for font rendering? Anytime I’ve looked into writing a complete rendering stack I’ve been shocked by how crazy just trying to render high fidelity Unicode is.
r
At first i used MSDF, which worked great actually except on lowDPI, then we switched to 'pathfinder-2' style GPU atlasses. So we GPU accelerate (but not super fast) render our atlasses for a certain subpixel position+size
As for 'but what about internationalisation' i have simply parked that problem until we are big enough to fund that
The gain of doing a UI the way we are is already much greater for us than the loss of that stuff
So yes you are right. Doing everything is prohibitive. I'm simply going to redefine my market/usecase so i don't have to care from the start.
i
Yeah that’s fair. We played around with MSDF as well but balked when we realized the textures would be ~40gb for unicode haha. Interesting that it did poorly in lowDPI, we hadn’t played with it long enough to discover that one. 🙂
r
yea so we load our own TTF's and render the atlasses entirely on demand. So luckily no 40gb textures
👍 1
And yes our lowDPI stuff still looks like crap because we haven't implemented the pixelhinting things
But atleast we have a clear path to do so now
Which MSDF didn't really offer
@ibdknox good work on inspiring the world on improving IDE's btw. I always keep track of what yr upto
i
Cheers! I’ve been following makepad as well 🙂 The first time I pressed alt in the editor, I was shocked by how wonderfully smooth it was compared to pretty much anything else I’ve seen. Can’t wait to see where you take the foundation you’ve got now!
r
Thanks! We're going for 'new shadertoy' because shaders give me a live backend, also the system has some really interesting answers to improve shaderprogramming. Things will rapidly happen now.
👍 1
With Rust (and Wasm) its the first time i actually have breathing room in my CPU performance. On native i'm regularly in the 1-3 millisecond per update/edit/fold cpu time
i
Yeah, I’ve found ways to get JS there, but you can’t write anything that actually looks like JS to do it. The backend for the language we’ve been writing is built so that it can pretty trivially emit whatever. It’ll be interesting to try some c-like JS vs Rust vs Rust compiled WASM vs direct to WASM at some point 🙂
I don’t have SIMD and a few other things I’d like to have in JS-land, but it gets us instant hotswapping across the whole system.
I’ve been thinking of it as a tiered thing. Develop in the dynamic, slightly slower mode, then spit it out to rust on deploy.
r
Yea that would be the ideal situation. I'm solving it by moving certain domains (UI styling, shaders, layout) into the 'live' coding, and the rest will simply have to wait for a Rust recompile cycle. Which isnt THAT long to be fair.
It's very hard to know when you want what yr livecoding to be 'as fast as it gets' or interpreted. The gap is so vast, especially in creative domains
The most inspiring solution i have yet come across is leonard ritters ' 'Scopes' language. It keeps llvm online to runtime compile bits of 'eval' language
Problem is that as soon as you move your performance domain into 'really needs LLVM optimisation' yr kinda stuck waiting for that. Because running it in 'slow' mode doesn't really do it anymore. I made makepad run on Rust-debug builds by building a nearly 10x performance window in it (ie i use <10% cpu at all time)
Now when i compile it for the Quest in wasm i need every ounce of that performance I just 'barely' scrape through the door there.
i
Yeah, I’m trying to avoid relying on LLVM primarily by generating code that needs very little optimization to be fast. We compile the language down to a very small set of semantics around just bare arrays and simple primitives.
r
Yea i considered that option, but luckily Rust saved me from going down the even longer path 🙂 Looking forward to see what you come up with. Still eve-ish? Or something new
i
Something new. Not explicitly trying to go for accessibility this time, though where we’re landing may end up that way by accident. Mostly trying to see what happens if we tried to make just ourselves super human. We’ve learned a lot since the end of Eve and figured out how to solve a bunch of the issues we ran into. E.g. I don’t think performance is going to be a problem this time heh.
r
Yeah im definitely not going for accessibility. Makepad is mostly an excercise in how to make building code-editors, ide's an complex designtool UI performant, and suck least to write. Any fallout it can gather for broader appeal will have to come from a domain like Shaders.
s
I should really invite L Ritter here... I'm not sure if he knows about the community but it seems like he might be into it
👍 2
The Quest support looks pretty slick, how far do you want to go with VR support and do you plan on doing a native VR app at some point (either targeting Quest, OpenXR, OpenVR or Rift/Rift-S)?
r
VR support right now is more of an experiment. I've always said the UI tech would work in VR, so now we are proving that. I think it could be really nice 'extra' if our webbased shader editor has a VR mode that also works. For now we stick to webXR, but integrating a nativeVR platform probably isin the order of a week of work so its not that hard.
Makepad already compiles native for mac, linux and windows, and we have a native build for the quest 'to be completed' as well so its not super hard
m
Hi Rik, since you're living in the Netherlands.. have you got a WBSO-subsidy for makepad? I use it for my FoC-project
r
Hi, not at the moment, makepad is in 'startup' mode. But i might apply since i think it does fit
Btw the problem with eeking performance out of things like react + canvas is there is almost no space to get more performance. Wasm also isn't the killer-feature alone. Its Wasm+WebGL(webGPU soon) otherwise its game over
I have a highly optimised path to the GPU from Wasm by using 'instanced arrays' so my call overhead into webGL is miminised. I also use a form of executable graphics command buffers (in JS) to remove any calloverhead between wasm an JS there might be
IMHO thats the only path available on web to get anywhere near the performance you see with Makepad.
I still have a webGL 2 feature (uniform buffers) that could help a bit, but i'm not really drawcall bottlenecked