Hi,
I am having a poor GUI performance with Pd under Windows 10 and an Notebook with Nvidia GTX980M graphics card.
Starting with an empty patch placing and dragging objects is very laggy.
This is the same for Pd-0.47-1, and Pd-extended 0.43.4, therefore I suspect it's a problem with Tcl/Tk?
DSP and internal message handling works fine...
Does somebody have the same problem or a fix for this?
Thanks, Matthias
On 10/02/17 11:53, Matthias Kronlachner wrote:
Starting with an empty patch placing and dragging objects is very laggy.
Does somebody have the same problem or a fix for this?
i had similar problems with various versions of pd on various linux-versions, with the free radeon driver. it was better using the non-free amd-drivers, and "solved" by using the free drivers for the internal intel-graphics (g45). i think it has something to do with some 2d graphics-operations needed by tcl/tk not beeing accelerated.
maybe using other (newer or older) graphicsdrivers might help.
bis denn! martin
On 10/02/17 12:47, martin brinkmann wrote:
On 10/02/17 11:53, Matthias Kronlachner wrote:
Starting with an empty patch placing and dragging objects is very laggy.
Does somebody have the same problem or a fix for this?
i had similar problems with various versions of pd on various linux-versions, with the free radeon driver.
meanwhile i have solved this problem by using the free radeon driver (xubuntu 14.4, with xenial kernel), and writing a minimal xorg.conf containing
Section "Device"
Identifier "radeon whatever the cards name is"
Driver "radeon"
Option "AccelMethod" "glamor"
Option "ShadowPrimary" "on"
Option "DRI" "3"
EndSection
the important option was ShadowPrimary (which needs glamor though). this option enables "fast cpu access to pixel data". maybe there is a similar option hidden in the settings (directx?...) for other graphicscards on other os too...
...after having added a global "gui refresh metro" to minimize updates of moving sliders etc. to my patches, everything works now (again) fine without that...
what is the global gui refresh metro ? and do other graphics cards have different options besides ShadowPrimary that allows fast access to pixel data? Can look it up but seeing that you have recently been dabbling in it...
On Mon, Mar 20, 2017 at 4:48 AM, martin brinkmann mnb@martin-brinkmann.de wrote:
On 10/02/17 12:47, martin brinkmann wrote:
On 10/02/17 11:53, Matthias Kronlachner wrote:
Starting with an empty patch placing and dragging objects is very laggy.
Does somebody have the same problem or a fix for this?
i had similar problems with various versions of pd on various linux-versions, with the free radeon driver.
meanwhile i have solved this problem by using the free radeon driver (xubuntu 14.4, with xenial kernel), and writing a minimal xorg.conf containing
Section "Device" Identifier "radeon whatever the cards name is" Driver "radeon" Option "AccelMethod" "glamor" Option "ShadowPrimary" "on" Option "DRI" "3"
EndSection
the important option was ShadowPrimary (which needs glamor though). this option enables "fast cpu access to pixel data". maybe there is a similar option hidden in the settings (directx?...) for other graphicscards on other os too...
...after having added a global "gui refresh metro" to minimize updates of moving sliders etc. to my patches, everything works now (again) fine without that...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 05/04/17 16:15, Billy Stiltner wrote:
what is the global gui refresh metro ?
that is/was my (temporary) solution for the slow gui: a metro at 8 hz sending bangs to a global send and a [f] receiving these bangs before every slider/number/ which is updated via midi-ctl, counters, sequencers, whatever. while directly connecting a few midi-controllers to sliders could easily stall the gui (when the knobs are moved), this solution looked not very beautiful, but caused no dramatic cpu-spikes, even without 2d hardware acceleration.
and do other graphics cards have different options besides ShadowPrimary that allows fast access to pixel data?
i suppose so...
Can look it up but seeing that you have recently been dabbling in it...
only with my radeon card under linux, until i had success with the settings in xorg.conf.
Option "AccelMethod" "glamor" Option "ShadowPrimary" "on"
Another solution could be to reduce the maximum number of messages sent to the gui per tick. IIRC this is a #define somewhere in the sources and you'd have to recompile pd, but I did this once on an advice of Miller and it worked very well (except for the slow gui framerate).
Apart from that there is an external called speedlim (you could also build that as an abstraction using vanilla) which might be more elegant than using a global metro.
-- Orm
Am Donnerstag, den 06. April 2017 um 12:12:42 Uhr (+0200) schrieb martin brinkmann:
On 05/04/17 16:15, Billy Stiltner wrote:
what is the global gui refresh metro ?
that is/was my (temporary) solution for the slow gui: a metro at 8 hz sending bangs to a global send and a [f] receiving these bangs before every slider/number/ which is updated via midi-ctl, counters, sequencers, whatever. while directly connecting a few midi-controllers to sliders could easily stall the gui (when the knobs are moved), this solution looked not very beautiful, but caused no dramatic cpu-spikes, even without 2d hardware acceleration.
and do other graphics cards have different options besides ShadowPrimary that allows fast access to pixel data?
i suppose so...
Can look it up but seeing that you have recently been dabbling in it...
only with my radeon card under linux, until i had success with the settings in xorg.conf.
Option "AccelMethod" "glamor" Option "ShadowPrimary" "on"
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/04/17 12:27, Orm Finnendahl wrote:
Apart from that there is an external called speedlim (you could also build that as an abstraction using vanilla) which might be more elegant than using a global metro.
my idea was to have exactly one event which updates all gui-elements, instead of triggering a gui-update with every event (even if it is speedlimited). maybe i am wrong, and pd 'quantizes' the screen updates anyway (i have not studied the pd sourcecode), so that a few gui-redraws at (more or less) the same time are not worse than one? and of course i bypassed the gui for the dsp-calculations to use all incoming events without any limit.
what is the global gui refresh metro ?
that is/was my (temporary) solution for the slow gui: a metro at 8 hz sending bangs to a global send and a [f] receiving these bangs before every slider/number/ which is updated via midi-ctl, counters, sequencers, whatever.
-
Billy Stiltner -
martin brinkmann -
Matthias Kronlachner -
Orm Finnendahl