Tk Source Code

# Source this into wish. Test with

#

#   drawlines [makepts $count] $width

#   

# where $count is number of points, $width is width of
lines

# in pixels.

#

# Works well on unix.  Time required depends linearly
on the

# number of points, with thick lines (width>1) taking only

# marginally longer than thin lines.

#

# On Windows, thin lines (width=1) work well, with time

# required depending linearly on the number of points.

# Thick lines are rendered slowly, with time required

# increasing much worse than linear once the number of

# points is more than say 100.  On my Win98 box, with

# Tcl/Tk 8.4.1, 'drawlines [makepts 1638] 2' raises

# an illegal operation fault.  More points than this

# results in nothing being drawn.  On Win2k, system

# response becomes very sluggish as the number of points

# moves into the thousands.

Serhiy, many thanks for the fix! Merged into main, core-9-0-branch, and core-8-6-branch by commits [ca469b53], [52da8e78], and [8514323e].

Still present on Windows 11 with 9.1: a line of 20000 points takes 6 ms with -width 1, 21 s with -width 2 and hangs with -width 4; closed lines and polygon outlines are the same. GDI strokes a path with a geometric pen in time quadratic in the number of points. Fixed on branch win-wide-polyline-pieces in [baf1c209be]: wide solid polylines with more than 64 points are stroked in pieces of 32 points overlapping by two segments, with a flat-capped pen so that the seams are invisible; 20000 points with -width 4 now take 50 ms instead of more than a minute. Dashed lines are not split, because the dash pattern would restart in every piece, so a dashed wide line with thousands of points is still slow on Windows; the dashed lines of [663981] are two-point lines and are fast now.

Logged In: YES 
user_id=80530


any progress on this?

Logged In: YES 
user_id=80530

followup from the original reporter:

Bug 663981 reports 2 problems with long dashed lines, one on
Unix and
one on Win2k.  I suspect the Unix problem is related to the
line slope
problem we discussed earlier, which occurs on both Unix and
Windows.
Release 8.4.2 fixes this problem on Windows; someone should
check on
Unix but I bet it is fixed there too.

The Win2k problem reported in 663981 is still present in
8.4.2.  Bug
630171 is a Win2K problem, and is also still present in 8.4.2.
Additional info: In bug 663981, it states the problem on
Win2k goes
away if you remove the dash option.  It also goes away in my
tests (on
8.4.2 anyway) if you make the -width 1 instead of 4.  If
-dash is
implemented as a big collection of line segments, then
663981/Win2k may
actually be the same bug as 630171.

Logged In: YES 
user_id=72656

Is this addressed by 663981?

File Added - 34121: demo.tcl