@GDCPresoReviews I dunno about that particular case, but I recently encountered the original paper describing the rsync algorithm (1996) and it’s quite readable and a good example of spending some CPU (and extra round-trips) to reduce the amount of data transferred.

https://www.andrew.cmu.edu/course/15-749/READINGS/required/cas/tridgell96.pdf

@daniel_collin @rovarma @sschoener Yes! Users are (approximately) always right when they describe a problem, but often don’t have full context to identify a “good” solution.

It’s common for feedback to start off in “solution space” but pushing the conversation into “problem space” is usually a good idea.

@rovarma @aras How do you handle text!?

We also use a fair amount of the "fancy" SVG-y brush/pen/path APIs in QPainter so reimplementing all that seems quite expensive.

My dream would be a backend based on ImDrawList from @ocornut but I fear the requirements may be (correctly) out of scope for dear-imgui. But perhaps one day?! 😅

@StompyRobot @ben Any references for tools that behave more like you want - particularly how they work/are implemented?

I don’t recognize the term “optimizing fair flow graph” and I’m not super familiar with implementation details around production-quality purity or laziness (very familiar with “imperative script” though 🤣)

@rovarma @aras For the perfy parts, are you using Qt’s GL wrappers, or directly writing to GL APIs? IME advantage of the former is the insanely rich QPainter APIs, but there are many extra complex layers so perf isn’t guaranteed.

We are doing the first approach in one of our tools, but the perf control surfaces are very indirect. But QPainter is hard to quit! (Particularly for text and curves; our target is a high-complexity pretty-high-fidelity “canvas ui” so thise are important.)

@dotstdy @superfunc FWIW they directly address the question in the FAQ that’s linked from the primary announcement (I missed this the first time I saw it) and one of the main reasons they cite is similarity between ts and go, because they expect to maintain both implementations simultaneously for a long time. Not an expert in either language but that seems pretty reasonable!

https://github.com/microsoft/typescript-go/discussions/411

@chandlerc
Thanks, that’s helpful! Inlining and forwarding was where my head went, but I hadn’t considered the grow case intertwining construction with array logistics, making the codegen even harder. (“Hmm there’s no room for that, uh I guess I’ll balance it precariously while I shuffle things.”)

Seems like that could maaaaaybe be dodged by relaxing no-copy-no-move (which has to happen for all the other elements in the array anyway?) but something tells me that might upset diehard emplace-ers.