You are absolutely right from a pragmatic perspective. However, having 100 refreshes top off a relatively recent CPU is quite worrisome and IMHO should not be dismissed lightly as it could manifest in other contexts as well. FWIW I did a program which had a similar feature in Qt over four years ago (with 100Hz refreshes for several concurrent timers) and its CPU usage was always less than 3% at that time. This either suggests that Tcl/Tk is a total hog or that there is a bug in a code somewhere (or both).
Hence me bringing this up...
Ico
-----Original Message----- From: Hans-Christoph Steiner [mailto:hans@eds.org] Sent: Monday, February 19, 2007 10:22 PM To: ico@vt.edu Cc: pd-dev@iem.at Subject: Re: [PD-dev] tcl/tk 8.5, antialising, and large fonts lead to huge cpu overhead bug?
Sounds like you are charting new territory. I haven't worked with Tcl/Tk 8.5 yet, but I think a couple people on the list have.
I don't know of any reason to update a GUI object more than 100 Hz since that's about the max for screen refreshes. 10 Hz is probably faster than we can perceive numbers anyway.
.hc
On Feb 18, 2007, at 11:03 PM, ico@vt.edu wrote:
All right, unlike my previous e-mail this is perhaps not a bug, but an oddity. Nonetheless, it would be nice to know at least where it is stemming from so that I can contribute code in the right place...
I've encountered unusual spike in cpu use when using antialiased tcl/tk 8.5 (IIRC it also affects other antialiasing-enabled tcl/tk releases) in conjunction with large fonts. I for instance use this for my performers so that they can clearly read info even when positioned at some distance from the display monitor/LCD.
One quick example would be to use a large font counter which counts 1/100ths of a second using metro and displaying it in a number2 object. This results in a 80+% (!) CPU utilization on an Athlon 64 3000+. Lowering metro to 1/10th of second drops CPU use below 5%. Similarly making font smaller does the same. Font size used is in this case is just about anything above 72.
Any ideas how to circumvent this problem? Is this due to antialiasing inefficiency in tcl/tk or some other reason? If I can be pointed in the right direction, I'll gladly provide patches...
Best wishes,
Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, CHCI Virginia Tech Department of Music Blacksburg, VA 24061-240 (540) 231-1137 (540) 231-5034 (fax) ico.bukvic.net
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
If you are not part of the solution, you are part of the problem.
You're right, it definitely shouldn't be that bad. Have you tried
this same test on different platforms, or with different versions of
Tcl/Tk? (I am guessing you are on Windows, which I don't use). I
just tried on my G4 800 with Tcl/Tk 8.4.15-cvs. I get about 50%
usage from one num2 at 24 point at 100hz.
.hc
On Feb 20, 2007, at 8:49 AM, Ivica Ico Bukvic wrote:
You are absolutely right from a pragmatic perspective. However,
having 100 refreshes top off a relatively recent CPU is quite worrisome and
IMHO should not be dismissed lightly as it could manifest in other contexts as
well. FWIW I did a program which had a similar feature in Qt over four
years ago (with 100Hz refreshes for several concurrent timers) and its CPU
usage was always less than 3% at that time. This either suggests that Tcl/Tk
is a total hog or that there is a bug in a code somewhere (or both).Hence me bringing this up...
Ico
-----Original Message----- From: Hans-Christoph Steiner [mailto:hans@eds.org] Sent: Monday, February 19, 2007 10:22 PM To: ico@vt.edu Cc: pd-dev@iem.at Subject: Re: [PD-dev] tcl/tk 8.5, antialising, and large fonts
lead to huge cpu overhead bug?Sounds like you are charting new territory. I haven't worked with Tcl/Tk 8.5 yet, but I think a couple people on the list have.
I don't know of any reason to update a GUI object more than 100 Hz since that's about the max for screen refreshes. 10 Hz is probably faster than we can perceive numbers anyway.
.hc
On Feb 18, 2007, at 11:03 PM, ico@vt.edu wrote:
All right, unlike my previous e-mail this is perhaps not a bug, but an oddity. Nonetheless, it would be nice to know at least where it is stemming from so that I can contribute code in the right place...
I've encountered unusual spike in cpu use when using antialiased tcl/tk 8.5 (IIRC it also affects other antialiasing-enabled tcl/tk releases) in conjunction with large fonts. I for instance use this for my performers so that they can clearly read info even when positioned at some distance from the display monitor/LCD.
One quick example would be to use a large font counter which counts 1/100ths of a second using metro and displaying it in a number2 object. This results in a 80+% (!) CPU utilization on an Athlon 64 3000+. Lowering metro to 1/10th of second drops CPU use below 5%. Similarly making font smaller does the same. Font size used is in this case is just about anything above 72.
Any ideas how to circumvent this problem? Is this due to
antialiasing inefficiency in tcl/tk or some other reason? If I can be pointed in the right direction, I'll gladly provide patches...Best wishes,
Ivica Ico Bukvic, D.M.A. Composition, Music Technology, CCTAD, CHCI Virginia Tech Department of Music Blacksburg, VA 24061-240 (540) 231-1137 (540) 231-5034 (fax) ico.bukvic.net
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
If you are not part of the solution, you are part of the problem.
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
You're right, it definitely shouldn't be that bad. Have you tried this same test on different platforms, or with different versions of Tcl/Tk? (I am guessing you are on Windows, which I don't use). I
Nope. I am on a Linux box (not literally at this very moment, but I use PD exclusively on Linux). I did try this on 2 different machines with same results. Although both of them were AMD cpus (3000+ laptop and a 4800+ desktop, nicely loaded in terms of RAM etc.), since your test below was on a totally different architecture, my hunch is that this has nothing to do with cpu choice. The two also used two different distros.
just tried on my G4 800 with Tcl/Tk 8.4.15-cvs. I get about 50% usage from one num2 at 24 point at 100hz.
Is this with antialiased fonts? Either way, what we have so far suggests that the tcl/tk is a real hog. With GriPD being apparently abandonware, should one simply use Gem to display data that calls for refreshes faster than 10Hz? To me this idea sounds like an overkill...
Ico
Is there a way to disable proportional fonts? THat might be all we need...
cheers M
On Wed, Feb 21, 2007 at 09:33:54AM -0500, Ivica Ico Bukvic wrote:
You're right, it definitely shouldn't be that bad. Have you tried this same test on different platforms, or with different versions of Tcl/Tk? (I am guessing you are on Windows, which I don't use). I
Nope. I am on a Linux box (not literally at this very moment, but I use PD exclusively on Linux). I did try this on 2 different machines with same results. Although both of them were AMD cpus (3000+ laptop and a 4800+ desktop, nicely loaded in terms of RAM etc.), since your test below was on a totally different architecture, my hunch is that this has nothing to do with cpu choice. The two also used two different distros.
just tried on my G4 800 with Tcl/Tk 8.4.15-cvs. I get about 50% usage from one num2 at 24 point at 100hz.
Is this with antialiased fonts? Either way, what we have so far suggests that the tcl/tk is a real hog. With GriPD being apparently abandonware, should one simply use Gem to display data that calls for refreshes faster than 10Hz? To me this idea sounds like an overkill...
Ico
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sure, use a fixed width font. I was using a fixed width font in my
tests: DejaVu Sans Mono.
.hc
On Feb 21, 2007, at 1:28 PM, Miller Puckette wrote:
Is there a way to disable proportional fonts? THat might be all we
need...cheers M
On Wed, Feb 21, 2007 at 09:33:54AM -0500, Ivica Ico Bukvic wrote:
You're right, it definitely shouldn't be that bad. Have you tried this same test on different platforms, or with different versions of Tcl/Tk? (I am guessing you are on Windows, which I don't use). I
Nope. I am on a Linux box (not literally at this very moment, but
I use PD exclusively on Linux). I did try this on 2 different machines with
same results. Although both of them were AMD cpus (3000+ laptop and a
4800+ desktop, nicely loaded in terms of RAM etc.), since your test
below was on a totally different architecture, my hunch is that this has nothing
to do with cpu choice. The two also used two different distros.just tried on my G4 800 with Tcl/Tk 8.4.15-cvs. I get about 50% usage from one num2 at 24 point at 100hz.
Is this with antialiased fonts? Either way, what we have so far
suggests that the tcl/tk is a real hog. With GriPD being apparently
abandonware, should one simply use Gem to display data that calls for refreshes
faster than 10Hz? To me this idea sounds like an overkill...Ico
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Miller Puckette