kicad-developers team mailing list archive
Mailing list archive
Re: Internal units in the KiCAD source code
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Thu, 13 Feb 2020 14:47:21 -0500
addr=stambaughw@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
Compiling the internal units code multiple times is ugly but it could be
replaced by a pure virtual class that implements the internal units
specific scaling. Although a single common internal unit would be cleaner.
While 64 bit 1nm internal units would solve some issues, we have far
bigger issues to resolve than this for V6. There is also a significant
risk that it could break existing code so it's definitely not going to
happen for V6. We can discuss it for V7. One thing that can be said
for sure about 64 bit internal units is that there will be a performance
hit on 32 bit architectures. The questions are how much and do we care?
On 2/13/20 10:06 AM, Thomas Pointhuber wrote:
> Hi Wayne,
> I think, I was present at FOSDEM 2019 when talking about this issue.
> From what I understand, the current approach requires KiCad to compile
> the units for each package separately (because e.g. mapping IU<->mm is
> always different). This has two big problems:
> 1. the same code has to be compiled multiple times.
> 2. there is no "true" mapping from IU to other units. When I for example
> want to create a python API with one type of geometric primitives, this
> is a real problem. When I want to script into eeschema and pcbnew at the
> same time, how to choose the correct units?
> The solution discussed was to move to 64bit and to use
> constexpr/templates handling unit conversion. So a programmer can for
> example enter 2mm and the compiler automatically converts it into the
> internal unit like nm.
> I'm still in favour of improving this. The same with angles.
> Am 13.02.20 um 15:46 schrieb Wayne Stambaugh:
>> Hi Johannes,
>> Thank you for your suggestion but the internal units for each format
>> were chosen for a specific reason. There really is no justifiable
>> reason to change them as they have been carefully selected based on the
>> requirements of the objects they represent. Conversion code is provided
>> for each internal unit so plotting to standard units such as
>> millimeters, inches, etc is trivial. I'm not opposed to adding support
>> for changing the plot units. I am opposed to changing the internal units.
>> On 2/13/20 9:32 AM, Johannes Pfister wrote:
>>> The KiCAD code uses all kinds of different units for distances.
>>> Amongst other things I found:
>>> nm: pcbnew internal units
>>> 10nm: Gerbview internal units
>>> 100nm EEschema internal units
>>> 1um: PL-Editor internal units
>>> 0.1mil (2.54um): SetViewport
>>> 1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils
>>> And the native File formats use mm (pcbnew) and mil (EEschema).
>>> Something like SVG exports in 0.1 mil steps. I think that this is not
>>> very consistent and something like a PLOTTER class needs to handle
>>> different IU-sizes.
>>> My idea is to rewrite the internal units so that nm are used
>>> everywhere inside the source code, and only parts that write or read
>>> files and display data to or read data from the user should convert it
>>> to another unit system. I don't want to change any file formats.
>>> That would make it a bit more straightforward, more consistent, metric
>>> and an SVG-Plotter would use a metric step size. The disadvantage
>>> would be that there would be an about 2m or 4m limit in every
>>> direction, assuming int is 32 bit, which is AFAIK true for all
>>> platforms KiCAD current supports.
>>> Before i rewrite code, can you say what you guys think about it?
>>> Johannes Pfister
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp