kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

He he… I had sort of the same idea, only I’m building it lazily at runtime.  But I think your idea would be even better.

Since I’ve already made the changes to have STROKE_FONT use const pointers to the data structures, let me merge in first and then you can move it to compile-time.

Cheers,
Jeff.


> On 3 Dec 2019, at 17:40, Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:
> 
> On 12/3/19 7:27 AM, Jeff Young wrote:
>> Hi Seth,
>> 
>> Trying to keep track of lengths is going to be ugly.  I did re-write the bounding-box calc (which saves a bunch), and re-mapped the initialisation to use stack storage until all the points had been allocated (which saves a little).
>> 
>> But it’s still too slow (especially when you try to edit a pad).
>> 
>> A glyph is an array of strokes; a stroke is an array of points.  Do you remember which was giving the issue?  (Or was it both?)
>> 
>> Changing the glyph back to a deque (and leaving the strokes vectors) would probably alleviate much of the performance hit — but I’m not sure if it would bring back the memory issues or not.
>> 
>> Cheers,
>> Jeff.
> 
> Hi Jeff-
> 
> How about this solution:
> 
> There's no reason we need to keep generating Hershey.  It is bulky, we can't read it by a human anyway and we waste time reloading.
> 
> Instead, I'll adjust the generation script to build the vector<vector<vector<VECTOR2D>>> structure as a constant.  Then we can just reference it and it is converted at compile time.
> 
> If you're OK with this plan, I'll do the adjustment.
> 
> Best-
> Seth
> 
> -- 
>  
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬ <tel:+12126039372>
> Davis, CA
> www.kipro-pcb.com <https://www.kipro-pcb.com/>    info@xxxxxxxxxxxxx <mailto:info@xxxxxxxxxxxxx>
>  <https://twitter.com/KiProEDA>   <https://twitter.com/KiProEDA>	 <https://www.linkedin.com/company/kicad>   <https://www.linkedin.com/company/kicad>