Apparently, Windows places some limitations on the sizes of lines drawn. See attached project -- it seems the maximum length is $7FFFFFF = 2^27 - 1 This is hinted at by
http://support.microsoft.com/kb/299533 and
http://www.delphikingdom.com/library/library.asp?ID=13&Mode=2 (in Russian, search for "28.4" inside)

Should we:
1) Ignore it
2) Move to GDI+
3) Write some wrapper(s) to work around the problem?

On the more generic note, I have a need (in TChart) for some floating-point geometry
routines, like intersection of line with rectangle. Is there something like that in LCL? If not, should I add them to TChart or to some place in LCL?

Apparently, Windows places some limitations on the sizes of lines drawn. See attached project -- it seems the maximum length is $7FFFFFF = 2^27 - 1

That's perfectly sufficient for currently available screen and paper formats.

3) Write some wrapper(s) to work around the problem?

There is no problem with the output, the problem is the data source. When you want a picture of the whole earth (Google Earth like), you need an appropriate coordinate system and storage format for the data, and means to map the data into an canvas (zoom factor, section).

GDI allows to map arbitrary world coordinates to an viewport (mapping modes: MM_ISOTROPIC, MM_ANISOTROPIC). When the mapping parameters are of insufficient accuracy, the world coordinates will have to be mapped into viewport (canvas) coordinates outside the drawing system, with appropriate clipping. This is what you can provide.

I'm undecided how such mapping should be made available. One solution were a "high precision" canvas, with all methods overloaded for world coordinates as Int64 and/or Double/Extended, and added properties for the viewport mapping (genercis?). Another solution, with less methods, would require to map all coordinates prior to passing them to the canvas methods; not so nice to use, but with far less added methods, or encapsulated in a dedicated mapping object.

DoDi