Tk Source Code

Long dashed horizontal lines cause problems for the
canvas.  Consider
the following script:

    pack [canvas .c]
   .c create line 0 20 100000 20 -width 4 -fill red -dash .
   .c create line -100000 40 100000 40 -width 4 -fill
blue -dash .
   .c create line -32767 60 32767 60 -width 4 -fill
green -dash .

On Unix (RedHat 7.3),  the top red line is displayed
correctly.  The
middle blue line does not appear at all.  The lower
green line initially
does not appear.  But if you take another window and
drag it slowly
over top of the canvas, bits of the green line will
appear as Expose
events are processed.

On win2k, (VMWare on the same RedHat 7.3 machine) the
canvas
displays correctly but expose events take about 10
seconds to process.
While expose events are pending, the CPU is maxed out
at 100%
usage and the display is locked up.

The lines are displayed correctly (and quickly) if the
-dash option is
omitted.

Lines were fixed in 2003 by the clipper. With 8.6 and 9.1, polygons (also dashed), ovals, arcs and filled rectangles with coordinates far beyond +/-32767 are drawn correctly too. What remained was a dashed outline of a rectangle wider than +/-32767: .c create rectangle -100000 40 100000 60 -outline blue -width 4 -dash . drew nothing, because XDrawRectangle() got the clamped coordinates. Fixed on branch canvas-huge-rect-outline in [1846f1cb24]: the outline of such a rectangle is drawn as a clipped path, like lines and polygons.

Logged In: YES 
user_id=69293

The code to fix this problem for "line"s is in.
But I'm going to leave the bug open as a reminder
to myself to go back and check for the same problem
in polygons, arcs, rectangles, etc.

Logged In: YES 
user_id=137748

I have code for both Liang-Barsky and Cohen-Sutherland clipping 
routines if you want it.   For the canvas, I think the
Liang-Barsky 
algorithm is a better fit since canvas coordinates are
floating point.

--gah

Logged In: YES 
user_id=69293

I'm working on a clipper now.  I should be able to check in
code soon.

Logged In: YES 
user_id=137748

It's generous to call what Tk_CanvasDrawableCoords does
clipping.

Instead it's bounding the coordinates to the size of short
ints.  I did this 
for a while in the graph widget. It doesn't work.   Except
for horizontal
or vertical lines, it changes the slope of the line badly.  

Tk_CanvasDrawableCoords also doesn't leave room (dashes would
probably work if it clipped to +/-30000) for other
calcuations like 
dash offsets.

A Liang-Barsky or Cohen-Sutherland clipper is easy enough to
implement. But it would change the drawing code, since multiple
traces might be generated for a single continuous line.  A
single
XDrawLines call would no longer be sufficient.

--gah

Logged In: YES 
user_id=72656

It appears that tkCanvUtil.c:Tk_CanvasDrawableCoords does 
the clipping, but it is incorrect before it just clips a point 
without respect to how it might change the geometry of a 
larger object that uses it.  The clipping needs to be done 
upstream somewhere, and should probably also be done to 
clip to the viewable area instead of just 16-bit coords.  No 
need to ask X to draw something that will be clipped.

Logged In: YES 
user_id=137748

I don't think the problem is dashed lines.

Rather it has to do with the fact that 

   1) the coordinates are beyond the size of a short integer 
       (the size of an X coordinate) and 
   2) the canvas does no clipping of lines.

You'll notice that if the lines aren't horizontal (or
vertical) that
it doesn't matter if the lines are dashed or not.

This could be remedied by clipping the generated line segments
before asking X to draw them. The same type of thing would
need to be done for polygons and arcs.

--gah