going back to an earlier question, which I think is a (or the) central
one...
On 9/30/24 10:30 AM, Christof Ressi wrote:
On 30.09.2024 09:43, Miller Puckette wrote:
Well, to quote out of order:
"... for all built-in objects the core shouldn't have to tell the
GUI how to draw it."
Well, I think that is a fundamental point on which you and I
disagree. I tried once with Max/FTS (19890-1994 or so) to do
precisely that and the problems of keeping the graphical layer and
the real-time layer in sync ended up overwhelming. In particular,
the graphcal layer had to wait while the real-time layer verified
whether object creation succeeded or not which made the loading of a
patch from file impossibly slow, unless the GUI layer had its own
instance of Pd running right inside it in parallel with the real
one. And that - keeping parallel copies of the same complex data
structure in sync as it was changed from both sides - was also too
much to manage.
I'm not sure I understand. Why would you need to wait for the UI to be
in sync? What is the difference between
a. sending "draw X, Y, Z" to the UI
b. send "draw W" to the UI, which in turns draws "X, Y, Z"
You just shift the responsibility, but there is no fundamental
difference. Please have a look at the linked draft PR form IOhannes!
I've already linked the example for "bang"
(https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1765/files*diff-08294559d6a971f74472cc2fca7cce724cdd9e055ac46f6e38c4633b27a97bcbR25-R33__;Iw!!Mih3wA!CWqblkk1v8fW-0zvFNxIHZDgxp4Gw-Wlvsuq4ZecKIr2BkkCSPYf7y4Tu5tSXJ5bYkyjSzbKVHNGWg$
). Look at how many drawing commands we're currently sending to the UI
for such a simple object! With the draft PR we would only send 1/10th
of the commands even for the most simple objects. For more complex
objects, like VU meter, it can be orders of magnitude.
But it's not only about the drawing commands itself. Sending commands
like "draw a line", etc., mandates that the object is constructed of
individual primitives on a canvas. But in a framework like Qt a
built-in Pd object can just be a single widget (which knows how to
draw itself). Of course, having one widget in a canvas is much more
efficient than having dozens of individual geometric primitives!
Suppose we replace "draw X, Y,Z" with "draw button". I think this then
spins out in either of two possible ways:
(1) the "button" widget on the GUI side now takes care of mouse-hit
detection and making itself flash (and eventually widgets with text can
grab focus, handle copy/paste, etc). In this case the GUI widget has to
maintain a connection with its corresponding object in Pd. This gets
very complicated when, for instance, changing text causes inlets or
outlets to appear, which perhaps on the Pd side the text is getting
hammered by messages from elsewhere at the same time. Distributed
database management, anyone?
(2) it's just a drawing with a tag, not an active widget; perhaps mouse
hit detection is done in the GUI but everything else in Pd. In this case
it's not a big enough change to make much difference, except for this
noisome one: "GUI externals" such as the knob now have to load dynamic
libraries into two programs, instead of just one.
Depending on which scenario we want to consider (or perhaps this is
somehow a false choice) we can go into more detail about this...
cheers
M
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/6WFFUCOQCFNEKCVI2QTY6XYZN6QAPFZY/
