Re: [Kicad-developers] Strokefont change from std::deque to std::vector

On 12/3/19 9:46 AM, Jeff Young wrote: OK, my stuff is pushed On 3 Dec 2019, at 17:44, Jeff Young > wrote: 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

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

OK, my stuff is pushed > On 3 Dec 2019, at 17:44, Jeff Young wrote: > > 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

Re: [Kicad-developers] 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. Cheers,

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

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

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

Hi Simon, I’m already doing that — it helps a little but less than I thought it would. Cheers, Jeff. PS: I’m trying out another version which pre-flights the number of strokes, but not the number of points in each stroke. > On 3 Dec 2019, at 15:42, Simon Richter wrote: > > Hi, > > On Tue,

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

Hi, On Tue, Dec 03, 2019 at 03:27:26PM +, Jeff Young wrote: > 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. Would it make sense to build it

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

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

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

On 12/2/19 3:45 PM, Jeff Young wrote: Hi Seth, What was the reason for the change from std::deque to std::vector?  Building the stroke font is now accounting for 50% of document load time (I /think/ because we’re using a 2D vector so that any resize of any constituent vector has to

Re: [Kicad-developers] Strokefont change from std::deque to std::vector

Jeff, I believe this change is related to the out of memory error in Eeschema that JP reported after the CJK fonts were added (see list messages: https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg36655.html ) -Ian On Tue, 3 Dec 2019, 00:29 Jeff Young, wrote: > Hi Seth, > >

[Kicad-developers] Strokefont change from std::deque to std::vector

Hi Seth, What was the reason for the change from std::deque to std::vector? Building the stroke font is now accounting for 50% of document load time (I think because we’re using a 2D vector so that any resize of any constituent vector has to reallocate the whole shebang). We also load the