Path.GetBounds() : The size component returned is incorrect and inaccurate for a base 10 structure RRS feed

  • Question

  • Hello, this my first question, what I am reporting is not a bug in the classic sense, it looks like a misrepresentation of the metrics definition for System.Drawing (Size) in the path object; in particular the bounding box size: GetBounds().

    This question has not had an accurate response based upon my research by other users. So I challenge again the following:

    The question:

    Why does it appear that a reported size from a System.Drawing library method, denoted herein, can magically not equal the actual physical size it is reporting in terms of the very definition for the size structure it represents? Is it reasonable to assume there is another definition for size not documented or maybe those rules simply do not apply to the method authors? There seems to be no contextual reason why this issue exits other than perhaps a possible shortcut was implemented to save a few ticks. It is not a show stopper yet it’s frustrating all the same when things do not add up correctly. I'm talking about the usage of the size structure to represent data when that data should be represented using another structure, like LocationSize.


    When constructing a figure be it a triangle, circle or polygon, a user supplies points for each required segment (line, arc etc) and each are connected in series, point to point, typically ending back to the starting point (origin) thereby closing and forming the figure often creating a shape. These asserted points are "location" point coordinates on grid (x , y) and are typically added to a graphics path object for eventual rendering to a graphics surface by the way of methods like DrawPath and FillPath. Sounds simple enough right?

    If it is agreed that "points" and "path points" are location coordinates on a grid (x, y); Where this grid and coordinates at (0 , 0) represents the first pixel on a graphics surface (top left hand corner) since we are talking about the GDI+ graphics surface here and not virtual vectors, then we can continue. This preamble is to limit this discussion to location and size of rendered graphics at discreet integer pixels locations and should help to avoid confusion and complexities that is often added to these discussions when referencing vectored graphic objects since those figures may also include sub pixel boundaries which are neither relevant nor implemented herein.

    Steps to observe this problem:

    1. (Recommend: draw path --> Small Square at any reasonable location just not on the graphics origin for easy location referencing and to ensure the figure is rendered correctly. Example path coordinates:

           Point[] TestArray ={new Point(20,20), new Point(60,20), new Point(60,60), new Point(20,60), new Point(20,20)};

    The above path coordinates forms a simple square outline when drawn to screen using Graphics.DrawPath(). 

    1. Using the suggested figure render to the graphics surface using no AntiAlias, preferably to the screen for examination and screen capture (this will rule out any DPI comments including sub pixel rendering theories). Include for reference your figure’s path bounding box which can be obtained by using Path.GetBounds() and record the rectangle information for later comparison.

    2. Using screen capture, copy the rendered figure to clipboard and paste it in Microsoft paint or your favorite paint program. Measure the size of your figure and its location. If your figure is the suggested square; how many pixels for width and height is it and record the size results. To get the figures location, the easy way, count how many pixels occupy only empty space between the graphics origin (0 , 0) and the very first pixel occupied by your figure from both left and top locations and record as being location X and Y respectively. Record the location and size information in rectangle format just to be concise for the following comparison.

    Sub note: This above method is similar in principal to how a control's screen bounds are calculated when using Control.PointToScreen which is accurate and returns the control's screen rectangle relative to the top left corner of the virtual desktop and includes the size of the control. Why is this method accurate?

    1. Compare your manually measured figure information between the returned Path.GetBounds() information.

    The Path.GetBounds() for the path example provided returns:

    RectangleF(PointF(20,20), SizeF(40,40)),  it should be instead à

    RectangleF(PointF(20,20), SizeF(41,41)), per the rule location to size = point size (x + 1, y + 1)

    The problem:

    The manually measured screen size for the figure does not equal the figure’s path get bounding box rectangle size. The path get bounds size is actually the location-size representing the difference between points violating the definition of System.Drawing.Size - these two concepts, location and size, are different as one is base zero the other is base 10 where Size is base 10.

    Rule_1: Size to location equals (size: width - 1, height – 1) and location to size = (location: X + 1, Y + 1) to be accurate when converting between base 0 and base 10. That is how controls metrics are reported and translated elsewhere.

    It is also improper to denote base 0 in a Size structure no matter if it is in a rectangle or by itself.


    Why is Visual Studio, the premier programming suite, still allowing these anomalies to propagate - that is using a defined structure like Size and not adhering to definition of which that structure entails in its own implementations. Is there a graphics library which properly represents the size and location structure in the current context?

    In summation:

    This "one off pixel point" scenario is referenced across the board in Microsoft forums and in other forums which only contributes to the extensive complexity in decoding that which otherwise should not exist in current context should size mean size and location mean location. Maybe I'm asking too much that size just means size and that location just means location for pixel sakes? Lol.

    Parameters which define library methods should be more upfront in IntelliSense concerning returned results versus expected results in particular when intentionally deviating from previously defined context like size.

    It's my goal to make computer programming more about "the fun, the productivity and getting to those results sooner than later" and hopefully in do so with much less pain and frustration that can arise when the math just does not add up and it's not the programmers fault! It is enough dealing with floating point, debugging one’s code and also having to deal with anomalies that should not exist in a state of the art programming suite like Visual studios. I rest my case. lol.

    P.S. Become cranky I’ll be when blindly quoting documents read not by you, may the force be with you. Yes!

     Yours truly, ImplementsMasterYoda.

    • Edited by Jamie2010 Thursday, April 12, 2018 7:07 PM
    Thursday, April 12, 2018 7:06 PM