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-08294559d6a971f74472cc2fca7cce724cdd9e055ac46f6e38c4633b27a97bcbR25-R33
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-when-drawing-many-rectangles-c-gtkmm
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
---
[email protected] - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/SQGTXOKHMPIVIENAPUQWPXJDHXIWPMJW/
