First off, I very much appreciate any effort to move away from Tcl/Tk :)
On 28.09.2024 14:01, Miller Puckette wrote:
I don't know if any of you remember this, but at the first Pd convention in 2004, someone (I forget who) had the idea of replacing the Pd front end by using the tcl parser
I think this is actually what the rest of us is trying to avoid :) The overall goal of the recent GUI refactoring efforts was explicitly to move away from Tcl-specific code towards a more general interface. pdgui_vmess() has only been the very first step. IMO https://github.com/pure-data/pure-data/pull/1765 goes into the right direction.
In general, for all built-in objects the core shouldn't have to tell the GUI how to draw it. That's the job of the GUI! I.e. we shouldn't say "draw these lines with these colors at these positions, then draw a circle with radius X and position Z", instead we should just tell "draw a 'bang' object with this size at this position". Here's a good example: https://github.com/pure-data/pure-data/pull/1765/files#diff-08294559d6a971f7...
The big question is how to handle externals that want to create their own UIs by sending Tcl commands. Generally, our UI does not know about these, so we probably need to provide raw drawing commands. Ideally, these drawing commands should not be actual Tcl commands, but more generalized. However, this would mean that all existing externals that send Tcl commands would need to be updated. We could keep a Tcl parser just for externals, at least for a transition period.
Well, I made a stab at doing the same thing with GTK4 - you can grab it here: http://msp.ucsd.edu/tmp/2024.09.28-pdgtk.tgz . It's about 1200 lines of code and does only a coupe of very basic things, but it allows us to guess what it would entail to do the whole job. Of the 325 calls to pdgui_v[a]mess in the PD source, it takes care of about 10 I think.
Why did you pick GTK specifically? What is the 2D canvas implementation like? IMO we must absolutely evaluate the quality of the canvas implementation because it's absolutely critical to performance. The Tk canvas implementation, for example, is rather bad and GUI performance on large patches with lots of GOP is horrendous. Qt, on the other hand, has a very optimized 2D canvas implementation ("QGraphicsScene") which can easily handle thousands of objects. (All items are kept in a BSP tree so it can quickly determine which area of the canvas it needs to redraw after an object has changed.)
I see that you're using Cairo. Have you tested with lots of primitives? Reports like https://stackoverflow.com/questions/63114699/extremely-bad-cairo-performance... don't sound encouraging...
The most important questions is: what happens if you change something in the canvas? Does it need to redraw the whole thing? Or can it figure out which parts it needs to redraw?
---
Finally, I see that the GUI would still be in separate process. Why is that? All other audio applications I know simply run the UI on the main thread. Instead of sending the GUI messages over a TCP socket, we can just put them on a (lockfree) FIFO which is polled by the UI thread.
(I'm curious: what was the reason for running the GUI as a separate process in the first place?)
The only reason I can think of for running the UI in a separate process would be remote GUIs. However, out-of-process GUIs can be implemented on top of in-process GUIs, using the the same binary on both sides:
1. the core keeps throwing messages on the FIFO, but instead of an UI thread, we have a network thread that forwards the messages to a TCP socket.
2. the GUI just runs the UI threads, but instead of an audio thread, we have a network thread that reads messages from the TCP socket and throws them on the FIFO.
Running the GUI in process would not only remove all the networking overhead, it would also allow to integrate custom UI elements (e.g. an openGL visualization of an ambisonic field). This would be a real game changer! Some externals, like FluoCoMa, are already struggling with Pd's limited GUI abilities. It would also massively simplify VST plugin hosting.
Christof