you mean in opengl?
Ico
João Pais jmmmpais@googlemail.com wrote:
I'm not a coder, but I could also give a sugestion, which I haven't tried myself for lack of time: how about circumventing tcl/tk, by writing your gui in gem? There was once a report that it's much faster - I can only say it does if you're using data structures inside a gop.
The problem is that Tcl/Tk is not the bottleneck when it comes to array redrawing. Its how pd sends draw commands. Redrawing a big array once could result in literally 500KB of Tcl code generated by Pd and sent to the GUI.
So whether you use Tcl/Tk, Qt, JUCE, or whatever, you'll have to address that issue to get any real gain. I'd say the best place to start is try updating the array drawing code so that it just sends a simple command to Tcl and let's Tcl do the drawing work. You could easily make that an external and use it with any version of Pd.
.hc
Interesting. Still, this does not resolve the issue of a large number box on the screen being updated rapidly taking up a lot of CPU (it scales exponentially with growing font size and in this case I suspect Pd's output is minimal, amounting to change in the displayed set of characters).
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
I guess so (haven't that much experience with gem). only know that a small square with some data structures with geographical positions took at least 10% cpu in my thinkpad. with gem it took nothing.
you mean in opengl?
Ico
João Pais jmmmpais@googlemail.com wrote:
I'm not a coder, but I could also give a sugestion, which I haven't tried myself for lack of time: how about circumventing tcl/tk, by writing your gui in gem? There was once a report that it's much faster - I can only say it does if you're using data structures inside a gop.
The problem is that Tcl/Tk is not the bottleneck when it comes to array redrawing. Its how pd sends draw commands. Redrawing a big array once could result in literally 500KB of Tcl code generated by Pd and sent to the GUI.
So whether you use Tcl/Tk, Qt, JUCE, or whatever, you'll have to address that issue to get any real gain. I'd say the best place to start is try updating the array drawing code so that it just sends a simple command to Tcl and let's Tcl do the drawing work. You could easily make that an external and use it with any version of Pd.
.hc
Interesting. Still, this does not resolve the issue of a large number box on the screen being updated rapidly taking up a lot of CPU (it scales exponentially with growing font size and in this case I suspect Pd's output is minimal, amounting to change in the displayed set of characters).
Ico
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
I guess so (haven't that much experience with gem). only know that a small square with some data structures with geographical positions took at least 10% cpu in my thinkpad. with gem it took nothing.
you mean in opengl?
I think this would then be probably done in vanilla OpenGL, not Gem. And I agree this could potentially work but is perhaps not as easily implemented as with using JUCE where a lot of APIs are already prebuilt for you. The same may be the case with Qt but I don't know for sure as I haven't messed with it very recently.
Ico
I think this would then be probably done in vanilla OpenGL, not Gem. And I agree this could potentially work but is perhaps not as easily implemented as with using JUCE where a lot of APIs are already prebuilt for you. The same may be the case with Qt but I don't know for sure as I haven't messed with it very recently.
I've done it in pd-extended. it's true, the initial step to do a full gui will be a hassle, because you'll have to program the interface yourself. but if that's done carefully, it should pay up afterwards.
or just make a gui in processing, csound or supercollider through osc :)
I've done it in pd-extended. it's true, the initial step to do a full gui will be a hassle, because you'll have to program the interface yourself. but if that's done carefully, it should pay up afterwards.
The lingering question is whether you wish to encumber GPU with editor interface (if you are using Gem for visuals) rather than visuals themselves. With some cool voodoo design one could probably disable patch updating to allow GPU to focus on the visuals alone but that would defeat the purpose of having easy-to-edit-runtime gui in the first place.
or just make a gui in processing, csound or supercollider through osc :) No virus found in this incoming message.
Sure, but that IMHO can make it even less user-friendly than existing implementation as it adds an additional point of potential failure.
Best wishes,
Ico
-
Ivica Ico Bukvic -
João Pais