Another question I have: how is zooming implemented? That is one of the biggest pain points of the Tcl/Tk canvas.
In Qt you can transform the whole canvas view with simple function calls. For example, to zoom the canvas you just have to call the "scale" method: https://doc.qt.io/qt-6/qgraphicsview.html#scale.
(I have recently written an editor for my 2D game engine and it lets me zoom in and out of the tile map seemlessly. The tile map itself can easily consist of ten-thousands of objects and performance.)
Basically, what I want to say is: we need to carefully compare the performance characteristics of different UI frameworks, otherwise we may end up in a dead-end street.
---
Side note: another neat feature of the Qt canvas is that it's split into "model" (QGraphicsScene) and "view" (QGraphicsView). This allows for cool things like having multiple independent views into the same canvas. For example, you could split the window to show differenct sections of the same patch, similar to how a code editor can show multiple sections of the same source file.
On 30.09.2024 10:30, 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://github.com/pure-data/pure-data/pull/1765/files#diff-08294559d6a971f7...). 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!
I did float (a couple of years ago?) the idea of simply having one process with a GUI thread. Iohannes quickly warned me that that would invalidate a Pd variant he was working on - I forget what exactly. So I dropped that idea.
I would be curious to know about IOhannes' objections. I definitely think you were right back then :)
The winning feature of my proposal is that it can be done without disturbing the existing Pd at all. I could even add a gtk subdir to the Pd source tree and simultaneously maintain both GTL and TK versions for years while the kinks get worked out of the GTK one.
"... Why did you pick GTK specifically? What is the 2D canvas implementation like?"
My solution doesn't use the GTK canvas - it uses Cairo directly. OTOH it does redraw the entire drawing area offscreen - there's no region-invalidation as there was with the original Max (1988). This could be an efficiency problem, but it wouldn't be hard to put region-invalidation back in if indeed it turns out to be an issue.
I think region-invalidation will be absolutely crucial, especially for complex GOP GUIs.
OTOH I don't know whether Cairo will prove to be efficient enough for our purposes.
And... as to GTK4 versus QT, I can't see much reason to prefer one over the other, although I got a bad impression of QT after seeing what happened to LXDE when they migrated it to LXQT. The result was just... ugly. I also much refer GTK4's licensing --- it's hard open source as opposed to QT's attempting to take both sides on the issue. In my experience the hard-open-source projects such as linux or indeed pd itself tend to outlast the sort-of-open-source ones.
IMO Qt looks pretty great and it does a good job of emulating the individual platforms' native look. Have a look at SuperCollider's UI! I wouldn't call it ugly. It's just a matter of styling. It would be easy to recreate the current minimalistic Pd look.
I agree that GTK's licensing policy is more attractive. On the other hand, SuperCollider has been doing fine with Qt for quite some time now. I have to say that I don't have first-hand experience with GTK, so I can't really compare the two. I just had very good experiences with Qt building complex UIs.
Anyway, I'm not sold on this way of doing things - I only put a week into it so far and have to tend to other stuff for this coming week, so there's time to think about all this.
cheers
Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/RLRCVHGFFIX...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/MCOBZHZPHPH...