290 views
in Embedded Wizard Studio by

Hi experts,

    I got an issue that when Path of Views::FilledPath contains points of big value.

    Now that FilledPath's bounds <0, 0, 300, 300>. Path is initialized like,

Path.SetMaxNoOfSubPaths(1);
Path.InitSubPath(0, 100);
Path.Begin(0, 150, 150);
Path.AddLine(0, 18000, -8000);
Path.AddLine(0, 13000, 64000);
Path.Close(0);

  The result is not quite as expected.

  My question is, is there any size limit of Path coordinates' range / bounding rect range?

Thanks!

1 Answer

0 votes
by
Hello Sanitor,

very interesting question. To explain it I would need to dive into the internal aspects of the implemented algorithms.

Due to the fact that we address embedded systems with less power and few memory the implementation of the vector graphic raster algorithm is well optimized. One aspect of this optimization is the manner how vector graphic coordinates are encoded and calculated internally. These are 32-bit integer values with the lowest 4-bit used to address up to 16 sub-pixel. Effectively, the resulting 27-bit (32-bit - 4-bit - 1-sign bit) are able to address pixel lying in range -134217728 .. 134217727.

Further limiting aspect are the arithmetic operations performed with the values. Concrete the raster algorithm calculates with the coordinates to estimate where an edge does intersect the actually rasterized pixel row. These operations involve 32-bit integer multiplications. In worst case the algorithm may multiply the width with the height of an edge (an edge is the line segment connecting two consecutive corners in the path). If the result of such multiplication does exceed 31-bit, the value overflows.

By taking in account the above mentioned 4-bit used to address sub-pixel, the multiplied pixel coordinates may not exceed 23-bit (32-bit - 4-bit - 4-bit - 1-sign bit). In worst case the multiplied width and height of an edge may not exceed the value 8388607. This could be 8000 pixel width * 1000 pixel height. Or even 2890 * 2890 pixel if the edge has 45 degree slope. This means, that the effective limitation depends on the slope of the affected edge. There is no concrete fixed value for an individual coordinate. The limitation results from the combination of the affected coordinates.

So far the technical background. For reasons of performance optimization the raster algorithm neither verifies the resulting values for eventual overflows nor reports errors. What can you and we do?

1. I don't know your application case nor the reason for the large coordinates. You should eventually modify your implementation to use lower values.

2. We will discuss internally the actual implementation in context of eventual modification of the actual algorithm to allow larger values. This could include 64-bit integer arithmetic in the algorithm. However, we fear that this will have an impact on the performance of the algorithm. Actually we are in the final preparation stage of the next release. So that such modification can be addressed (if we decide to do this) in the next following version.

I hope this helps you a little bit to understand the technical backgrounds of this behaviour and eventually find a way to workaround it.

Best regards

Paul Banach
by
Very helpful, thank you!

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...