Hello dear Pd users and developers,
I have a basic problem: on my system (debian sid, i386) Pd 0.43+ as well as Pd-extended 0.42.5 both have very low gui performance (sometimes it takes couple of seconds to update). It's happening even if I have one object in a maximized window and try to move it with DSP off.
I think this can be somehow related to the GUI rewrite (fonts? UTF-8 support?), because Pd-vanilla 0.42.x was running quite well.
I've also tried to compile Pd-vanilla 0.43.1x from upstream source, but got the same result.
What might be the cause? Did anyone experience something similar?
Thanks for reading, YurB
Le 2011-10-16 à 17:17:00, Yury Bulka a écrit :
I think this can be somehow related to the GUI rewrite (fonts? UTF-8 support?), because Pd-vanilla 0.42.x was running quite well.
It's hard to believe UTF-8 support could be related to that. The new UTF-8 support code in Pd is only used when editing text inside of a box. Anyway, there's nothing that takes any significant amount of time in handling UTF-8 in any part of Pd (Tcl has its own UTF-8 decoder) nor outside of it.
Fonts... I can't really imagine them being rendered slowly except if using a remote display across a not-very-fast network, but that depends on the renderer and I haven't tried that with Pd+TrueType in particular.
I think that it really has to have a different cause, even if that might be unlikely to you.
How much CPU does Pd (both halves of it) really use while it's acting slow ? That could be a big hint either way. In the process list («ps» or «top»), see whether «pd» has a big %, and see whether «pd-gui» has a big %.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Thank you for your reply,
Mathieu Bouchard matju@artengine.ca writes:
How much CPU does Pd (both halves of it) really use while it's acting slow ? That could be a big hint either way. In the process list («ps» or «top»), see whether «pd» has a big %, and see whether «pd-gui» has a big %.
I did the following experiment:
- opened 'top' in a terminal
- opened pd and created new file
...the CPU is mostly idle
- with dsp turned off I tried to add one object (a non-existing [test] one) and move it around
...when I move the object (the window is already updating slowly, around 2 fps), the Xorg process raises to about 70% CPU usage and puredata process remains at 2-5%. The command «ps -A | egrep -i 'pd|puredata'» gives the following:
17 ? 00:00:13 kswapd0 783 ? 00:00:00 pppd 1045 ? 00:08:51 mpd 26605 pts/4 00:00:01 puredata 26608 pts/4 00:00:00 pd-watchdog
(I was running it with JACK, but running through ALSA gives the same results with only additional puredata process).
The same situation with Pd-extended (except the process name:).
I will post my Xorg.log as an attachment...
Hmm... several things changed that could be relevant.
One thing that might be worth doing is running "pd -d 1" and seeing if there's any obvious difference in the amount of data flowing from Pd to the GUI process.
I gather that 'sid' refers to the very latest unstable version of Debian, so there's also a possibility that the X server itself is having trouble in some way...?
cheers Miller
On Sun, Oct 16, 2011 at 07:36:46PM +0300, Yury Bulka wrote:
Thank you for your reply,
Mathieu Bouchard matju@artengine.ca writes:
How much CPU does Pd (both halves of it) really use while it's acting slow ? That could be a big hint either way. In the process list («ps» or «top»), see whether «pd» has a big %, and see whether «pd-gui» has a big %.
I did the following experiment:
- opened 'top' in a terminal
- opened pd and created new file
...the CPU is mostly idle
- with dsp turned off I tried to add one object (a non-existing [test] one) and move it around
...when I move the object (the window is already updating slowly, around 2 fps), the Xorg process raises to about 70% CPU usage and puredata process remains at 2-5%. The command «ps -A | egrep -i 'pd|puredata'» gives the following:
17 ? 00:00:13 kswapd0 783 ? 00:00:00 pppd 1045 ? 00:08:51 mpd 26605 pts/4 00:00:01 puredata 26608 pts/4 00:00:00 pd-watchdog
(I was running it with JACK, but running through ALSA gives the same results with only additional puredata process).
The same situation with Pd-extended (except the process name:).
I will post my Xorg.log as an attachment...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Let me thank the author for his invaluable contribution to the free software world, and to the concept of live electronics [music]:)
Miller Puckette msp@ucsd.edu writes:
Hmm... several things changed that could be relevant.
One thing that might be worth doing is running "pd -d 1" and seeing if there's any obvious difference in the amount of data flowing from Pd to the GUI process.
I ran the test and created a log which I attach.
I gather that 'sid' refers to the very latest unstable version of Debian, so there's also a possibility that the X server itself is having trouble in some way...?
Seems so...
I am also attaching the fresh Xorg.log.
Hmm... I'm really liking this line from the terminal window ("pd log" but not really a message from Pd I don't think):
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":2" after 11214 requests (11213 known processed) with 0 events remaining.
I don't know what it means but it definitely tried really hard to do something (and ultimately coundn't)!
A mystery... Miller
On Sun, Oct 16, 2011 at 09:04:43PM +0300, Yury Bulka wrote:
Let me thank the author for his invaluable contribution to the free software world, and to the concept of live electronics [music]:)
Miller Puckette msp@ucsd.edu writes:
Hmm... several things changed that could be relevant.
One thing that might be worth doing is running "pd -d 1" and seeing if there's any obvious difference in the amount of data flowing from Pd to the GUI process.
I ran the test and created a log which I attach.
I gather that 'sid' refers to the very latest unstable version of Debian, so there's also a possibility that the X server itself is having trouble in some way...?
Seems so...
I am also attaching the fresh Xorg.log.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette msp@ucsd.edu writes:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":2" after 11214 requests (11213 known processed) with 0 events remaining.
Oh, this happened when I closed the window (may be related to window manager). I tried from another one, plus using the 'File -> Quit' command to close Pd, and it dissapeared.
I've found the point. It was somehow related to my videocard's hardware acceleration: when I disabled it, Pd worked perfectly.
I'm sorry for bothering you with this...
However, if I will find a solution, I will post it here, just in case someone has same videocard I have (Radeon 7000/VE).
Le 2011-10-16 à 19:36:00, Yury Bulka a écrit :
...when I move the object (the window is already updating slowly, around 2 fps), the Xorg process raises to about 70% CPU usage and puredata process remains at 2-5%. The command «ps -A | egrep -i 'pd|puredata'» gives the following:
- this does not show you the pd-gui row
- this does not show you the cpu usage column
additionally, the X11 row and the memory usage column(s) are sometimes useful for speed problems. I usually use «ps aux» to get lots of info (it's rather close to the default columns of «top»).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Mathieu Bouchard -
Miller Puckette -
Yury Bulka