f



Tcl/Tk 8.6.3, Itcl 4.0.2, sqlite 3.8.7 Release Candidates

Release candidate downloads of the 8.6.3 releases of Tcl and Tk,
Itcl 4.0.2, and sqlite 3.8.7 may now be found at

   https://sourceforge.net/projects/tcl/files/Tcl/8.6.3/

The actual releases of these files should come on October 29.
Until then, enjoy this advance preview, and if you find anything
catastrophically wrong with them, please inform me so we can fix
the problem before the true release.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
0
Don
10/22/2014 3:31:11 PM
comp.lang.tcl 23428 articles. 2 followers. Post Follow

46 Replies
1555 Views

Similar Articles

[PageSpeed] 42

In comp.lang.tcl, Don Porter wrote:
>
> Release candidate downloads of the 8.6.3 releases of Tcl and Tk,
> Itcl 4.0.2, and sqlite 3.8.7 may now be found at
>
>    https://sourceforge.net/projects/tcl/files/Tcl/8.6.3/
>
> The actual releases of these files should come on October 29.
> Until then, enjoy this advance preview, and if you find anything
> catastrophically wrong with them, please inform me so we can fix
> the problem before the true release.

I believe, I found something "catastrophically wrong" in 8.6.2: it seems,
that canvas has about 5x more work with drawing "line" type objects than
with drawing the same object (say: pentagram) as filled "polygon". The same
can be noticed, when polygon is drawn with "-outline" option.

Is it proper behaviour? Five times more CPU load, when drawing _simpler_
("wireframe") object? Not tested yet 8.6.3.
-- 
Z.
0
empty
10/23/2014 9:43:39 PM
I should add: tested under Linux control (Slackware 14.1, kernel 3.17).

