kicad-developers team mailing list archive
Mailing list archive
Re: Strokefont change from std::deque to std::vector
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.
> 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.
> 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.
> 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>