the damned GUI - was:[PD] Pd in white on black and OSC

[chris clepper]

At 6:31 AM -0800 11/21/03, <ben at 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.