On May 25, 2009, at 9:17 PM, danomatika wrote:

On Mon, 2009-05-25 at 21:09 -0400, Hans-Christoph Steiner wrote:
Another thing to try is writing the GUI in a toolkit that is optimized for speed. I don't know if you have a GPU, but if you wrote Pd GUI objects using something like togl or tkzinc, both use OpenGL, that could also help.

That's a little more then I mean ...

When I first started using Pd I naively thought that num boxes and sliders somehow were "skipped over" or turned into [clip] objects when in -nogui mode.

I also thought that, its not true?

I don't really need an accelerated gui as I like what Pd has now, I just think these basic elements should not peg the cpu in -nogui mode. That way I can work in a nice graphical environment to create the patches, then run said patches in the minimal environment and not get penalized for using gui objects/parameters.

I started work on the 'tkwidgets' library a while back to provide simple Pd interfaces to the Tk widgets. The IEMGUI code is quite complicated. I have an almost complete API for Pd<->Tk that includes code for a standard way of resizing the GUI objects with a mouse. I think this could serve well as the basis for a GUI library that does behave like a [clip] in -nogui mode.

For example, instead of a number box, we could make a Tk "label" object in Pd which accepts anything you throw at it and displays it, i.e. it would even display spaces and different fonts even! Shocking, I know. I think there could be a working Pd object based on label in a day or two of work, refinements would take longer, of course...

.hc


----------------------------------------------------------------------------

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie




_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to