kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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?

Cheers,

Wayne

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.
> 
> Regards,
> Thomas
> 
> 
> 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.
>>
>> Cheers,
>>
>> Wayne
>>
>> 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
>