1

I have a CAD application which uses Graphics32 (1.9.1) to draw the polygons using the PolygonTS drawing routines.

Things work OK when everything is on canvas, the problem comes when zooming into objects.

I can check if all points of a polygon are off screen and not draw it, the problem comes when drawing polygons which are partially on screen.

It appears that Graphics32 uses a fixed point vertex math scheme (Tfixedpoint) that effectively reduces the number of pixels it can handle to 65536 (16 bit). If a point on the polygon that is being drawn is over this value, then the math overflows and artefacts are drawn on screen.

This happens on quite modest zooms, I can't imagine this problem hasn't been come across before, yet a cursory search comes up with nothing. Having to manually cull polygons would negate the use of GR32.

Is there an alternative polygon drawing library for GR32 that uses 32 bit maths?

Andy k
  • 1,056
  • 1
  • 11
  • 22
  • I don't see any evidence of 16 bit. `TFixed` is 32 bit. I suggest that you present a clean [mcve]. – David Heffernan Aug 11 '16 at 08:20
  • @david Read the GR32 documentation. Tfixed is in 16:16 fixed point format, the clue is in the name. To convert a Tpoint integer vertex point to a GR32 Tfixedpoint, it is multiplied by 65535. Which reduced its pixel range to 65535. – Andy k Aug 11 '16 at 08:52
  • I remember encountering something similar in GDI on Win9x, which used 16 bit integer arithmetic internally. We solved that by performing our own clipping. Clearly you have to get in before the precision is lost. – David Heffernan Aug 11 '16 at 09:06
  • Yes, I had exactly the same problem in 95, the sum of the vertices had to add up to less than the precision. I worked around the problem by not drawing those objects that overranged, which is less than optimal. I am drawing thousands of polygons, If I have to manually cull, there seems little advantage in using GR32. – Andy k Aug 11 '16 at 09:11
  • 3
    The obvious conclusion here is that Graphics32 is designed for screen graphics. You're trying to use it for something other than screen graphics and this makes it break. Like David said, if you're trying to build a CAD program then you need to keep the CAD model separate from the screen's drawing surface. When you zoom, you'll have to do this in the model's precise coordinate space and only transform to screen space as the last step. It sounds like you're trying to fit the entire model into a canvas and that's clearly a bad idea. – J... Aug 11 '16 at 10:21
  • @j You may be correct but the pixel range of the fixedpoint math is +/- 32,768. That is insufficient for a modern printer canvas. – Andy k Aug 11 '16 at 10:53
  • @J FOrgot to mention, what you describe is exactly what happens in code, converstion to screen is the last step. I just wasn't expecting to have to apply clipping to the objects. I had assumed the graphics library would be clever enough to handle this, that is why we use libraries is it not? – Andy k Aug 11 '16 at 11:03
  • @Andyk Yes, but Graphics32 is heavily optimized for screen performance - you have to expect that this means they've sacrificed flexibility to gain that performance. – J... Aug 11 '16 at 20:21
  • @J can you post that as an answer and I will accept it. I will just have to work around the limitation or find another library. Maybe its time for graphics64 :) – Andy k Aug 12 '16 at 07:31

0 Answers0