At 6:31 AM -0800 11/21/03, ben@ekran.org wrote:
I think this would be the only alternative other than tcl/tk myself.
I've been using tcl/tk for many many years now and It can be very very fast. The bottom line is not just that the toolkit is slow, its the damn fact that the PD patcher is a vector drawing. This stuff is just never all that fast in a toolkit (not enough need for them to optimize for it is there?)
How about replacing some of the vector drawing with bitmaps? Pd doesn't do a whole lot that really requires vector drawing - there are no fancy Bezier curves and it doesn't even scale things very well (or at all in certain cases). I'm thinking that the GUI elements like sliders and buttons would be perfect for having bitmaps (gee you ever notice how every single other app uses them for graphic interfaces???). This would allow for even more variation in the look and feel of pd, and all windowing systems have a good deal of optimization for blitting pixmaps to screen and so forth. How capable is tcl/tk for doing something like this? Of course, this is not an answer to the real underlying problems with the Pd GUI, only yet another in a series of patches that sidesteps issues (it would potentially make Pd better looking though!).
Of course I would not want to loose any great features, like dynamic patching, and dyanmic GUIS, I would like to keep all this (possible in SDL/GL?)
Yes. Here's my thoughts on how to do a GL patcher setup:
- objects would be divided into two classes: static and dynamic
- edit mode would do straight GL immediate mode calls
- switching out of edit mode would build a display list of static elements
- dynamic objects, like arrays, would use vertex arrays for best performance
- you could even design all of the UI elements in Maya and save them
as .obj files
It's basically just replacing the tcl/tk calls with GL ones, and keeping track of windows in a context (maybe GLUT is deficient here). Hell, GL is cross-platform enough that foregoing a lib like SDL wouldn't be that big of a deal compared with the entire retooling of the GUI. Also, you've got a pretty capable team of GEM coders that have worked on cross-platform GL for years as a resource.
And for the record (for those not running on all platforms) windows takes the prize for fastest GUI patching. My ol 800 is great for it, In fact so much better I do most patching in (ick) windows. Linux is next, its pretty good, ok for almost everything, but I'd guess about 30% behind windows. OSX is almost useless for large copy-paste operations and GOPs on the g4 733, so slow I've been thinking about a performance environment where you use a windows/linux machine to run the GUI, and the PD DSP on the mac. Lots of extra effort, but perhaps worth it to get some nice gui feel...
Ahh, the joys of throwing pixels right into the framebuffer with next to no management. It gets you 'Snappy'®TM, but little else. Obviously, little consideration was made for relatively antiquated toolkits like tcl/tk when designing Quartz (there wasn't even much consideration of the classic Mac toolkit either, but that's a whole different subject). And thus we have arrived at the current situation where the old stuff looks bad and performs even worse, while the eye candy is pretty well optimized. Exposé seriously rocks on that 733 and cheap Geforce2MX, but drawing dinky little outlines of squares and numbers inside them requires more resources! And here's a truly mindblowing, fucked-up stat: GEM handles decompressing and display of a DV stream more efficiently than Wish drawing two spinning number boxes at the corners of a 720x480 patcher!!
cgc
Enough of me blabing.
B.