How to reproduce: just compare CPU load during execution of "Polyhedra" demo
(from http://wiki.tcl.tk/14283 ), when drawing filled and wireframe corpses.
Yes, I can see that wireframes are created there as polygons filled with
black - but even when replacing relevant part of the code to create them as
"line" objects - the huge difference in CPU load still remains (which can be
seen especially on weaker machine, not strong modern multicore).
-- 
Z.
0
empty
10/23/2014 10:46:21 PM
Am Freitag, 24. Oktober 2014 00:46:25 UTC+2 schrieb empty-buffers:
> I should add: tested under Linux control (Slackware 14.1, kernel 3.17).
>=20
> How to reproduce: just compare CPU load during execution of "Polyhedra" d=
emo
> (from http://wiki.tcl.tk/14283 ), when drawing filled and wireframe corps=
es.
> Yes, I can see that wireframes are created there as polygons filled with
> black - but even when replacing relevant part of the code to create them =
as
> "line" objects - the huge difference in CPU load still remains (which can=
 be
> seen especially on weaker machine, not strong modern multicore).
> --=20
> Z.

Hi,=20

just to throw in some figures, although on a windows machine:

OS: windows 7
Tcl: 8.6.2, ActiveTcl
CPU: i7-3770 @ 3.4 GHz


               shaded       wireframe
tetrahedron      0.24       0.24
cube             0.3        0.3
octahedron       0.29       0.3
dodecahedron     0.43       0.46
icosahedron      0.45       0.49


view distance: 1200
speed:           40


So at least on windows this runs smoothly.

Did you compare it with Tcl 8.5.x?
You should show the numbers of Tcl 8.5 and 8.6!
Only with real numbers others can tell if there is a performance degradatio=
n in Tcl or the problem stems from some other component.

R=FCdiger
0
hae
10/24/2014 6:34:27 AM
I am not sure it relates to Tk, and I have not done any particular 
testing regarding canvas and stuff. But it is true that I have observed
a dramatic slowdown in Tk apps under Linux lately (a couple of years), 
especially with gnome 3.
I don't know what has changed, but a few apps of mine (that do quite 
some processing) spend more cpu nowadays in their gui than in 
computation. This is due a process called "gnome-shell", which takes 
huge amounts of cpu when my Tk apps run.

I don't know what it is doing, I haven't checked it at all.
But my understanding is that something under Linux (at least) has 
changed. "gnome-shell" seems to have some cpu load when i.e. gnome 
applications run, but I "goes crazy" when I run Tk apps, exhibiting 
loads like 300+% (yes three whole cpu cores) when Tk windows redraw 
themselves.

Just a note, I don't know if it is related to the canvas redrawing 
problem. (Although I think all window drawings are slowed down in gnome...)

George

On 24/10/2014 09:34, hae wrote:
> Am Freitag, 24. Oktober 2014 00:46:25 UTC+2 schrieb empty-buffers:
>> I should add: tested under Linux control (Slackware 14.1, kernel 3.17).
>>
>> How to reproduce: just compare CPU load during execution of "Polyhedra" demo
>> (from http://wiki.tcl.tk/14283 ), when drawing filled and wireframe corpses.
>> Yes, I can see that wireframes are created there as polygons filled with
>> black - but even when replacing relevant part of the code to create them as
>> "line" objects - the huge difference in CPU load still remains (which can be
>> seen especially on weaker machine, not strong modern multicore).
>> --
>> Z.
>
> Hi,
>
> just to throw in some figures, although on a windows machine:
>
> OS: windows 7
> Tcl: 8.6.2, ActiveTcl
> CPU: i7-3770 @ 3.4 GHz
>
>
>                 shaded       wireframe
> tetrahedron      0.24       0.24
> cube             0.3        0.3
> octahedron       0.29       0.3
> dodecahedron     0.43       0.46
> icosahedron      0.45       0.49
>
>
> view distance: 1200
> speed:           40
>
>
> So at least on windows this runs smoothly.
>
> Did you compare it with Tcl 8.5.x?
> You should show the numbers of Tcl 8.5 and 8.6!
> Only with real numbers others can tell if there is a performance degradation in Tcl or the problem stems from some other component.
>
> R�diger
>

0
Georgios
10/24/2014 8:44:10 AM
In comp.lang.tcl, hae wrote:

> just to throw in some figures, although on a windows machine:
>
> OS: windows 7
> Tcl: 8.6.2, ActiveTcl
> CPU: i7-3770 @ 3.4 GHz
>
>
>                shaded       wireframe
> tetrahedron      0.24       0.24
> cube             0.3        0.3
> octahedron       0.29       0.3
> dodecahedron     0.43       0.46
> icosahedron      0.45       0.49
>
>
> view distance: 1200
> speed:           40
>
>
> So at least on windows this runs smoothly.

No particular difference, since in both cases it draws POLYGONS (unless you
modified code, as I suggested) - and it seems OK. Well under Linux, with the
latest "polyhedra" script version, on a weak machine with Athlon 1.9 GHz
(32-bit), I see 8x (EIGHT TIMES! YES!) heavier "load".

If you modify the code to make it create LINE objects in "wireframe" mode,
IMHO you should notice even lower CPU load. But under Linux it's still
several times heavier! Can you imagine? It has more work while drawing
straight lines - than while drawing polygon, and then filling it with
selected paint!

But that's why I stressed "Linux"; I'm aware, it's probably not the same
part of the Tk-code.

> Did you compare it with Tcl 8.5.x?

No, and the question was about "catastrophic" problems in current TCL/Tk.
What I'm describing, I see as kinda catastrophe.

> You should show the numbers of Tcl 8.5 and 8.6!
> Only with real numbers others can tell if there is a performance
> degradation in Tcl or the problem stems from some other component.

Well I told you: EIGHT TIMES heavier CPU load! From about 10% (as shown by
GKrellM) - to 80%. Yes, it wouldn't be that noticeable on Core i7. But I was
appreciating - during past years - that Tk is ("was"?) very "light"
environment. It seems, it is no longer one.
-- 
Z.
0
empty
10/24/2014 9:37:30 AM
In comp.lang.tcl, Georgios Petasis wrote:

> I don't know what has changed, but a few apps of mine (that do quite 
> some processing) spend more cpu nowadays in their gui than in 
> computation. This is due a process called "gnome-shell", which takes 
> huge amounts of cpu when my Tk apps run.
>
> I don't know what it is doing, I haven't checked it at all.
> But my understanding is that something under Linux (at least) has 
> changed. "gnome-shell" seems to have some cpu load when i.e. gnome 
> applications run, but I "goes crazy" when I run Tk apps, exhibiting 
> loads like 300+% (yes three whole cpu cores) when Tk windows redraw 
> themselves.

I'm not sure, does there exist any coincidence with TCT's decision of
introducing OO extension into core. There wasn't any particular need for
this IMHO: we had - well, we still have, right? - several OO-extensions
to choose from. Well the decision was to add another one. "One to rule
them all".

> Just a note, I don't know if it is related to the canvas redrawing 
> problem. (Although I think all window drawings are slowed down in gnome...)

Maybe try that "polyhedra" script in your free time, just to confirm the
problem? I'm using IceWM, not Gnome.
-- 
Z.
0
empty
10/24/2014 9:47:31 AM
In comp.lang.tcl, hae wrote:

> Did you compare it with Tcl 8.5.x?

Just tested 8.5.17 release candidates; they're spoiled the same way.
-- 
Z.
0
empty
10/24/2014 10:51:07 AM
In comp.lang.tcl, empty-buffers wrote:

> Just tested 8.5.17 release candidates; they're spoiled the same way.

Reverted even to 8.5.12 - still the same. It seems, canvas (under Linux)
is screwed up since longer time - just nobody noticed.
-- 
Z.
0
empty
10/24/2014 11:45:39 AM
hae <r_haertel@gmx.de> wrote:
> Am Freitag, 24. Oktober 2014 00:46:25 UTC+2 schrieb empty-buffers:
> > I should add: tested under Linux control (Slackware 14.1, kernel 3.17).
> > 
> > How to reproduce: just compare CPU load during execution of "Polyhedra" demo
> > (from http://wiki.tcl.tk/14283 ), when drawing filled and wireframe corpses.
> > Yes, I can see that wireframes are created there as polygons filled with
> > black - but even when replacing relevant part of the code to create them as
> > "line" objects - the huge difference in CPU load still remains (which can be
> > seen especially on weaker machine, not strong modern multicore).
> > -- 
> > Z.

> Hi, 

> just to throw in some figures, although on a windows machine:

> OS: windows 7
> Tcl: 8.6.2, ActiveTcl
> CPU: i7-3770 @ 3.4 GHz


>                shaded       wireframe
> tetrahedron      0.24       0.24
> cube             0.3        0.3
> octahedron       0.29       0.3
> dodecahedron     0.43       0.46
> icosahedron      0.45       0.49


> view distance: 1200
> speed:           40


> So at least on windows this runs smoothly.

> Did you compare it with Tcl 8.5.x?
> You should show the numbers of Tcl 8.5 and 8.6!
> Only with real numbers others can tell if there is a performance
> degradation in Tcl or the problem stems from some other component.

> Rüdiger

8.6.1 - Slackware 14.1 - just Fvwm2 (no desktop environment)

No measurable difference between shaded and wireframe for the code from
the wiki.  2% cpu for tetrahedron, cube, octahedron, and 3% cpu for
dodecahedron and icosahedron.  Both low enough to essentially be
"noise" on this CPU.

System:

Intel(R) Core(TM) i7 CPU       Q 840  @ 1.87GHz
AMD Radeon card (don't remember the model).
X11 using the default stock kernel driver.
0
Rich
10/24/2014 12:36:59 PM
In comp.lang.tcl, Rich wrote:

> 8.6.1 - Slackware 14.1 - just Fvwm2 (no desktop environment)
>
> No measurable difference between shaded and wireframe for the code from
> the wiki.  2% cpu for tetrahedron, cube, octahedron, and 3% cpu for
> dodecahedron and icosahedron.  Both low enough to essentially be
> "noise" on this CPU.
>
> System:
>
> Intel(R) Core(TM) i7 CPU       Q 840  @ 1.87GHz
  ^^^^^^^^^^^^^^^^^^^^^^^^
> AMD Radeon card (don't remember the model).
> X11 using the default stock kernel driver.

That's why it went unnoticed so many years: on such strong CPU it's
difficult to notice (probably the entire code got into CPU's cache).
I believe the TCT developers have decent machines.

Anyone could use "something weaker"?
-- 
Z.
0
empty
10/24/2014 12:42:24 PM
On 10/23/2014 05:43 PM, empty-buffers wrote:
>>     https://sourceforge.net/projects/tcl/files/Tcl/8.6.3/
>>
>> The actual releases of these files should come on October 29.
>> Until then, enjoy this advance preview, and if you find anything
>> catastrophically wrong with them, please inform me so we can fix
>> the problem before the true release.

> I believe, I found something "catastrophically wrong" in 8.6.2: it seems,
> that canvas has about 5x more work with drawing "line" type objects than
> with drawing the same object (say: pentagram) as filled "polygon".

That does sound like a problem...

 > Not tested yet 8.6.3.

I'm looking for things that are release-blocking for the 8.6.3
candidates.  Things that make releasing Tcl/Tk 8.6.3 demonstrably worse
than not releasing anything and leaving folks stuck with 8.6.2.

Telling me that 8.6.2 suffers compared to some unspecified earlier
Tcl/Tk combination doesn't address that question.

It *is* very important information though!  Can we get a ticket open
on it so we can drill down the missing detail and figure out where
the problem has arisen and address it?  That would be a great help.

You can create Tk tickets here:

	http://core.tcl.tk/tk/tktnew

If you have any difficulty with that, feel free to reply to me for
help.

Ah, I see you've provided more detail in some followups.  I will
attempt to reproduce your reported troubles.  Thanks!

-- 
| Don Porter            Applied and Computational Mathematics Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
0
Don
10/24/2014 12:50:22 PM
>> You should show the numbers of Tcl 8.5 and 8.6!
>> Only with real numbers others can tell if there is a performance
>> degradation in Tcl or the problem stems from some other component.

> Well I told you: EIGHT TIMES heavier CPU load! From about 10% (as shown by
> GKrellM) - to 80%.

Please.  If you can tell us with as much precision as you can what two
things you are comparing and how you are measuring them it would be of
tremendous help in isolating and fixing the problem.

In another followup, you've extended your complaint all the way back to
Tk 8.5.12.  Can you identify a Tk release that doesn't suffer?  You've
made comparisons such as 5x and 8x more work.  What are the things
you compare that produce those results?

-- 
| Don Porter            Applied and Computational Mathematics Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
0
Don
10/24/2014 12:54:36 PM
In comp.lang.tcl, Don Porter wrote:

>> Well I told you: EIGHT TIMES heavier CPU load! From about 10% (as shown by
>> GKrellM) - to 80%.
>
> Please.  If you can tell us with as much precision as you can what two
> things you are comparing and how you are measuring them it would be of
> tremendous help in isolating and fixing the problem.

For usual everyday's tasks I use quite weak (for today's standards) system,
with a CPU:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) XP 2600+
stepping        : 0
cpu MHz         : 1851.529
cache size      : 512 KB

Before the test, I run GKrellM utility. Its "CPU-meter" displays on
non-lasted system usually show a value between 0 and 3% CPU load.

After I run polyhedra script, with "icosahedron shaded", there is from 7 to
10% CPU load (as shown by GKrellM) - quite acceptable values, right? Well
when I switch it to "wireframe" (which in the code from the Wiki means
"outlined polygon"), the load jumps up to 75-80%. By modifying the code
I found, that switching to real wireframe (I mean "line"-type object) means
no practical difference.

In conclusion: Tk's canvas - at least under Linux - has strange problems
with drawing "just lines". It draws filled polygons much faster(!). Why?

It's not a flaw in CPU-meter; the same shows "internal CPU-meter" of IceWM.

> In another followup, you've extended your complaint all the way back to
> Tk 8.5.12.  Can you identify a Tk release that doesn't suffer?

I'll try later some more older releases. But a minute ago tried 8.4.20 -
which suffers the same problem.

> You've made comparisons such as 5x and 8x more work.  What are the things
> you compare that produce those results?

I tried that "polyhedra" script. Closer examination of the code revealed no
flaws in "wireframe" display procedures, that could introduce additional
load (or maybe I'm missing something, but honestly I don't think so). Even
the changes, that I tried:

From "pretended wireframe":

       lappend lpoly [$w.c create polygon \
                    [string repeat " 0" [expr {2*[llength $cnx]}]] \
                    -fill black -outline blue]

To "real wireframe":

       lappend lpoly [$w.c create line \
                     [string repeat " 0" [expr {2*[llength $cnx]}]] \
                     -width 1 -fill blue]

gave no desired effect, I mean: even when operating real "line" objects,
canvas requires MORE CPU cycles (still about 4x more), than drawing and
filling polygons (and even while the "line" objects haven't been "closed").
Unbelievable!
-- 
Z.
0
empty
10/24/2014 1:18:30 PM
In comp.lang.tcl, Don Porter wrote:

> You can create Tk tickets here:
>
> 	http://core.tcl.tk/tk/tktnew

OK, when I'll be back in few hours, I'll test the RC version (alas, I don't
expect it to work better in the described regard), and I'll open a ticket.
-- 
Z.
0
empty
10/24/2014 1:20:46 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > 8.6.1 - Slackware 14.1 - just Fvwm2 (no desktop environment)
> >
> > No measurable difference between shaded and wireframe for the code from
> > the wiki.  2% cpu for tetrahedron, cube, octahedron, and 3% cpu for
> > dodecahedron and icosahedron.  Both low enough to essentially be
> > "noise" on this CPU.
> >
> > System:
> >
> > Intel(R) Core(TM) i7 CPU       Q 840  @ 1.87GHz
>   ^^^^^^^^^^^^^^^^^^^^^^^^
> > AMD Radeon card (don't remember the model).
> > X11 using the default stock kernel driver.

> That's why it went unnoticed so many years: on such strong CPU it's
> difficult to notice (probably the entire code got into CPU's cache).
> I believe the TCT developers have decent machines.

> Anyone could use "something weaker"?

Later tonight after I get home from work I'll be able to test on a
Pentium 4 Celeron at 2Ghz.  That's the weakest CPU I have that is
still running and therefore testable.

0
Rich
10/24/2014 1:27:11 PM
On 10/24/2014 09:18 AM, empty-buffers wrote:
>> You've made comparisons such as 5x and 8x more work.  What are the things
>> you compare that produce those results?

> I tried that "polyhedra" script.

Ok, so I think I misunderstood the claim.  This is not a comparison
of performance between releases of Tk, where an old release was
acceptable, and newer ones are not.

Instead it's a comparison of two different tasks on a canvas which
have relative performance contrary to intuition.  Wireframe drawing
"should be" as fast or faster then filled polygon drawing, but it
is instead significantly slower.

Have I got it right now?

-- 
| Don Porter            Applied and Computational Mathematics Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
0
Don
10/24/2014 1:36:05 PM
Debian 7.7, kernel 3.17, model name : Genuine Intel(R) CPU T1600  @ 1.66GHz

Can't confirm, 8.5.11, 8.6.2 and 8.6.3 all run both shaded and wireframe within same limits of CPU use (difference 2-3 percentage points in favor of unshaded). No difference even with switch to "real lines".
0
Kaitzschu
10/24/2014 1:54:19 PM
Quote: Kaitzschu wrote on Fri, 24 October 2014 15:54
----------------------------------------------------
> Debian 7.7, kernel 3.17, model name : Genuine Intel(R) CPU T1600  @ 1.66GHz
> 
> Can't confirm, 8.5.11, 8.6.2 and 8.6.3 all run both shaded and wireframe within same limits of CPU use (difference 2-3 percentage points in favor of unshaded). No difference even with switch to "real lines".
----------------------------------------------------

Could it be that the local X (in the OP's setup) just happens to lack hardware acceleration of *lines* but not for polys ?

That would account for the CPU hog being another process than wish.

-Alex
0
Alexandre
10/24/2014 2:05:18 PM
Am 24.10.2014 15:36, schrieb Don Porter:
> On 10/24/2014 09:18 AM, empty-buffers wrote:
>>> You've made comparisons such as 5x and 8x more work.  What are the
>>> things
>>> you compare that produce those results?
>
>> I tried that "polyhedra" script.
>
> Ok, so I think I misunderstood the claim.  This is not a comparison
> of performance between releases of Tk, where an old release was
> acceptable, and newer ones are not.

I've seen funny effects from older X-clients displaying on newer 
X-servers "capped" with KDE.
And independent of how the  clients are created.
Another effect was : start a remote program for local display,
see the window appear for milliseconds and then the app closes down 
without error immediately.

Result is increased cpu usage ( on occasion into being unuseable )
on the client and the server.

MY assumption was that nobody could be bothered to be nice to
older software/hardware. Modern desktop environments appear to
be resource black holes ;-)

Uwe






0
Uwe
10/24/2014 2:34:48 PM
On 24/10/2014 12:47, empty-buffers wrote:
> In comp.lang.tcl, Georgios Petasis wrote:
>
>> I don't know what has changed, but a few apps of mine (that do quite
>> some processing) spend more cpu nowadays in their gui than in
>> computation. This is due a process called "gnome-shell", which takes
>> huge amounts of cpu when my Tk apps run.
>>
>> I don't know what it is doing, I haven't checked it at all.
>> But my understanding is that something under Linux (at least) has
>> changed. "gnome-shell" seems to have some cpu load when i.e. gnome
>> applications run, but I "goes crazy" when I run Tk apps, exhibiting
>> loads like 300+% (yes three whole cpu cores) when Tk windows redraw
>> themselves.
>
> I'm not sure, does there exist any coincidence with TCT's decision of
> introducing OO extension into core. There wasn't any particular need for
> this IMHO: we had - well, we still have, right? - several OO-extensions
> to choose from. Well the decision was to add another one. "One to rule
> them all".
>

No, this does not relate at all with TclOO. And yes, TclOO in the core 
was an excellent decision in my point of view.

George
0
Georgios
10/24/2014 2:55:18 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > 8.6.1 - Slackware 14.1 - just Fvwm2 (no desktop environment)
> >
> > No measurable difference between shaded and wireframe for the code from
> > the wiki.  2% cpu for tetrahedron, cube, octahedron, and 3% cpu for
> > dodecahedron and icosahedron.  Both low enough to essentially be
> > "noise" on this CPU.
> >
> > System:
> >
> > Intel(R) Core(TM) i7 CPU       Q 840  @ 1.87GHz
>   ^^^^^^^^^^^^^^^^^^^^^^^^
> > AMD Radeon card (don't remember the model).
> > X11 using the default stock kernel driver.

> That's why it went unnoticed so many years: on such strong CPU it's
> difficult to notice (probably the entire code got into CPU's cache).
> I believe the TCT developers have decent machines.

> Anyone could use "something weaker"?

Something "weaker" (but not as weak as my Pentium 4 Celeron):

Mobile AMD Sempron(tm) Processor 3000+ (1.8Ghz)
ATI Radeon XPRESS 200M 5955
Slack 13.37
Kernel 3.8.2 (custom compiled - not the stock 13.37 kernel).
Using the stock kernel Radeon driver and stock X11 Radeon driver (i.e.,
not the ATI binary blob driver).

Animation run with standard distance/speed (1200/40):
CPU percentage measured via top.

8.6.2:       shaded  wireframe
tetrahedron    5.3%  4.6%
cube           6.6%  5.9%
octahedron     6.9%  6.0%
dodecahedron   9.6%  8.6%
icosahedron   10.9%  8.9%

8.6.3: Values identical to 8.6.2 to withing +- 0.1%.

8.5.17:        shaded    wireframe
tetrahedron      3.6%    3.0%
cube             4.6%    4.6%
octahedron       5.3%    4.6%
dodecahedron     7.3%    6.6%
icosahedron      8.6%    6.6%

0
Rich
10/24/2014 3:40:36 PM
Alexandre Ferrieux <alexandre.ferrieux@nospam.gmail.com> wrote:
> Quote: Kaitzschu wrote on Fri, 24 October 2014 15:54
> ----------------------------------------------------
> > Debian 7.7, kernel 3.17, model name : Genuine Intel(R) CPU T1600  @
> > 1.66GHz
> > 
> > Can't confirm, 8.5.11, 8.6.2 and 8.6.3 all run both shaded and
> > wireframe within same limits of CPU use (difference 2-3 percentage
> > points in favor of unshaded). No difference even with switch to
> > "real lines".
> ----------------------------------------------------

> Could it be that the local X (in the OP's setup) just happens to lack
> hardware acceleration of *lines* but not for polys ?

I'm beginning to think this may be the case, given my test results so
far.

> That would account for the CPU hog being another process than wish.

The OP was unclear what process was using the CPU.  If he/she was
looking at a generic "cpu usage" widget on a desktop environment, then
he/she would have been seeing total cpu, not just that used by wish.

OP - can you clarify exactly which process was consuming how much cpu?

0
Rich
10/24/2014 4:57:16 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Don Porter wrote:

> > You can create Tk tickets here:
> >
> >       http://core.tcl.tk/tk/tktnew

> OK, when I'll be back in few hours, I'll test the RC version (alas, I don't
> expect it to work better in the described regard), and I'll open a ticket.

Can you clarify how you are measuring CPU usage.

And can you clarify if you are measuring total CPU for the whole
system, or just CPU used by wish when running the demo.

If you are reporting CPU used by the whole system, then you need to
retest and report CPU used just by the wish process.
0
Rich
10/24/2014 4:58:29 PM
In comp.lang.tcl, Rich wrote:

> The OP was unclear what process was using the CPU.  If he/she was
> looking at a generic "cpu usage" widget on a desktop environment, then
> he/she would have been seeing total cpu, not just that used by wish.
>
> OP - can you clarify exactly which process was consuming how much cpu?

Actually, you're right regarding processes; I see 2 related:

- "tclsh ./polyhedra.tcl" uses about 4% CPU
- "/usr/bin/X :0 -auth ~/.Xauthority" uses 71% CPU

So the second process is _directly_ responsible for heavy CPU load. But it's
always triggered by Tk drawing lines (not polygons). When I close "polyhedra"
window, it drops to about 1% CPU use. Or when I switch back to "shaded"
mode, the CPU load drops back to low level, of course.

So you think the video driver may be faulty in a very specific way? But how
can I check this? Is it possible at all, that video driver has acceleration
for more complicated objects, but for simpler ones - not?

And does Tk use video acceleration at all?

I'm using Radeon 9600, which of course uses R300 driver. Xserver 1.14.3
If I'm correct, ATI video driver is involved, which is in version 7.2.0
-- 
Z.
0
empty
10/24/2014 5:45:17 PM
Sorry, guys - but something's obviously wrong with Tk. Just made another
test, on my different machine, and this time it was more modern CPU, with
more modern video adaptor (Radeon "Evergreen"), to ensure, it uses different
video driver. Regarding the CPU - it's 4-core Intel:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 60
model name	: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
stepping	: 3
microcode	: 0x1a
cpu MHz		: 3899.765
cache size	: 8192 KB

Made similar tests, like before - and still the same difference:

- when in "shaded" mode, X-process, the one directly responsible for CPU
use, needs about 0.7%

- after switching to "wireframe" it jumps to 15-17% of CPU use

Different machine, different hardware, Slackware 14.1 (64-bit this time),
TCL/Tk 8.6.1.

Only "polyhedra" script was the same.
-- 
Z.
0
empty
10/24/2014 6:04:39 PM
In comp.lang.tcl, Rich wrote:

>> Anyone could use "something weaker"?
>
> Something "weaker" (but not as weak as my Pentium 4 Celeron):
>
> Mobile AMD Sempron(tm) Processor 3000+ (1.8Ghz)
> ATI Radeon XPRESS 200M 5955
> Slack 13.37
> Kernel 3.8.2 (custom compiled - not the stock 13.37 kernel).
> Using the stock kernel Radeon driver and stock X11 Radeon driver (i.e.,
> not the ATI binary blob driver).
>
> Animation run with standard distance/speed (1200/40):
> CPU percentage measured via top.
>
> 8.6.2:       shaded  wireframe
> tetrahedron    5.3%  4.6%
> cube           6.6%  5.9%
> octahedron     6.9%  6.0%
> dodecahedron   9.6%  8.6%
> icosahedron   10.9%  8.9%
>
> 8.6.3: Values identical to 8.6.2 to withing +- 0.1%.
>
> 8.5.17:        shaded    wireframe
> tetrahedron      3.6%    3.0%
> cube             4.6%    4.6%
> octahedron       5.3%    4.6%
> dodecahedron     7.3%    6.6%
> icosahedron      8.6%    6.6%

Now that's strange - you don't notice any real difference. And it's obvious,
since in both cases there are polygons involved (just with blue border in
the second case) - the "strange" part is, that I SEE the huge difference,
using my machinery.

Yes, I also use stock (open source) Radeon video drivers in both cases, on
my both machines.
-- 
Z.
0
empty
10/24/2014 6:11:25 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > The OP was unclear what process was using the CPU.  If he/she was
> > looking at a generic "cpu usage" widget on a desktop environment, then
> > he/she would have been seeing total cpu, not just that used by wish.
> >
> > OP - can you clarify exactly which process was consuming how much cpu?

> Actually, you're right regarding processes; I see 2 related:

> - "tclsh ./polyhedra.tcl" uses about 4% CPU
> - "/usr/bin/X :0 -auth ~/.Xauthority" uses 71% CPU

> So the second process is _directly_ responsible for heavy CPU load.

Then the flaw is unlikely Tcl/Tk itself.  That second process (X) is
your X server process that handles all the effort of "drawing"
everything that appears on your screen.

> But it's always triggered by Tk drawing lines (not polygons).

Correct, and not the full story, at the same time.

Proper statement: 
  But it is always triggered by any X program that asks the X server to
  perform "operation Q".  By chance, Tk's canvas happens to request
  "operation Q".

The flaw here seems to be the X server (and likely ultimately the video
driver for your chip-set) in that it is likely not performing hardware
acceleration for some subset of X draw-able calls.  It just so happens
that Tk, for the canvas, is using one or more of those X draw-able
calls that result in CPU rendering in your X server.

But in reality, you could have a custom program written in C that
called one or more of the same bad X draw-able calls and you'd see
exactly the same results.

> When I close "polyhedra" window, it drops to about 1% CPU use.

Yes.  Tk is no longer asking the X server to draw something that the X
server is consuming loads of CPU in order to draw.

> Or when I switch back to "shaded" mode, the CPU load drops back to
> low level, of course.

Not surprising.  I once had a video card/X combo that for xterm/rxvt
windows would scroll text at an abysmally slow rate (on the order of
one line scrolled up per second).  However, placing any other window
such that the other window overlapped the xterm/rxvt scrolling area
(even by one pixel) resulted in the xterm/rxvt window scrolling at full
speed (i.e., faster than one could see).

So my solution to that issue was to simply drop a 1 pixel by 1 pixel
xlogo window above each usually open xterm/rxvt in an Fvwm layer that
was always above the others.  The result was fast scrolling.

A revision or two later of the X server, and the problem disappeared,
and I turned off my 1x1 xlogo's because they provided no benefit
anymore.

> So you think the video driver may be faulty in a very specific way?

Yes.  See my "slow vs fast scroll" paragraphs above.

> But how can I check this?

Without intimate knowledge of X, X's video driver architecture, and the
low level programming spec's of your particular video chip, you simply
can't.

> Is it possible at all, that video driver has acceleration for more
> complicated objects, but for simpler ones - not?

Yes.  Implying a bug somewhere, but it is possible.

> And does Tk use video acceleration at all?

No standard X windows programs know anything about "acceleration" at
all.  All the "acceleration" is part of the X servers and is supposed
to be invisible, and just work, for every X client.  The only
exceptions typically end up being clients such as video players.

> I'm using Radeon 9600, which of course uses R300 driver. Xserver
> 1.14.3 If I'm correct, ATI video driver is involved, which is in
> version 7.2.0

On the two Radeon's I tested upon, I'm running the standard open-source
drivers.  Any chance you'd be willing to uninstall the ATI proprietary
driver and use the open-source drivers to test?

Alternately, if there's been a new release of the proprietary driver,
upgrading it might fix the issue.
0
Rich
10/24/2014 6:15:23 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> >> Anyone could use "something weaker"?
> >
> > Something "weaker" (but not as weak as my Pentium 4 Celeron):
> >
> > Mobile AMD Sempron(tm) Processor 3000+ (1.8Ghz)
> > ATI Radeon XPRESS 200M 5955
> > Slack 13.37
> > Kernel 3.8.2 (custom compiled - not the stock 13.37 kernel).
> > Using the stock kernel Radeon driver and stock X11 Radeon driver (i.e.,
> > not the ATI binary blob driver).
> >
> > Animation run with standard distance/speed (1200/40):
> > CPU percentage measured via top.
> >
> > 8.6.2:       shaded  wireframe
> > tetrahedron    5.3%  4.6%
> > cube           6.6%  5.9%
> > octahedron     6.9%  6.0%
> > dodecahedron   9.6%  8.6%
> > icosahedron   10.9%  8.9%
> >
> > 8.6.3: Values identical to 8.6.2 to withing +- 0.1%.
> >
> > 8.5.17:        shaded    wireframe
> > tetrahedron      3.6%    3.0%
> > cube             4.6%    4.6%
> > octahedron       5.3%    4.6%
> > dodecahedron     7.3%    6.6%
> > icosahedron      8.6%    6.6%

> Now that's strange - you don't notice any real difference.

Nope.  The only real difference is that 8.6's usage is slightly more
than 8.5's usage, but none of the usage is anything unusual.

I made no changes to the code off the wiki, it was run exactly as it
exists on the wiki.

> And it's obvious, since in both cases there are polygons involved
> (just with blue border in the second case) - the "strange" part is,
> that I SEE the huge difference, using my machinery.

See my other reply where I relate a historical oddness with scrolling
xterm/rxvt's some years back.

> Yes, I also use stock (open source) Radeon video drivers in both cases, on
> my both machines.

Your other reply implied you were using the ATI supplied video driver.

You are only using one, but exactly which one, is quite important.
0
Rich
10/24/2014 6:20:15 PM
In comp.lang.tcl, Rich wrote:

> On the two Radeon's I tested upon, I'm running the standard open-source
> drivers.  Any chance you'd be willing to uninstall the ATI proprietary
> driver and use the open-source drivers to test?

But I'm using open-source ("Gallium", if I'm correct) video driver. And
it's really hard to believe, it's broken for all the possible Radeons?

Well, tested this with two quite different Radeons, as stated in my other post.
-- 
Z.
0
empty
10/24/2014 6:23:36 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:

> Sorry, guys - but something's obviously wrong with Tk. Just made another
> test, on my different machine, and this time it was more modern CPU, with
> more modern video adaptor (Radeon "Evergreen"), to ensure, it uses different
> video driver. Regarding the CPU - it's 4-core Intel:

> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 60
> model name      : Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
> stepping        : 3
> microcode       : 0x1a
> cpu MHz         : 3899.765
> cache size      : 8192 KB

> Made similar tests, like before - and still the same difference:

> - when in "shaded" mode, X-process, the one directly responsible for CPU
> use, needs about 0.7%

> - after switching to "wireframe" it jumps to 15-17% of CPU use

> Different machine, different hardware, Slackware 14.1 (64-bit this time),
> TCL/Tk 8.6.1.

> Only "polyhedra" script was the same.

My first performance report (the one from the i7, where your reply
asked for "weaker" CPU's) was with Slackware 14.1 64-bit with the
drivers that come with Slackware for Radeon chipsets.  I.e., not the
drivers produced by ATI themselves.

I saw no significant difference in wish.  I was not paying any
attention to the X process.  The reason I didn't care about X was 1)
your report was against Tk itself, so I was watching wish, 2) whatever
CPU the X server used wasn't big enough to make me think there was
anything other than normal processing going on.

0
Rich
10/24/2014 6:24:25 PM
In comp.lang.tcl, Rich wrote:

> Your other reply implied you were using the ATI supplied video driver.
>
> You are only using one, but exactly which one, is quite important.

Slackware 14.1 has the package xf86-video-ati-7.2.0 installed by default.
-- 
Z.
0
empty
10/24/2014 6:29:14 PM
empty-buffers wrote:

> In comp.lang.tcl, Rich wrote:
> 
>> On the two Radeon's I tested upon, I'm running the standard
>> open-source
>> drivers.  Any chance you'd be willing to uninstall the ATI
>> proprietary driver and use the open-source drivers to test?
> 
> But I'm using open-source ("Gallium", if I'm correct) video driver.
> And it's really hard to believe, it's broken for all the possible
> Radeons?
> 
> Well, tested this with two quite different Radeons, as stated in my
> other post.

Here are my experiences. 8.6.2 on i5-2500K, onboard graphics
opensuse 13.1, kde 4.11
Looks like outline is just a little faster.

(ian) 51 % pack [canvas .c -bg white] -fill both -expand 1

(ian) 52 % set xy {20 20 90 20 90 80 20 80}
20 20 90 20 90 80 20 80

(ian) 53 % time {.c create polygon $xy -fill red -outline ""} 1000
3.51 microseconds per iteration

(ian) 54 % time {.c create polygon $xy -fill red -outline ""} 1000
3.574 microseconds per iteration

(ian) 54 % .c delete all

(ian) 55 % time {.c create polygon $xy -fill "" -outline "blue"} 1000
3.286 microseconds per iteration

(ian) 56 % time {.c create polygon $xy -fill "" -outline "blue"} 1000
3.139 microseconds per iteration


-- 
*********** To reply by e-mail, make w single in address **************
0
Ian
10/24/2014 6:32:46 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > Your other reply implied you were using the ATI supplied video driver.
> >
> > You are only using one, but exactly which one, is quite important.

> Slackware 14.1 has the package xf86-video-ati-7.2.0 installed by default.

Same as on my 14.1 x86_64 i7 system:  xf86-video-ati-7.2.0-x86_64-2

You did leave off the full Slackware package name, the -2 on the end
means revision 2.  Slackware must have pushed a new package sometime. 
If by chance you have -1 in /var/log/packages consider upgrading to the
-2 version.
0
Rich
10/24/2014 6:52:20 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > On the two Radeon's I tested upon, I'm running the standard
> > open-source drivers.  Any chance you'd be willing to uninstall the
> > ATI proprietary driver and use the open-source drivers to test?

> But I'm using open-source ("Gallium", if I'm correct) video driver.
> And it's really hard to believe, it's broken for all the possible
> Radeons?

From your other followup, you may be running the same driver (you left
off the Slackware package revision number) I'm running on my Slackware
14.1 system.

I did not notice anything unusual, but I'm not sitting in front of that
system at the moment to retest.  I'll check again tonight and report
what I find.

> Well, tested this with two quite different Radeons, as stated in my
> other post.

It still could be the video driver.  The open source driver just might
not yet support triggering hardware acceleration for one particular
call (on any Radeon chip) that Tk is making into the X server, and so
it falls back on CPU based rendering.

But that would still be a flaw with the open source driver, not a Tk
flaw.

Quick retest with 8.6.2 on the "weaker" AMD athlon CPU (and
xf86-video-ati-6.14.1-i486-1 driver (Slackware 13.37)):

               shaded            wireframe
               wish        X     wish       X
tetrahedron    5.3%     8.9%     5.0%    8.9%
cube           6.6%    11.6%     5.6%   11.2%
octahedron     6.3%     9.9%     5.9%    6.9%
dodecahedron   9.6%    10.6%     8.2%    8.6%
isocahedron   10.5%    11.2%     8.3%    8.9%

None of those timings seem out of any reasonable range to me.
0
Rich
10/24/2014 7:04:00 PM
In comp.lang.tcl, Rich wrote:

> You did leave off the full Slackware package name, the -2 on the end
> means revision 2.  Slackware must have pushed a new package sometime. 
> If by chance you have -1 in /var/log/packages consider upgrading to the
> -2 version.

Yes, my also had "-2" as the suffix. I say "had", because - encouraged by
your posts - meanwhile I quickly upgraded to newest driver 7.5.0, and...

....and this nothing changed. I still see the same difference.

Maybe configuration? Do you use xorg.conf - if so, how does it look like?

I don't use one, just 2 lines in ~$HOME/.xinitrc

 xrandr --output DVI-0 --mode 1280x800 --panning 1680x1050
 /etc/X11/xinit/xinitrc.icewm

(apart of a few keyboard-related ones)
-- 
Z.
0
empty
10/24/2014 7:11:42 PM
In comp.lang.tcl, Rich wrote:

> It still could be the video driver.  The open source driver just might
> not yet support triggering hardware acceleration for one particular
> call (on any Radeon chip) that Tk is making into the X server, and so
> it falls back on CPU based rendering.
>
> But that would still be a flaw with the open source driver, not a Tk
> flaw.

To exclude even "human factor" (both machines have been configured by me),
on my weaker machine I just ran Vectorlinux 7.0 Live-CD from 2011 - and
guess what? Yes - the problem still persists. Since you have Radeon card as
well, I think it would be good "common denominator" - you can try polyhedra
script with this live-CD on your hardware. They included TCL/Tk 8.5.9.

So either Tk is flawed _since years_ - or Radeon driver is flawed, of course
_since years_.

Please note, that this time only hardware was the same - the entire software
(but "polyhedra" script) was totally different, and configured by someone
else, more than 3 years ago.
-- 
Z.
0
empty
10/24/2014 8:13:51 PM
On Wednesday, October 22, 2014 8:31:14 AM UTC-7, Don Porter wrote:
> Release candidate downloads of the 8.6.3 releases of Tcl and Tk,
> Itcl 4.0.2, and sqlite 3.8.7 may now be found at
> 
>    https://sourceforge.net/projects/tcl/files/Tcl/8.6.3/
> 
> The actual releases of these files should come on October 29.
> Until then, enjoy this advance preview, and if you find anything
> catastrophically wrong with them, please inform me so we can fix
> the problem before the true release.
> 
> -- 
> | Don Porter            Applied and Computational Mathematics Division |
> | donald.porter@nist.gov             Information Technology Laboratory |
> | http://math.nist.gov/~DPorter/                                  NIST |
> |______________________________________________________________________|

oh no u didn't!
0
johannes
10/24/2014 8:16:22 PM
In comp.lang.tcl, Don Porter wrote:

> That does sound like a problem...

To have the final answer, I tested it all again on the third machine:
2-core Sempron with NVidia graphics adaptor, using their proprietary,
"closed" drivers.

Yes, on that machine the script works as can be expected: the load is low
(3-5%), and there's no noticeable difference between its "display modes"
(at least it cannot be noticed by watching various "CPU-meteres").

Sorry - I couldn't believe, such basic thing like video driver could have
flawed such basic operation, like drawing straight lines - and it persists
since years including the most recent 7.5.0 driver release, and nobody(?)
cares/noticed. Unbelievable!
-- 
Z.
0
empty
10/24/2014 9:08:28 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > You did leave off the full Slackware package name, the -2 on the end
> > means revision 2.  Slackware must have pushed a new package sometime. 
> > If by chance you have -1 in /var/log/packages consider upgrading to the
> > -2 version.

> Yes, my also had "-2" as the suffix. I say "had", because - encouraged by
> your posts - meanwhile I quickly upgraded to newest driver 7.5.0, and...
> ...and this nothing changed. I still see the same difference.

Then that didn't work.

> Maybe configuration? Do you use xorg.conf - if so, how does it look
> like?

No, the only "conf" file the X server consumes is a
/etc/xorg.conf.d/10-monitor.conf one that contains only:

    Section "Monitor"
     Identifier "LVDS"
     Option    "PreferredMode" "1920x1080"
     Option    "Primary" "true"
    EndSection

    Section "Monitor"
     Identifier "VGA-0"
     Option    "PreferredMode" "1600x1200"
     Option    "RightOf" "LVDS"
    EndSection

To preset dual-monitor usage/setup.

> I don't use one, just 2 lines in ~$HOME/.xinitrc

>  xrandr --output DVI-0 --mode 1280x800 --panning 1680x1050
>  /etc/X11/xinit/xinitrc.icewm

I don't set --panning anywhere.  Maybe you might try a test without
--panning to see if there is any difference.
0
Rich
10/24/2014 10:39:41 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Rich wrote:

> > It still could be the video driver.  The open source driver just might
> > not yet support triggering hardware acceleration for one particular
> > call (on any Radeon chip) that Tk is making into the X server, and so
> > it falls back on CPU based rendering.
> >
> > But that would still be a flaw with the open source driver, not a Tk
> > flaw.

> To exclude even "human factor" (both machines have been configured by me),
> on my weaker machine I just ran Vectorlinux 7.0 Live-CD from 2011 - and
> guess what? Yes - the problem still persists. Since you have Radeon card as
> well,

Yes, but likely a very different chip - so the results are not apples
to apples comparisons.

I'll get a chance later to try the script and watch for the X server
cpu usage.  I'll know more when I get that chance.

0
Rich
10/24/2014 10:41:43 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Don Porter wrote:

> > That does sound like a problem...

> To have the final answer, I tested it all again on the third machine:
> 2-core Sempron with NVidia graphics adaptor, using their proprietary,
> "closed" drivers.

> Yes, on that machine the script works as can be expected: the load is
> low (3-5%), and there's no noticeable difference between its "display
> modes" (at least it cannot be noticed by watching various
> "CPU-meteres").

> Sorry - I couldn't believe, such basic thing like video driver could
> have flawed such basic operation, like drawing straight lines - and
> it persists since years including the most recent 7.5.0 driver
> release, and nobody(?) cares/noticed. Unbelievable!

Many may have noticed.  Few would have had the skills to do anything
about it.  Even fewer would have had the necessary documentation to
make any change.

And if those who noticed did not report it, the of course nothing is
likely to change.

You might look into how to file a bug report with the maintainers of
the radeon driver and provide your examples (having a repeatable test
case will help them tremendously).  Then it might end up getting fixed.
0
Rich
10/24/2014 10:44:14 PM
In comp.lang.tcl, Rich wrote:

> You might look into how to file a bug report with the maintainers of
> the radeon driver and provide your examples (having a repeatable test
> case will help them tremendously).  Then it might end up getting fixed.

Already done.
-- 
Z.
0
empty
10/24/2014 11:22:47 PM
On 24/10/2014 10:47, empty-buffers wrote:
> I'm not sure, does there exist any coincidence with TCT's decision of
> introducing OO extension into core. There wasn't any particular need for
> this IMHO: we had - well, we still have, right? - several OO-extensions
> to choose from. Well the decision was to add another one. "One to rule
> them all".

We have it, but don't use it for everything. In fact, we don't use it
for anything in that demo. The main use right now is for the Unix
standard dialogs, and you shouldn't be caring about performance too much
there! Whatever is going on, that's not it. In fact, I don't think we've
changed anything about canvases recently.

Different compilation options are more likely an issue. It's fairly easy
to pick a bad combination (for example, enabling either symbols or
dtrace probes will have a substantial performance impact).

Donal.
-- 
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.
0
Donal
10/28/2014 10:27:45 AM
On 24/10/2014 22:08, empty-buffers wrote:
> Sorry - I couldn't believe, such basic thing like video driver could have
> flawed such basic operation, like drawing straight lines - and it persists
> since years including the most recent 7.5.0 driver release, and nobody(?)
> cares/noticed. Unbelievable!

Believe it. :-)

It's probably the case that the most common operations — drawing
straight horizontal and vertical lines — are fast, but drawing at other
angles is unaccelerated. It's also possible that drawing of a single
line is accelerated but drawing of a polyline is not (though that would
be a dumb problem). In both cases, the issue is not in Tk which is just
saying “draw this” but rather in the code (Xserver or display driver)
which carries out that command.

Still, at least the panic from our side is over.

Donal.
-- 
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.
0
Donal
10/28/2014 10:38:26 AM
In comp.lang.tcl, Donal K. Fellows wrote:

> It's probably the case that the most common operations ??? drawing
> straight horizontal and vertical lines ??? are fast, but drawing at other
> angles is unaccelerated. It's also possible that drawing of a single
> line is accelerated but drawing of a polyline is not (though that would
> be a dumb problem). In both cases, the issue is not in Tk which is just
> saying ???draw this??? but rather in the code (Xserver or display driver)
> which carries out that command.

But it seems, they did acceleration for polygons (for all possible angles)
- so how the much simpler, very basic operation could have been left "for
later"?

Yes, I'm aware I should raise this question elsewhere (well I kinda did it).
-- 
Z.
0
empty
10/28/2014 4:39:29 PM
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.neither-this.com> wrote:
> In comp.lang.tcl, Donal K. Fellows wrote:

> > It's probably the case that the most common operations ??? drawing
> > straight horizontal and vertical lines ??? are fast, but drawing at
> > other angles is unaccelerated. It's also possible that drawing of a
> > single line is accelerated but drawing of a polyline is not (though
> > that would be a dumb problem). In both cases, the issue is not in
> > Tk which is just saying ???draw this??? but rather in the code
> > (Xserver or display driver) which carries out that command.

> But it seems, they did acceleration for polygons (for all possible
> - angles) so how the much simpler, very basic operation could have
> - been left "for
> later"?

> Yes, I'm aware I should raise this question elsewhere (well I kinda
> did it).

It would be termed a "bug".  I.e., there's some mistake in the driver
that, for your particular chipset (maybe more, but at least yours), is
causing the lack of acceleration for those items.

0
Rich
10/28/2014 9:00:04 PM
Reply:

Similar Artilces:

[RELEASED] Release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're pleased to announce the immediate availability of release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation...

[RELEASED] Release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're pleased to announce the immediate availability of release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 . The main impetus for these releases is fixing a security issue in Python's hash based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are maintained only for security issues, 2.6.8 and 3.1.5 contain only various security patches. The security issue exploits Python's dict and set implementations. Carefully crafted input can lead to extremely long computation times a...

[RELEASED] Second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're chuffed to announce the immediate availability of the second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3. The only change from the first release candidates is the patching of an additional security hole. The security issue fixed in the second release candidates is in the expat XML parsing library. expat had the same hash security issue detailed below as Python's core types. The hashing algorithm used in the expat library is now randomized. A more thorough explanation of the "hash attack" security hole follows. The main impetus for these rele...

[RELEASED] Second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3
We're chuffed to announce the immediate availability of the second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3. The only change from the first release candidates is the patching of an additional security hole. The security issue fixed in the second release candidates is in the expat XML parsing library. expat had the same hash security issue detailed below as Python's core types. The hashing algorithm used in the expat library is now randomized. A more thorough explanation of the "hash attack" security hole follows. The main impetus for these releases is fi...

ANNOUNCE: Release of DJGPP ports of GCC-5.2.0, GCC-4.9.3, GCC-4.8.5,, GCC-4.7.4 and GCC-3.4.6 for DJGPP v2.05
This is announcement of GCC-5.2.0, GCC-4.9.3, GCC-4.8.5, GCC-4.7.4 and GCC-3.4.6 for DJGPP v2.05 GCC used to stand for the GNU C Compiler, but since the compiler supports several other languages aside from C, it now stands for the GNU Compiler Collection. All these GCC versions are built using DJGPP v2.05 under Windows Vista Business SP3. Requirements for using binary packages: - DJGPP v2.05 (packages are NOT intended to be used with DJGPP v2.03) - binutils-2.22 or above (binutils-2.24 or above recommended) Currently all packages are still located at: ftp://ftp.de...

pgsql: Update release history for releases 7.4.6, 7.3.8, 7.2.6.
Log Message: ----------- Update release history for releases 7.4.6, 7.3.8, 7.2.6. Modified Files: -------------- pgsql/doc/src/sgml: release.sgml (r1.301 -> r1.302) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/release.sgml.diff?r1=1.301&r2=1.302) ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend ...

Safari 8.0.3, Safari 7.1.3, and Safari 6.2.3 Released
APPLE-SA-2015-01-27-3 Safari 8.0.3, Safari 7.1.3, and Safari 6.2.3 Safari 8.0.3, Safari 7.1.3, and Safari 6.2.3 are now available and address the following: WebKit Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.5, OS X Yosemite v10.10.1 Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution Description: Multiple memory corruption issues existed in WebKit. These issues were addressed through improved memory handling. CVE-ID CVE-2014-3192 : cloudfuzzer CVE-2014-4476 : Apple CVE-2014-4477 : ...

Will Ruby 1.8.2 include tcl/tk 8.4.x instead of 8.3?
Will Ruby 1.8.2 release come with tcl/tk 8.4.7 libraries? Thanks. Hi, From: "H. Simpson" <nospam@asdlkfjhasldkjfsadlfhskadjfahsldfks.com> Subject: Will Ruby 1.8.2 include tcl/tk 8.4.x instead of 8.3? Date: Mon, 2 Aug 2004 17:01:40 +0900 Message-ID: <HwmPc.1858$Z56.480@newssvr33.news.prodigy.com> > Will Ruby 1.8.2 release come with tcl/tk 8.4.7 libraries? Is that a binary package of Ruby 1.8.2 ? If you say about source files, Ruby/Tk can work with Tcl/Tk8.4.7. I already tested that Ruby/Tk works with Tcl/Tk8.4.7 and 8.5a1 (and ActiveTcl-8.4.6.1 binary package). U...

Tcl/Tk 8.6.3 Release Candidates
A fresh collection of release candidate files for Tcl/Tk 8.6.3 can now be found at https://sourceforge.net/projects/tcl/files/Tcl/8.6.3/ The collection includes the very latest sqlite3.8.7.1 release, as well as candidate releases for Itcl 4.0.2 and the 1.0.2 releases of the TDBC collection of packages. Thank you to the many who provided bug reports and bug fixes based on the previous RC's. This release is much better than it could have been without that participation. The aim is to release these files next Wednesday, Nov 12, unless some new discovery provides a rea...

bind <Shift-something> does not work under XF 4.3 tcl 8.3.5, ActiveState 8.4.3
I have tried the following script, under XFree86-4.3.0-2 both with RedHat 8 and 9, either with the native RH tcl 8.3.5 and with the ActiveState tcl 8.4.3 distributions. In all these platform combinations, the binding of <Shift-* does not work. For example, for Shift-F1, I get XF86_Switch_VT_1 (see xmodmap dump below), but the binded script is not triggered. However, the script works fine under Windows, with the same tcl distributions. Any hint? pack [entry .a] bind .a <Shift_L> {puts "hello, Shift"} bind .a <Shift-F1> {puts "hello, Shift-F1"} bind .a <...

RENEW 0.8.6.1.7.9.4.3.0.3.9.4.e164.arpa.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ProvID: DENIC-24 Enum-Domain: 0.8.6.1.7.9.4.3.0.3.9.4.e164.arpa. Action: RENEW Enum-Holder: DENIC-24-KF108 Admin-C: DENIC-24-KF108 Tech-C: DENIC-24-TSB4 Zone-C: DENIC-24-TSB4 Nserver: ns.dnsnglab.ipv6.berkom.de. Nserver: ns2.dnsnglab.ipv6.berkom.de. Remarks: TSI ENUM-Trial Teilnehmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBRXqOS9pACF8jgjwRArEvAJ4jBAdqTC8AKL+c0LL4RgXZ7J1f5gCgwXVo FgJZgHLnEk64xIRCM+S5XuI= =dC1s -----END PGP SIGNATURE----- ...

Question on migration from TCL 8.3 to TCL 8.6
Hi All, I am working on a EDA tool which is built on TCL 8.3 platform. I need to upgrade the platform to TCL 8.6. Is it proper to move directly from 8.3 to 8.6 version? Or should I upgrade to TCL 8.5 as TCL 8.6 is still beta version. Please suggest me precautions. Please point me to documentation/User guide related to this. Thanks for help, Divyesh On Thursday, 30 January 2014 04:47:57 UTC, Divyesh Patel wrote: > Is it proper to move directly from 8.3 to 8.6 version? Or should I upgrade to TCL 8.5 as TCL 8.6 is still beta version. > Tcl 8.6.1 is now the current ...

ANNOUNCE: freeWrap 8.6 released (supports TCL/TK 8.6.0)
This message announces the availability of freeWrap version 6.6. FreeWrap 6.6 is based on TCL/TK 8.6.0 freeWrap is a program that allows creation of stand-alone TCL/TK executables without needing a compiler. Versions are free and available for the Windows and Linux operating systems. Instructions and source code for building freeWrap are also available. The following additional variation of freeWrap is also available for download: freewrapTCLSH a console-only application which includes only TCL. Please visit the freeWrap home page: http://freewrap....

GnuPG / PGP signed checksums for PostgreSQL 7.4.5, 7.4.4, 7.3.7, 7.3.6, 7.3.5. 7.2.5
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a PGP-signed copy of the checksums for following PostgreSQL versions: 7.4.5 7.4.4 7.3.7 7.3.6 7.3.5 7.2.5 The latest copy of the checksums for these and other versions, as well as information on how to verify the files you download for yourself, can be found at: http://www.gtsm.com/postgres_sigs.html ## Created with md5sum: 97e750c8e69c208b75b6efedc5a36efb postgresql-7.4.5.tar.bz2 bffc3fe775c885489f9071e97f43ab9b postgresql-base-7.4.5.tar.bz2 548a73c898e65f901dbc06d622a2bc63 postgresql-docs-7.4.5.tar.b...

Web resources about - Tcl/Tk 8.6.3, Itcl 4.0.2, sqlite 3.8.7 Release Candidates - comp.lang.tcl

Candidate - Wikipedia, the free encyclopedia
For Nominee redirects here. For the financial term, see Nominee account , see Candidate (disambiguation) . In the context of elections for public ...

DCCC Trying To Force Some Rich Candidate From Orange County On Santa Clarita
... district but who was "given" the district by the DCCC. He lives in Orange County. Instead of supporting Lou Vince, the grassroots-backed candidate ...

Who Decides Who The Candidate Will Be— Locals Or The DCCC?
... are even important to the people in the district. He lives in Orange County. Instead of supporting Lou Vince, the grassroots-backed candidate ...

John Krasinski: I’m Disgusted By Candidates Using New Benghazi Film As ‘Political Football’
John Krasinski: I’m Disgusted By Candidates Using New Benghazi Film As ‘Political Football’

Tennessee Democrats introduce bill to bar candidates who aren't 'natural born citizens' from ballot
Two Democratic state lawmakers in Tennessee have introduced legislation to keep any presidential candidate who is not a "natural born citizen" ...

Candidates Aren’t Visiting Poorer Parts Of Des Moines
We spent last week driving all over Iowa, but Des Moines was our home base. That’s generally true for candidates as well: They campaign across ...

7 days to win hearts and minds: Candidates race to Iowa kick-off
With seven days until Iowans take the first official step in determining the fate of 2016's presidential hopefuls, Donald Trump and Hillary Clinton ...

Has tech found its presidential candidate? Bloomberg considers run, report says
... States, according to a report in The New York Times. If he does, his track record and experience would likely make him an attractive candidate ...

Dalit majority colonies chase away BJP candidates
Huge banners were also put up in many colonies asking “anti-Dalit people” not to come asking for votes. BJP candidates contesting the Greater ...

Next Republican Debate Schedule: When Does Donald Trump Face Ted Cruz, Megyn Kelly, Other Candidates ...
... into Iowa to fend off another round of verbal attacks from his closest rival, ultra-conservative Texas Senator Ted Cruz, and at four more candidates ...

Resources last updated: 1/26/2016 9:39:50 AM