Re: [Kicad-developers] Mac HighDPI performance

[Maciej Sumiński]

Wayne,

According to our plan, eeschema GALification is one of the major points
of v6 roadmap. We plan to start it early, but I think it is better to
begin with the schematic model refactor, as GAL and Tool Framework
heavily rely on that. Doing things in reverse order means we will have
more code to fix once the model changes.

Cheers,
Orson

On 03/04/2018 08:46 PM, Wayne Stambaugh wrote:
> I agree.  If it's not an easy straight forward fix, I would prefer to
> spend our precious manpower resources on the GAL port as well.  I don't
> know when in the v6 cycle any of this will happen but I'm guessing it
> will happen fairly early.  Tom or Orson, do either of you have any idea
> when this will happen?
> 
> Wayne
> 
> On 03/04/2018 02:40 PM, Jon Evans wrote:
>> FWIW, I don't find the existing performance to be unusable, it's just
>> not up to the standards of PcbNew/GAL.  I don't think it's worth any
>> effort beyond easy fixes, we should put that energy into the GAL port. 
>>
>> -Jon
>>
>> On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier > > wrote:
>>
>> I would judge it wrt eeschema GAL conversion.
>> If that starts with v6, I don’t know if it is worth the effort.
>> If it is unsure when this will happen, it might be worth it.
>>
>>
>>> On 4. Mar 2018, at 20:30, Wayne Stambaugh >> > wrote:
>>>
>>> Ughh!  I don't have a good answer for this one.  My best guess is
>>> to fix
>>> the wx macos code first and see what performance issues are left.  The
>>> problem with messing with any of this is that if you break
>>> something it
>>> will break all of the legacy canvas rendering not just the schematic
>>> editor.  I would move extremely carefully here.  I would prefer
>>> that we
>>> don't go too crazy this late in the v5 release cycle.  If the
>>> performance is truly not usable on macos, then we may have no choice.
>>>
>>> On 03/04/2018 02:07 PM, Jeff Young wrote:
 It turns out the fonts aren’t really the problem.

 It starts with this gem in wxWidgets:

    voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)

    {

    #if1

    SetNeedsDisplay();

    #else

    //Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.

    if(GetNeedsDisplay())

    {

    SetNeedsDisplay() ;

    }

    NSRectr=wxToNSRect([m_osxViewsuperview],*rect);

    NSSizeoffset=NSMakeSize((float)dx,(float)dy);

    [m_osxViewscrollRect:rby:offset];

    #endif

    }


 SetNeedsDisplay() with no rectangle argument invalidates the
 entire window.

 Even if you fix that (to scroll most of the window and only
 invalidate
 the newly-exposed parts), you run into this:

    
 voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))

    {

    //preparingtheupdateregion

    wxRegionupdateRgn;


    
 //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect

    #if0

    constNSRect*rects;

    NSIntegercount;

    [slfgetRectsBeingDrawn::];

    for(inti=0;iCLOCKS_PER_SEC/30)

    {

    s_lastFlush=clock();

    m_nowpeer->Update();

    }

    }


 But even Kicad isn’t blameless.  Once you fix all those there’s
 still no
 checking in SCH_SCREEN::Draw() to see if the individual draw items
 intersect the update region.  (Sure, the actually drawing is
 clipped in
 the end, but you still go through a /lot/ of code to get there.)

 All of these are fixable, and we’ve already crossed the Rubicon of
 having our own OSX wxWidgets branch.  

 But it’s still a reasonable amount of work, with a non-trivial risk
 profile.  Should I continue?

 Cheers,
 Jeff.



> On 4 Mar 2018, at 01:30, Bernhard Stegmaier
> 

Re: [Kicad-developers] Mac HighDPI performance

[Andrey Kuznetsov]

Of course Wayne, that was my way of expressing concern for delaying a
performance issue and trying to sauce out your feeling of the possible
duration of v6 development.
Do you think there is currently manpower and list of features that requires
1 year plus 6 months delay, or do you think it's more like 2 years best
case and 1 year of delay worst case time of thing?

On Sun, Mar 4, 2018 at 5:03 PM, Wayne Stambaugh 
wrote:

> When you become the project leader of KiCad, then you can make these
> decisions and live with the consequences of them.  In the mean time, that
> responsibility falls on my shoulders.  We are in a feature freeze for v5
> stable so I'm going to err on the side of caution here.  If we can pick up
> some performance gains without pushing the v5 stable release out, then I'm
> fine with that but if there are any stability issues then we will have to
> live with what we have.  Implementing this at the beginning of v6 and back
> porting it when it's stable is also acceptable.  Hopefully v6 will not take
> 2-3 years.
>
> Wayne
>
> On 03/04/2018 07:00 PM, Andrey Kuznetsov wrote:
>
>> If 6.0 is coming in 1 year, OK, but if it's 2-3 years away then I'd say
>> v5.0 should be stable and not have performance issues, in my mind better to
>> delay v5 up to 1 month at most to fix it rather than let it sit like that
>> for 2-3 years.
>>
>> On Sun, Mar 4, 2018 at 3:39 PM, Jeff Young  j...@rokeby.ie>> wrote:
>>
>> As for road-map, I’d suggest that EeschemaGAL + newSymbolFileFormat
>> == 6.0.  Anything else that can ride along is fine, but not
>> definitive.
>>
>> The legacy stuff represents a tax on all development we do.
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 4 Mar 2018, at 23:31, Jeff Young >> > wrote:
>>>
>>> Well, I pounded on it a bit more, and it wasn’t really fitting
>>> into “easy” /or/ “straight forward”.  It’ll have to wait.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>> On 4 Mar 2018, at 20:07, Jon Evans > wrote:

 We should probably make some kind of road map if it doesn't exist
 already, concerning the path to GAL for eeschema and who will be
 doing what. For example, it might make sense to do the SCHEMATIC
 class refactoring you were talking about before or in parallel
 with parts of the porting effort.

 I'm up for working on this too, as soon as my connectivity / bus
 stuff has landed.

 -Jon

 On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh > wrote:

 I agree.  If it's not an easy straight forward fix, I would
 prefer to
 spend our precious manpower resources on the GAL port as
 well.  I don't
 know when in the v6 cycle any of this will happen but I'm
 guessing it
 will happen fairly early.  Tom or Orson, do either of you
 have any idea
 when this will happen?

 Wayne

 On 03/04/2018 02:40 PM, Jon Evans wrote:
 > FWIW, I don't find the existing performance to be unusable,
 it's just
 > not up to the standards of PcbNew/GAL.  I don't think it's
 worth any
 > effort beyond easy fixes, we should put that energy into
 the GAL port.
 >
 > -Jon
 >
 > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier
 
 > >> wrote:
 >
 > I would judge it wrt eeschema GAL conversion.
 > If that starts with v6, I don’t know if it is worth the
 effort.
 > If it is unsure when this will happen, it might be
 worth it.
 >
 >
 >> On 4. Mar 2018, at 20:30, Wayne Stambaugh
 
 >> >> wrote:
 >>
 >> Ughh!  I don't have a good answer for this one.  My
 best guess is
 >> to fix
 >> the wx macos code first and see what performance
 issues are left.  The
 >> problem with messing with any of this is that if you
 break
 >> something it
 >> will break all of the legacy canvas rendering not just
 the schematic
 >> editor.  I would move extremely carefully here.  I
 would prefer
 >> that we
 >> don't go too crazy this late in the v5 release 

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Jeff Young]

OK, I’ll merge Michael’s patch as it is (only fixing the mac package strings to 
match the window titles).

@Michael, I merged your patch.  Thanks for your contribution.

Cheers,
Jeff.


> On 5 Mar 2018, at 01:06, Wayne Stambaugh  wrote:
> 
> The capitalization which has always been part of the original naming scheme, 
> although there have been bugs in the strings from time to time.
> 
> On 03/04/2018 08:01 PM, Jeff Young wrote:
>> The names or the capitalisation?  We’re only suggesting changing the 
>> capitalisation, which varies from place to place anyway.
>> Cheers,
>> Jeff
>>> On 5 Mar 2018, at 00:57, Wayne Stambaugh  wrote:
>>> 
>>> These are the names assigned by the founder of the project (JP).  They are 
>>> not open for debate.
>>> 
>>> On 03/04/2018 07:32 PM, Jeff Young wrote:
 Anyone care if we go the other way with some of these (ie: rename Eeschema 
 window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?
> On 4 Mar 2018, at 22:43, Bernhard Stegmaier  
> wrote:
> 
> I guess it just is like that because the Linux binaries are also written 
> like that and it has always been like that… :)
> 
> 
> Regards,
> Bernhard
> 
>> On 4. Mar 2018, at 23:37, Michael Kavanagh  
>> wrote:
>> 
>> The attached trivial patch fixes the app menubar items to match the
>> window titles, as well as when you "Quicklook" an executable, in
>> activity monitor and probably some other places as well.
>> 
>> As a side is there any reason why the bundle/symlink names aren't
>> capitalised/contain underscores instead of spaces? See attached
>> screenshot.
>> 
>> Regards,
>> Michael
>> <0001-macOS-standardise-CFBundleName-to-application-names.patch>> Shot 2018-03-04 at 
>> 17.39.07.png>___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Wayne Stambaugh]

The capitalization which has always been part of the original naming 
scheme, although there have been bugs in the strings from time to time.


On 03/04/2018 08:01 PM, Jeff Young wrote:

The names or the capitalisation?  We’re only suggesting changing the 
capitalisation, which varies from place to place anyway.

Cheers,
Jeff



On 5 Mar 2018, at 00:57, Wayne Stambaugh  wrote:

These are the names assigned by the founder of the project (JP).  They are not 
open for debate.

On 03/04/2018 07:32 PM, Jeff Young wrote:

Anyone care if we go the other way with some of these (ie: rename Eeschema 
window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?

On 4 Mar 2018, at 22:43, Bernhard Stegmaier  wrote:

I guess it just is like that because the Linux binaries are also written like 
that and it has always been like that… :)


Regards,
Bernhard


On 4. Mar 2018, at 23:37, Michael Kavanagh  wrote:

The attached trivial patch fixes the app menubar items to match the
window titles, as well as when you "Quicklook" an executable, in
activity monitor and probably some other places as well.

As a side is there any reason why the bundle/symlink names aren't
capitalised/contain underscores instead of spaces? See attached
screenshot.

Regards,
Michael
<0001-macOS-standardise-CFBundleName-to-application-names.patch>___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

When you become the project leader of KiCad, then you can make these 
decisions and live with the consequences of them.  In the mean time, 
that responsibility falls on my shoulders.  We are in a feature freeze 
for v5 stable so I'm going to err on the side of caution here.  If we 
can pick up some performance gains without pushing the v5 stable release 
out, then I'm fine with that but if there are any stability issues then 
we will have to live with what we have.  Implementing this at the 
beginning of v6 and back porting it when it's stable is also acceptable. 
 Hopefully v6 will not take 2-3 years.


Wayne

On 03/04/2018 07:00 PM, Andrey Kuznetsov wrote:
If 6.0 is coming in 1 year, OK, but if it's 2-3 years away then I'd say 
v5.0 should be stable and not have performance issues, in my mind better 
to delay v5 up to 1 month at most to fix it rather than let it sit like 
that for 2-3 years.


On Sun, Mar 4, 2018 at 3:39 PM, Jeff Young > wrote:


As for road-map, I’d suggest that EeschemaGAL + newSymbolFileFormat
== 6.0.  Anything else that can ride along is fine, but not definitive.

The legacy stuff represents a tax on all development we do.

Cheers,
Jeff.



On 4 Mar 2018, at 23:31, Jeff Young > wrote:

Well, I pounded on it a bit more, and it wasn’t really fitting
into “easy” /or/ “straight forward”.  It’ll have to wait.

Cheers,
Jeff.


On 4 Mar 2018, at 20:07, Jon Evans > wrote:

We should probably make some kind of road map if it doesn't exist
already, concerning the path to GAL for eeschema and who will be
doing what. For example, it might make sense to do the SCHEMATIC
class refactoring you were talking about before or in parallel
with parts of the porting effort.

I'm up for working on this too, as soon as my connectivity / bus
stuff has landed.

-Jon

On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh > wrote:

I agree.  If it's not an easy straight forward fix, I would
prefer to
spend our precious manpower resources on the GAL port as
well.  I don't
know when in the v6 cycle any of this will happen but I'm
guessing it
will happen fairly early.  Tom or Orson, do either of you
have any idea
when this will happen?

Wayne

On 03/04/2018 02:40 PM, Jon Evans wrote:
> FWIW, I don't find the existing performance to be unusable,
it's just
> not up to the standards of PcbNew/GAL.  I don't think it's
worth any
> effort beyond easy fixes, we should put that energy into
the GAL port.
>
> -Jon
>
> On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier

> >> wrote:
>
>     I would judge it wrt eeschema GAL conversion.
>     If that starts with v6, I don’t know if it is worth the
effort.
>     If it is unsure when this will happen, it might be
worth it.
>
>
>>     On 4. Mar 2018, at 20:30, Wayne Stambaugh

>>     >> wrote:
>>
>>     Ughh!  I don't have a good answer for this one.  My
best guess is
>>     to fix
>>     the wx macos code first and see what performance
issues are left.  The
>>     problem with messing with any of this is that if you break
>>     something it
>>     will break all of the legacy canvas rendering not just
the schematic
>>     editor.  I would move extremely carefully here.  I
would prefer
>>     that we
>>     don't go too crazy this late in the v5 release cycle. 
If the

>>     performance is truly not usable on macos, then we may
have no choice.
>>
>>     On 03/04/2018 02:07 PM, Jeff Young wrote:
>>>     It turns out the fonts aren’t really the problem.
>>>
>>>     It starts with this gem in wxWidgets:
>>>
>>>   
voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)

>>>
>>>    {
>>>
>>>    #if1
>>>
>>>    SetNeedsDisplay();
>>>
>>>    #else
>>>
>>>   
//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.

>>>
>>>    if(GetNeedsDisplay())
>>>
>>>    {
>>>
>>>    SetNeedsDisplay() ;
>>>
>>>    }
>>>
>>>    

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Jeff Young]

The names or the capitalisation?  We’re only suggesting changing the 
capitalisation, which varies from place to place anyway.

Cheers,
Jeff


> On 5 Mar 2018, at 00:57, Wayne Stambaugh  wrote:
> 
> These are the names assigned by the founder of the project (JP).  They are 
> not open for debate.
> 
> On 03/04/2018 07:32 PM, Jeff Young wrote:
>> Anyone care if we go the other way with some of these (ie: rename Eeschema 
>> window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?
>>> On 4 Mar 2018, at 22:43, Bernhard Stegmaier  wrote:
>>> 
>>> I guess it just is like that because the Linux binaries are also written 
>>> like that and it has always been like that… :)
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 4. Mar 2018, at 23:37, Michael Kavanagh  
 wrote:
 
 The attached trivial patch fixes the app menubar items to match the
 window titles, as well as when you "Quicklook" an executable, in
 activity monitor and probably some other places as well.
 
 As a side is there any reason why the bundle/symlink names aren't
 capitalised/contain underscores instead of spaces? See attached
 screenshot.
 
 Regards,
 Michael
 <0001-macOS-standardise-CFBundleName-to-application-names.patch Shot 2018-03-04 at 
 17.39.07.png>___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Wayne Stambaugh]

These are the names assigned by the founder of the project (JP).  They 
are not open for debate.


On 03/04/2018 07:32 PM, Jeff Young wrote:

Anyone care if we go the other way with some of these (ie: rename Eeschema 
window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?


On 4 Mar 2018, at 22:43, Bernhard Stegmaier  wrote:

I guess it just is like that because the Linux binaries are also written like 
that and it has always been like that… :)


Regards,
Bernhard


On 4. Mar 2018, at 23:37, Michael Kavanagh  wrote:

The attached trivial patch fixes the app menubar items to match the
window titles, as well as when you "Quicklook" an executable, in
activity monitor and probably some other places as well.

As a side is there any reason why the bundle/symlink names aren't
capitalised/contain underscores instead of spaces? See attached
screenshot.

Regards,
Michael
<0001-macOS-standardise-CFBundleName-to-application-names.patch>___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Andrey Kuznetsov]

I'd prefer it actually, since it uses proper capitalization of
abbreviations. But that's just me and aesthetics.

On Sun, Mar 4, 2018 at 4:32 PM, Jeff Young  wrote:

> Anyone care if we go the other way with some of these (ie: rename Eeschema
> window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?
>
> > On 4 Mar 2018, at 22:43, Bernhard Stegmaier 
> wrote:
> >
> > I guess it just is like that because the Linux binaries are also written
> like that and it has always been like that… :)
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 4. Mar 2018, at 23:37, Michael Kavanagh 
> wrote:
> >>
> >> The attached trivial patch fixes the app menubar items to match the
> >> window titles, as well as when you "Quicklook" an executable, in
> >> activity monitor and probably some other places as well.
> >>
> >> As a side is there any reason why the bundle/symlink names aren't
> >> capitalised/contain underscores instead of spaces? See attached
> >> screenshot.
> >>
> >> Regards,
> >> Michael
> >> <0001-macOS-standardise-CFBundleName-to-application-names.patch> Shot 2018-03-04 at 17.39.07.png>_
> __
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Jeff Young]

Anyone care if we go the other way with some of these (ie: rename Eeschema 
window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)?

> On 4 Mar 2018, at 22:43, Bernhard Stegmaier  wrote:
> 
> I guess it just is like that because the Linux binaries are also written like 
> that and it has always been like that… :)
> 
> 
> Regards,
> Bernhard
> 
>> On 4. Mar 2018, at 23:37, Michael Kavanagh  
>> wrote:
>> 
>> The attached trivial patch fixes the app menubar items to match the
>> window titles, as well as when you "Quicklook" an executable, in
>> activity monitor and probably some other places as well.
>> 
>> As a side is there any reason why the bundle/symlink names aren't
>> capitalised/contain underscores instead of spaces? See attached
>> screenshot.
>> 
>> Regards,
>> Michael
>> <0001-macOS-standardise-CFBundleName-to-application-names.patch>> 2018-03-04 at 17.39.07.png>___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Mac HighDPI performance

[Andrey Kuznetsov]

If 6.0 is coming in 1 year, OK, but if it's 2-3 years away then I'd say
v5.0 should be stable and not have performance issues, in my mind better to
delay v5 up to 1 month at most to fix it rather than let it sit like that
for 2-3 years.

On Sun, Mar 4, 2018 at 3:39 PM, Jeff Young  wrote:

> As for road-map, I’d suggest that EeschemaGAL + newSymbolFileFormat ==
> 6.0.  Anything else that can ride along is fine, but not definitive.
>
> The legacy stuff represents a tax on all development we do.
>
> Cheers,
> Jeff.
>
>
> On 4 Mar 2018, at 23:31, Jeff Young  wrote:
>
> Well, I pounded on it a bit more, and it wasn’t really fitting into “easy”
> *or* “straight forward”.  It’ll have to wait.
>
> Cheers,
> Jeff.
>
> On 4 Mar 2018, at 20:07, Jon Evans  wrote:
>
> We should probably make some kind of road map if it doesn't exist already,
> concerning the path to GAL for eeschema and who will be doing what. For
> example, it might make sense to do the SCHEMATIC class refactoring you were
> talking about before or in parallel with parts of the porting effort.
>
> I'm up for working on this too, as soon as my connectivity / bus stuff has
> landed.
>
> -Jon
>
> On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh  wrote:
>
>> I agree.  If it's not an easy straight forward fix, I would prefer to
>> spend our precious manpower resources on the GAL port as well.  I don't
>> know when in the v6 cycle any of this will happen but I'm guessing it
>> will happen fairly early.  Tom or Orson, do either of you have any idea
>> when this will happen?
>>
>> Wayne
>>
>> On 03/04/2018 02:40 PM, Jon Evans wrote:
>> > FWIW, I don't find the existing performance to be unusable, it's just
>> > not up to the standards of PcbNew/GAL.  I don't think it's worth any
>> > effort beyond easy fixes, we should put that energy into the GAL port.
>> >
>> > -Jon
>> >
>> > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier > > > wrote:
>> >
>> > I would judge it wrt eeschema GAL conversion.
>> > If that starts with v6, I don’t know if it is worth the effort.
>> > If it is unsure when this will happen, it might be worth it.
>> >
>> >
>> >> On 4. Mar 2018, at 20:30, Wayne Stambaugh > >> > wrote:
>> >>
>> >> Ughh!  I don't have a good answer for this one.  My best guess is
>> >> to fix
>> >> the wx macos code first and see what performance issues are left.
>> The
>> >> problem with messing with any of this is that if you break
>> >> something it
>> >> will break all of the legacy canvas rendering not just the
>> schematic
>> >> editor.  I would move extremely carefully here.  I would prefer
>> >> that we
>> >> don't go too crazy this late in the v5 release cycle.  If the
>> >> performance is truly not usable on macos, then we may have no
>> choice.
>> >>
>> >> On 03/04/2018 02:07 PM, Jeff Young wrote:
>> >>> It turns out the fonts aren’t really the problem.
>> >>>
>> >>> It starts with this gem in wxWidgets:
>> >>>
>> >>>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,
>> intdx,intdy)
>> >>>
>> >>>{
>> >>>
>> >>>#if1
>> >>>
>> >>>SetNeedsDisplay();
>> >>>
>> >>>#else
>> >>>
>> >>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
>> >>>
>> >>>if(GetNeedsDisplay())
>> >>>
>> >>>{
>> >>>
>> >>>SetNeedsDisplay() ;
>> >>>
>> >>>}
>> >>>
>> >>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
>> >>>
>> >>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
>> >>>
>> >>>[m_osxViewscrollRect:rby:offset];
>> >>>
>> >>>#endif
>> >>>
>> >>>}
>> >>>
>> >>>
>> >>> SetNeedsDisplay() with no rectangle argument invalidates the
>> >>> entire window.
>> >>>
>> >>> Even if you fix that (to scroll most of the window and only
>> >>> invalidate
>> >>> the newly-exposed parts), you run into this:
>> >>>
>> >>>voidwxWidgetCocoaImpl::drawRect(void*rect,
>> WXWidgetslf,void*WXUNUSED(_cmd))
>> >>>
>> >>>{
>> >>>
>> >>>//preparingtheupdateregion
>> >>>
>> >>>wxRegionupdateRgn;
>> >>>
>> >>>
>> >>>//sinceaddingmanyrectstoaregionisacostlyprocess,
>> bydefaultusetheboundingrect
>> >>>
>> >>>#if0
>> >>>
>> >>>constNSRect*rects;
>> >>>
>> >>>NSIntegercount;
>> >>>
>> >>>[slfgetRectsBeingDrawn::];
>> >>>
>> >>>for(inti=0;i> >>>
>> >>>{
>> >>>
>> >>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
>> >>>
>> >>>}
>> >>>
>> >>>#else
>> >>>
>> >>>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>> >>>
>> >>>#endif
>> >>>
>> >>>
>> >>> …which will /also/ cause the whole window to be repainted if
>> there’s
>> >>> both an invalidated horizontal strip and a vertical one.
>> 

Re: [Kicad-developers] Mac HighDPI performance

[Jeff Young]

As for road-map, I’d suggest that EeschemaGAL + newSymbolFileFormat == 6.0.  
Anything else that can ride along is fine, but not definitive.

The legacy stuff represents a tax on all development we do.

Cheers,
Jeff.


> On 4 Mar 2018, at 23:31, Jeff Young  wrote:
> 
> Well, I pounded on it a bit more, and it wasn’t really fitting into “easy” or 
> “straight forward”.  It’ll have to wait.
> 
> Cheers,
> Jeff.
> 
>> On 4 Mar 2018, at 20:07, Jon Evans > > wrote:
>> 
>> We should probably make some kind of road map if it doesn't exist already, 
>> concerning the path to GAL for eeschema and who will be doing what. For 
>> example, it might make sense to do the SCHEMATIC class refactoring you were 
>> talking about before or in parallel with parts of the porting effort.
>> 
>> I'm up for working on this too, as soon as my connectivity / bus stuff has 
>> landed. 
>> 
>> -Jon
>> 
>> On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh > > wrote:
>> I agree.  If it's not an easy straight forward fix, I would prefer to
>> spend our precious manpower resources on the GAL port as well.  I don't
>> know when in the v6 cycle any of this will happen but I'm guessing it
>> will happen fairly early.  Tom or Orson, do either of you have any idea
>> when this will happen?
>> 
>> Wayne
>> 
>> On 03/04/2018 02:40 PM, Jon Evans wrote:
>> > FWIW, I don't find the existing performance to be unusable, it's just
>> > not up to the standards of PcbNew/GAL.  I don't think it's worth any
>> > effort beyond easy fixes, we should put that energy into the GAL port. 
>> >
>> > -Jon
>> >
>> > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier > > 
>> > >> wrote:
>> >
>> > I would judge it wrt eeschema GAL conversion.
>> > If that starts with v6, I don’t know if it is worth the effort.
>> > If it is unsure when this will happen, it might be worth it.
>> >
>> >
>> >> On 4. Mar 2018, at 20:30, Wayne Stambaugh > >> 
>> >> >> wrote:
>> >>
>> >> Ughh!  I don't have a good answer for this one.  My best guess is
>> >> to fix
>> >> the wx macos code first and see what performance issues are left.  The
>> >> problem with messing with any of this is that if you break
>> >> something it
>> >> will break all of the legacy canvas rendering not just the schematic
>> >> editor.  I would move extremely carefully here.  I would prefer
>> >> that we
>> >> don't go too crazy this late in the v5 release cycle.  If the
>> >> performance is truly not usable on macos, then we may have no choice.
>> >>
>> >> On 03/04/2018 02:07 PM, Jeff Young wrote:
>> >>> It turns out the fonts aren’t really the problem.
>> >>>
>> >>> It starts with this gem in wxWidgets:
>> >>>
>> >>>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
>> >>>
>> >>>{
>> >>>
>> >>>#if1
>> >>>
>> >>>SetNeedsDisplay();
>> >>>
>> >>>#else
>> >>>
>> >>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
>> >>>
>> >>>if(GetNeedsDisplay())
>> >>>
>> >>>{
>> >>>
>> >>>SetNeedsDisplay() ;
>> >>>
>> >>>}
>> >>>
>> >>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
>> >>>
>> >>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
>> >>>
>> >>>[m_osxViewscrollRect:rby:offset];
>> >>>
>> >>>#endif
>> >>>
>> >>>}
>> >>>
>> >>>
>> >>> SetNeedsDisplay() with no rectangle argument invalidates the
>> >>> entire window.
>> >>>
>> >>> Even if you fix that (to scroll most of the window and only
>> >>> invalidate
>> >>> the newly-exposed parts), you run into this:
>> >>>
>> >>>
>> >>> voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
>> >>>
>> >>>{
>> >>>
>> >>>//preparingtheupdateregion
>> >>>
>> >>>wxRegionupdateRgn;
>> >>>
>> >>>
>> >>>
>> >>> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
>> >>>
>> >>>#if0
>> >>>
>> >>>constNSRect*rects;
>> >>>
>> >>>NSIntegercount;
>> >>>
>> >>>[slfgetRectsBeingDrawn::];
>> >>>
>> >>>for(inti=0;i> >>>
>> >>>{
>> >>>
>> >>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
>> >>>
>> >>>}
>> >>>
>> >>>#else
>> >>>
>> >>>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>> >>>
>> >>>#endif
>> >>>
>> >>>
>> >>> …which will /also/ cause the whole window to be repainted if there’s
>> >>> both an invalidated horizontal strip and a vertical one.
>> >>>
>> >>> And the latter turns out to be pretty much guaranteed by this
>> >>> one, 

Re: [Kicad-developers] Mac HighDPI performance

[Jeff Young]

Well, I pounded on it a bit more, and it wasn’t really fitting into “easy” or 
“straight forward”.  It’ll have to wait.

Cheers,
Jeff.

> On 4 Mar 2018, at 20:07, Jon Evans  wrote:
> 
> We should probably make some kind of road map if it doesn't exist already, 
> concerning the path to GAL for eeschema and who will be doing what. For 
> example, it might make sense to do the SCHEMATIC class refactoring you were 
> talking about before or in parallel with parts of the porting effort.
> 
> I'm up for working on this too, as soon as my connectivity / bus stuff has 
> landed. 
> 
> -Jon
> 
> On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh  > wrote:
> I agree.  If it's not an easy straight forward fix, I would prefer to
> spend our precious manpower resources on the GAL port as well.  I don't
> know when in the v6 cycle any of this will happen but I'm guessing it
> will happen fairly early.  Tom or Orson, do either of you have any idea
> when this will happen?
> 
> Wayne
> 
> On 03/04/2018 02:40 PM, Jon Evans wrote:
> > FWIW, I don't find the existing performance to be unusable, it's just
> > not up to the standards of PcbNew/GAL.  I don't think it's worth any
> > effort beyond easy fixes, we should put that energy into the GAL port. 
> >
> > -Jon
> >
> > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier  > 
> > >> wrote:
> >
> > I would judge it wrt eeschema GAL conversion.
> > If that starts with v6, I don’t know if it is worth the effort.
> > If it is unsure when this will happen, it might be worth it.
> >
> >
> >> On 4. Mar 2018, at 20:30, Wayne Stambaugh  >> 
> >> >> wrote:
> >>
> >> Ughh!  I don't have a good answer for this one.  My best guess is
> >> to fix
> >> the wx macos code first and see what performance issues are left.  The
> >> problem with messing with any of this is that if you break
> >> something it
> >> will break all of the legacy canvas rendering not just the schematic
> >> editor.  I would move extremely carefully here.  I would prefer
> >> that we
> >> don't go too crazy this late in the v5 release cycle.  If the
> >> performance is truly not usable on macos, then we may have no choice.
> >>
> >> On 03/04/2018 02:07 PM, Jeff Young wrote:
> >>> It turns out the fonts aren’t really the problem.
> >>>
> >>> It starts with this gem in wxWidgets:
> >>>
> >>>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
> >>>
> >>>{
> >>>
> >>>#if1
> >>>
> >>>SetNeedsDisplay();
> >>>
> >>>#else
> >>>
> >>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
> >>>
> >>>if(GetNeedsDisplay())
> >>>
> >>>{
> >>>
> >>>SetNeedsDisplay() ;
> >>>
> >>>}
> >>>
> >>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
> >>>
> >>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
> >>>
> >>>[m_osxViewscrollRect:rby:offset];
> >>>
> >>>#endif
> >>>
> >>>}
> >>>
> >>>
> >>> SetNeedsDisplay() with no rectangle argument invalidates the
> >>> entire window.
> >>>
> >>> Even if you fix that (to scroll most of the window and only
> >>> invalidate
> >>> the newly-exposed parts), you run into this:
> >>>
> >>>
> >>> voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
> >>>
> >>>{
> >>>
> >>>//preparingtheupdateregion
> >>>
> >>>wxRegionupdateRgn;
> >>>
> >>>
> >>>
> >>> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
> >>>
> >>>#if0
> >>>
> >>>constNSRect*rects;
> >>>
> >>>NSIntegercount;
> >>>
> >>>[slfgetRectsBeingDrawn::];
> >>>
> >>>for(inti=0;i >>>
> >>>{
> >>>
> >>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
> >>>
> >>>}
> >>>
> >>>#else
> >>>
> >>>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
> >>>
> >>>#endif
> >>>
> >>>
> >>> …which will /also/ cause the whole window to be repainted if there’s
> >>> both an invalidated horizontal strip and a vertical one.
> >>>
> >>> And the latter turns out to be pretty much guaranteed by this
> >>> one, which
> >>> batches repaints:
> >>>
> >>>voidwxNonOwnedWindow::Update()
> >>>
> >>>{
> >>>
> >>>if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
> >>>
> >>>{
> >>>
> >>>s_lastFlush=clock();
> >>>
> >>>m_nowpeer->Update();
> >>>
> >>>}
> >>>
> >>>}
> >>>
> >>>
> >>> But even Kicad isn’t blameless.  Once you fix all those there’s
> >>> still no
> >>> checking in SCH_SCREEN::Draw() to see if 

Re: [Kicad-developers] [PATCH] macOS CFBundleName

[Bernhard Stegmaier]

I guess it just is like that because the Linux binaries are also written like 
that and it has always been like that… :)


Regards,
Bernhard

> On 4. Mar 2018, at 23:37, Michael Kavanagh  wrote:
> 
> The attached trivial patch fixes the app menubar items to match the
> window titles, as well as when you "Quicklook" an executable, in
> activity monitor and probably some other places as well.
> 
> As a side is there any reason why the bundle/symlink names aren't
> capitalised/contain underscores instead of spaces? See attached
> screenshot.
> 
> Regards,
> Michael
> <0001-macOS-standardise-CFBundleName-to-application-names.patch> 2018-03-04 at 17.39.07.png>___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Jeff Young]

There is actually code in there to make them always on, but there seems to be 
something defeating it.  I’ll poke around some more.

> On 4 Mar 2018, at 21:57, Jon Evans  wrote:
> 
> Ah yes, I can reproduce that on Windows too.  I guess I didn't notice before 
> because generally the scrollbars are visible (I noticed that "zoom extents" 
> doesnt *always* result in the scrollbars being hidden, for whatever reason)
> Any reason why we hide the scrollbars?  Seems like it might be simpler to 
> just always show them...
> -Jon
> 
> On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier  > wrote:
> Do a “fit to window” and then pan left/right… I use the touchpad.
> After “fit to window” there is no scrollbar.
> When the scrollbar comes back due to panning, I see almost always a small 
> shift of the whole view down and then up again.
> Sometimes, but not always if you just pan left/right it will make this small 
> jump downwards every time you cross center, just as if it would “snap" to 
> middle position.
> 
> 
>> On 4. Mar 2018, at 21:25, Jon Evans > > wrote:
>> 
>> Maybe I don't really understand what you mean, but I can't see any jumpiness 
>> on Linux when panning around (with middle-mouse drag).
>> What do you mean by "it automatically fits to window, so there's not really 
>> any place to go"?  It does not do any kind of auto-fitting except for the 
>> zoom-extents on file load on Linux, and I don't have my Mac machine handy to 
>> compare.
>> 
>> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young > > wrote:
>> If I open an eeschema file on OSX and pan around (it automatically fits to 
>> window, so there’s not really any place to go), the screen jumps around a 
>> bit.  True also on other platforms, or Mac-specific?
>> 
>> Thanks,
>> Jeff.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Jon Evans]

Ah yes, I can reproduce that on Windows too.  I guess I didn't notice
before because generally the scrollbars are visible (I noticed that "zoom
extents" doesnt *always* result in the scrollbars being hidden, for
whatever reason)
Any reason why we hide the scrollbars?  Seems like it might be simpler to
just always show them...
-Jon

On Sun, Mar 4, 2018 at 4:52 PM, Bernhard Stegmaier 
wrote:

> Do a “fit to window” and then pan left/right… I use the touchpad.
> After “fit to window” there is no scrollbar.
> When the scrollbar comes back due to panning, I see almost always a small
> shift of the whole view down and then up again.
> Sometimes, but not always if you just pan left/right it will make this
> small jump downwards every time you cross center, just as if it would
> “snap" to middle position.
>
>
> On 4. Mar 2018, at 21:25, Jon Evans  wrote:
>
> Maybe I don't really understand what you mean, but I can't see any
> jumpiness on Linux when panning around (with middle-mouse drag).
> What do you mean by "it automatically fits to window, so there's not
> really any place to go"?  It does not do any kind of auto-fitting except
> for the zoom-extents on file load on Linux, and I don't have my Mac machine
> handy to compare.
>
> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  wrote:
>
>> If I open an eeschema file on OSX and pan around (it automatically fits
>> to window, so there’s not really any place to go), the screen jumps around
>> a bit.  True also on other platforms, or Mac-specific?
>>
>> Thanks,
>> Jeff.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Bernhard Stegmaier]

Do a “fit to window” and then pan left/right… I use the touchpad.
After “fit to window” there is no scrollbar.
When the scrollbar comes back due to panning, I see almost always a small shift 
of the whole view down and then up again.
Sometimes, but not always if you just pan left/right it will make this small 
jump downwards every time you cross center, just as if it would “snap" to 
middle position.

> On 4. Mar 2018, at 21:25, Jon Evans  wrote:
> 
> Maybe I don't really understand what you mean, but I can't see any jumpiness 
> on Linux when panning around (with middle-mouse drag).
> What do you mean by "it automatically fits to window, so there's not really 
> any place to go"?  It does not do any kind of auto-fitting except for the 
> zoom-extents on file load on Linux, and I don't have my Mac machine handy to 
> compare.
> 
> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  > wrote:
> If I open an eeschema file on OSX and pan around (it automatically fits to 
> window, so there’s not really any place to go), the screen jumps around a 
> bit.  True also on other platforms, or Mac-specific?
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Jeff Young]

Hi Jon,

Yes, I meant the zoom extents.

When you open the file it auto-zooms to fit.  Therefore you have no scrollbars. 
 But panning with the trackpad (or I imagine middle mouse button) causes it to 
show the scroll bar which “jumps” the schematic by the width and height of the 
scrollbars.  With the trackpad at least sometimes it jumps right back and the 
scroll bars go away again (but that might just be hysteresis in the trackpad 
motion detection).

Cheers,
Jeff.


> On 4 Mar 2018, at 20:25, Jon Evans  wrote:
> 
> Maybe I don't really understand what you mean, but I can't see any jumpiness 
> on Linux when panning around (with middle-mouse drag).
> What do you mean by "it automatically fits to window, so there's not really 
> any place to go"?  It does not do any kind of auto-fitting except for the 
> zoom-extents on file load on Linux, and I don't have my Mac machine handy to 
> compare.
> 
> On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  > wrote:
> If I open an eeschema file on OSX and pan around (it automatically fits to 
> window, so there’s not really any place to go), the screen jumps around a 
> bit.  True also on other platforms, or Mac-specific?
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MacOS Packaging Question

[Nick Østergaard]

Yes, it probably still uses the old libs. It is ready when it is ready or
someone else submits a patch.

2018-03-04 21:38 GMT+01:00 Andy Peters :

> The macOS nightlies still use “old” libraries. By that I mean, for
> example, Housings_SOIC instead of Packages_SOIC and the like.
>
> -a
>
> On Mar 3, 2018, at 7:53 PM, Nick Østergaard  wrote:
>
> This is the current scripts used for the current nightlies for macos
> https://github.com/wayneandlayne/KiCadMacOSPackaging.git
>
> 2018-03-04 <20%2018%2003%2004> 0:37 GMT+01:00 Rene Pöschl <
> poesc...@gmail.com>:
>
>> On 03/03/18 23:32, Seth Hillbrand wrote:
>>
>>> ​In the current nightly MacOS builds, we package the applications,
>>> symbols and 3d models but no footprints.
>>>
>>> Is this an oversight?
>>>
>>> -S​
>>>
>>>
>>>
>> This might be because in kicad 4 the footprints where downloaded on
>> demand via the github plugin.
>> With the new library setup (single repository for all footprints) this is
>> no longer possible.
>>
>> I assume some packages for other operating systems might have a similar
>> problem
>>
>> ___
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MacOS Packaging Question

[Andy Peters]

The macOS nightlies still use “old” libraries. By that I mean, for example, 
Housings_SOIC instead of Packages_SOIC and the like.

-a

> On Mar 3, 2018, at 7:53 PM, Nick Østergaard  wrote:
> 
> This is the current scripts used for the current nightlies for macos
> https://github.com/wayneandlayne/KiCadMacOSPackaging.git 
> 
> 
> 2018-03-04 0:37 GMT+01:00 Rene Pöschl  >:
> On 03/03/18 23:32, Seth Hillbrand wrote:
> ​In the current nightly MacOS builds, we package the applications, symbols 
> and 3d models but no footprints.
> 
> Is this an oversight?
> 
> -S​
> 
> 
> 
> This might be because in kicad 4 the footprints where downloaded on demand 
> via the github plugin.
> With the new library setup (single repository for all footprints) this is no 
> longer possible.
> 
> I assume some packages for other operating systems might have a similar 
> problem
> 
> ___
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Jumpy canvas on other platforms?

[Jon Evans]

Maybe I don't really understand what you mean, but I can't see any
jumpiness on Linux when panning around (with middle-mouse drag).
What do you mean by "it automatically fits to window, so there's not really
any place to go"?  It does not do any kind of auto-fitting except for the
zoom-extents on file load on Linux, and I don't have my Mac machine handy
to compare.

On Sun, Mar 4, 2018 at 3:11 PM, Jeff Young  wrote:

> If I open an eeschema file on OSX and pan around (it automatically fits to
> window, so there’s not really any place to go), the screen jumps around a
> bit.  True also on other platforms, or Mac-specific?
>
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Jumpy canvas on other platforms?

[Jeff Young]

If I open an eeschema file on OSX and pan around (it automatically fits to 
window, so there’s not really any place to go), the screen jumps around a bit.  
True also on other platforms, or Mac-specific?

Thanks,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Mac HighDPI performance

[Jon Evans]

We should probably make some kind of road map if it doesn't exist already,
concerning the path to GAL for eeschema and who will be doing what. For
example, it might make sense to do the SCHEMATIC class refactoring you were
talking about before or in parallel with parts of the porting effort.

I'm up for working on this too, as soon as my connectivity / bus stuff has
landed.

-Jon

On Sun, Mar 4, 2018, 14:46 Wayne Stambaugh  wrote:

> I agree.  If it's not an easy straight forward fix, I would prefer to
> spend our precious manpower resources on the GAL port as well.  I don't
> know when in the v6 cycle any of this will happen but I'm guessing it
> will happen fairly early.  Tom or Orson, do either of you have any idea
> when this will happen?
>
> Wayne
>
> On 03/04/2018 02:40 PM, Jon Evans wrote:
> > FWIW, I don't find the existing performance to be unusable, it's just
> > not up to the standards of PcbNew/GAL.  I don't think it's worth any
> > effort beyond easy fixes, we should put that energy into the GAL port.
> >
> > -Jon
> >
> > On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier  > > wrote:
> >
> > I would judge it wrt eeschema GAL conversion.
> > If that starts with v6, I don’t know if it is worth the effort.
> > If it is unsure when this will happen, it might be worth it.
> >
> >
> >> On 4. Mar 2018, at 20:30, Wayne Stambaugh  >> > wrote:
> >>
> >> Ughh!  I don't have a good answer for this one.  My best guess is
> >> to fix
> >> the wx macos code first and see what performance issues are left.
> The
> >> problem with messing with any of this is that if you break
> >> something it
> >> will break all of the legacy canvas rendering not just the schematic
> >> editor.  I would move extremely carefully here.  I would prefer
> >> that we
> >> don't go too crazy this late in the v5 release cycle.  If the
> >> performance is truly not usable on macos, then we may have no
> choice.
> >>
> >> On 03/04/2018 02:07 PM, Jeff Young wrote:
> >>> It turns out the fonts aren’t really the problem.
> >>>
> >>> It starts with this gem in wxWidgets:
> >>>
> >>>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
> >>>
> >>>{
> >>>
> >>>#if1
> >>>
> >>>SetNeedsDisplay();
> >>>
> >>>#else
> >>>
> >>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
> >>>
> >>>if(GetNeedsDisplay())
> >>>
> >>>{
> >>>
> >>>SetNeedsDisplay() ;
> >>>
> >>>}
> >>>
> >>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
> >>>
> >>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
> >>>
> >>>[m_osxViewscrollRect:rby:offset];
> >>>
> >>>#endif
> >>>
> >>>}
> >>>
> >>>
> >>> SetNeedsDisplay() with no rectangle argument invalidates the
> >>> entire window.
> >>>
> >>> Even if you fix that (to scroll most of the window and only
> >>> invalidate
> >>> the newly-exposed parts), you run into this:
> >>>
> >>>
> voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
> >>>
> >>>{
> >>>
> >>>//preparingtheupdateregion
> >>>
> >>>wxRegionupdateRgn;
> >>>
> >>>
> >>>
> 
> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
> >>>
> >>>#if0
> >>>
> >>>constNSRect*rects;
> >>>
> >>>NSIntegercount;
> >>>
> >>>[slfgetRectsBeingDrawn::];
> >>>
> >>>for(inti=0;i >>>
> >>>{
> >>>
> >>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
> >>>
> >>>}
> >>>
> >>>#else
> >>>
> >>>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
> >>>
> >>>#endif
> >>>
> >>>
> >>> …which will /also/ cause the whole window to be repainted if
> there’s
> >>> both an invalidated horizontal strip and a vertical one.
> >>>
> >>> And the latter turns out to be pretty much guaranteed by this
> >>> one, which
> >>> batches repaints:
> >>>
> >>>voidwxNonOwnedWindow::Update()
> >>>
> >>>{
> >>>
> >>>if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
> >>>
> >>>{
> >>>
> >>>s_lastFlush=clock();
> >>>
> >>>m_nowpeer->Update();
> >>>
> >>>}
> >>>
> >>>}
> >>>
> >>>
> >>> But even Kicad isn’t blameless.  Once you fix all those there’s
> >>> still no
> >>> checking in SCH_SCREEN::Draw() to see if the individual draw items
> >>> intersect the update region.  (Sure, the actually drawing is
> >>> clipped in
> >>> the end, but you still go through a /lot/ of code to get there.)
> >>>
> >>> All of these are fixable, and we’ve already crossed the Rubicon of
> >>> having our own OSX wxWidgets branch.
> >>>
> >>> But it’s still a reasonable amount of work, with a non-trivial risk
> >>>  

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Wayne Stambaugh]

Bernhard,

I merged your patch.  Thanks.

Wayne

On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> Attached patch fixes building on macOS with non-Xcode clang:
> * To avoid problems make documentation suggest that 
> cmake_minimum_required(...) has to be the very first statement directly 
> followed by project(...)
> * Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake 
> will ignore CMAKE_CXX_STANDARD with non-Xcode clang
> 
> Tested on macOS with native and non-Xcode clang.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

I agree.  If it's not an easy straight forward fix, I would prefer to
spend our precious manpower resources on the GAL port as well.  I don't
know when in the v6 cycle any of this will happen but I'm guessing it
will happen fairly early.  Tom or Orson, do either of you have any idea
when this will happen?

Wayne

On 03/04/2018 02:40 PM, Jon Evans wrote:
> FWIW, I don't find the existing performance to be unusable, it's just
> not up to the standards of PcbNew/GAL.  I don't think it's worth any
> effort beyond easy fixes, we should put that energy into the GAL port. 
> 
> -Jon
> 
> On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier  > wrote:
> 
> I would judge it wrt eeschema GAL conversion.
> If that starts with v6, I don’t know if it is worth the effort.
> If it is unsure when this will happen, it might be worth it.
> 
> 
>> On 4. Mar 2018, at 20:30, Wayne Stambaugh > > wrote:
>>
>> Ughh!  I don't have a good answer for this one.  My best guess is
>> to fix
>> the wx macos code first and see what performance issues are left.  The
>> problem with messing with any of this is that if you break
>> something it
>> will break all of the legacy canvas rendering not just the schematic
>> editor.  I would move extremely carefully here.  I would prefer
>> that we
>> don't go too crazy this late in the v5 release cycle.  If the
>> performance is truly not usable on macos, then we may have no choice.
>>
>> On 03/04/2018 02:07 PM, Jeff Young wrote:
>>> It turns out the fonts aren’t really the problem.
>>>
>>> It starts with this gem in wxWidgets:
>>>
>>>    voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
>>>
>>>    {
>>>
>>>    #if1
>>>
>>>    SetNeedsDisplay();
>>>
>>>    #else
>>>
>>>    //Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
>>>
>>>    if(GetNeedsDisplay())
>>>
>>>    {
>>>
>>>    SetNeedsDisplay() ;
>>>
>>>    }
>>>
>>>    NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
>>>
>>>    NSSizeoffset=NSMakeSize((float)dx,(float)dy);
>>>
>>>    [m_osxViewscrollRect:rby:offset];
>>>
>>>    #endif
>>>
>>>    }
>>>
>>>
>>> SetNeedsDisplay() with no rectangle argument invalidates the
>>> entire window.
>>>
>>> Even if you fix that (to scroll most of the window and only
>>> invalidate
>>> the newly-exposed parts), you run into this:
>>>
>>>    
>>> voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
>>>
>>>    {
>>>
>>>    //preparingtheupdateregion
>>>
>>>    wxRegionupdateRgn;
>>>
>>>
>>>    
>>> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
>>>
>>>    #if0
>>>
>>>    constNSRect*rects;
>>>
>>>    NSIntegercount;
>>>
>>>    [slfgetRectsBeingDrawn::];
>>>
>>>    for(inti=0;i>>
>>>    {
>>>
>>>    updateRgn.Union(wxFromNSRect(slf,rects[i]));
>>>
>>>    }
>>>
>>>    #else
>>>
>>>    updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>>>
>>>    #endif
>>>
>>>
>>> …which will /also/ cause the whole window to be repainted if there’s
>>> both an invalidated horizontal strip and a vertical one.
>>>
>>> And the latter turns out to be pretty much guaranteed by this
>>> one, which
>>> batches repaints:
>>>
>>>    voidwxNonOwnedWindow::Update()
>>>
>>>    {
>>>
>>>    if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
>>>
>>>    {
>>>
>>>    s_lastFlush=clock();
>>>
>>>    m_nowpeer->Update();
>>>
>>>    }
>>>
>>>    }
>>>
>>>
>>> But even Kicad isn’t blameless.  Once you fix all those there’s
>>> still no
>>> checking in SCH_SCREEN::Draw() to see if the individual draw items
>>> intersect the update region.  (Sure, the actually drawing is
>>> clipped in
>>> the end, but you still go through a /lot/ of code to get there.)
>>>
>>> All of these are fixable, and we’ve already crossed the Rubicon of
>>> having our own OSX wxWidgets branch.  
>>>
>>> But it’s still a reasonable amount of work, with a non-trivial risk
>>> profile.  Should I continue?
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>>
 On 4 Mar 2018, at 01:30, Bernhard Stegmaier
 
 > wrote:

 No.

> On 4. Mar 2018, at 01:51, Andrey Kuznetsov  
> > wrote:
>
> Would it be an easy fix to change the text/font such that it
> does not
> affect performance so significantly on MacOS?
>
> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh
> 
> 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Bernhard,

On 03/04/2018 02:32 PM, Bernhard Stegmaier wrote:
> Wayne, I am seeing the same funny stuff on my old Debian box.
> I didn’t follow up, because I thought it might have to do something with my 
> OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not 
> that good maintained.

My system is a core i7 with an nvidia graphics card using the
proprietary nvidia drivers.  I rarely have any rendering issue with the
nvidia drivers.  I have far less luck with the open source nvidia drivers.

> 
> But, the first picture is the OpenGL renderer, so this one is OK?

Yes, the OpenGL rendering is fine.

> 
> 
> Bernhard
> 
>> On 4. Mar 2018, at 20:20, Wayne Stambaugh  wrote:
>>
>> I'm not seeing any crash on Debian testing but there is some rather
>> amusing artifacts on the rendering.  It looks like all of my 3D models
>> have been deconstructed to tiny bits all over the model space.  Last
>> time I checked it was fine on windows.
>>
>> On 03/04/2018 02:06 PM, Maciej Suminski wrote:
>>> Bernhard,
>>>
>>> I suppose this is about raytrace rendering? Anyway, I see it crashing
>>> even without any design loaded. 3D viewer passes the first phase so I
>>> see the design rendered, but during 'Post processing shader' stage it
>>> crashes.
>>>
>>> Cheers,
>>> Orson
>>>
>>> On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote:
 Hi all,

 could please anybody test the following on a Windows/Linux OpenMP version?

 I have a PCB with only components placed (via “Update from Schematic”), no 
 routing done yet.
 Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
 Now, edit a footprint (“e”) and do a “Update Footprint from Library” for 
 only this footprint (no changes in footprint needed).
 Open 3d-viewer again.

 Or:
 Open PCB as above with only components and no routing yet.
 Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
 Delete some of the components and reimport them vie “Update PCB from 
 Schematic”.
 Open 3d-viewer again.

 In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang 
 (all cores at 100%, grey window, nothing happens) 3d-viewer .
 It doesn’t hang/crash in my non-OpenMP builds.

 If I save the PCB after the changes, close and reopen KiCad, then 
 3d-viewer of OpenMP build is also fine again.


 Regards,
 Bernhard

> On 3. Mar 2018, at 20:33, Bernhard Stegmaier  
> wrote:
>
> Hi all,
>
> So, I played around a bit to get OpenMP and GCD into something like a 
> “parallel_for” wrapper which either uses OpenMP or GCD.
> Unfortunately, OpenMP seems to require that the “for” statement directly 
> follows the “#pragma omg for …”.
> That currently killed all my attempts to define such a “parallel_for” (as 
> function, #define, ?) so that the code will stay the same for both.
> One option would be to pull the “#pragma omp for …” into the wrapper, but 
> I guess this is not really acceptable (since you can’t specify any 
> specific schedule parameters any longer).
>
> I will think about it some more just because of the challenge… but I am 
> not very optimistic at the moment to get something nice.
> If anyone else has a nice idea, I’d be very interested to learn freaky 
> new stuff… :)
>
> On the other side, I looked at using a non-Xcode OpenMP capable clang.
> The only caveat seems to be not to mix standard C++ libraries (in the 
> past libc++/libstdc++ haven’t been compatible in some aspects - didn’t 
> try to find out if that is resolved).
> Default on macOS now is libc++, but it seems that at least MacPorts 
> builds clang with libstdc++ per default (no idea why).
> The MacPorts build can easily be switched to libc++.
> That clang-mp builds KiCad without problems even if dependencies have 
> been built with Xcode clang.
> Everything seems to work as expected, multithreading is there where it 
> should be.
>
> So, for now it seems to be the most easy solution to switch to a suitable 
> non-Xcode clang for building packages - if we want to have OpenMP for 
> macOS.
>
> AFAIK our build machines use Homebrew.
> Seems as if Homebrew decides which standard library to use depending on 
> macOS version (https://docs.brew.sh/C++-Standard-Libraries 
> ).
> So, if everything is recent enough it might not be a problem at all… like 
> it obviously also has been for Seth below.
>
>
> Regards,
> Bernhard
>
>> On 1. Mar 2018, at 17:47, Seth Hillbrand > > wrote:
>>
>> Hi All-
>>
>> I was playing with this last night (don't normally compile on the mac) 
>> and found that using homebrew's llvm 

Re: [Kicad-developers] Mac HighDPI performance

[Jon Evans]

FWIW, I don't find the existing performance to be unusable, it's just not
up to the standards of PcbNew/GAL.  I don't think it's worth any effort
beyond easy fixes, we should put that energy into the GAL port.

-Jon

On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier 
wrote:

> I would judge it wrt eeschema GAL conversion.
> If that starts with v6, I don’t know if it is worth the effort.
> If it is unsure when this will happen, it might be worth it.
>
>
> On 4. Mar 2018, at 20:30, Wayne Stambaugh  wrote:
>
> Ughh!  I don't have a good answer for this one.  My best guess is to fix
> the wx macos code first and see what performance issues are left.  The
> problem with messing with any of this is that if you break something it
> will break all of the legacy canvas rendering not just the schematic
> editor.  I would move extremely carefully here.  I would prefer that we
> don't go too crazy this late in the v5 release cycle.  If the
> performance is truly not usable on macos, then we may have no choice.
>
> On 03/04/2018 02:07 PM, Jeff Young wrote:
>
> It turns out the fonts aren’t really the problem.
>
> It starts with this gem in wxWidgets:
>
>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
>
>{
>
>#if1
>
>SetNeedsDisplay();
>
>#else
>
>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
>
>if(GetNeedsDisplay())
>
>{
>
>SetNeedsDisplay() ;
>
>}
>
>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
>
>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
>
>[m_osxViewscrollRect:rby:offset];
>
>#endif
>
>}
>
>
> SetNeedsDisplay() with no rectangle argument invalidates the entire window.
>
> Even if you fix that (to scroll most of the window and only invalidate
> the newly-exposed parts), you run into this:
>
>
>voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
>
>{
>
>//preparingtheupdateregion
>
>wxRegionupdateRgn;
>
>
>
>//sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
>
>#if0
>
>constNSRect*rects;
>
>NSIntegercount;
>
>[slfgetRectsBeingDrawn::];
>
>for(inti=0;i
>{
>
>updateRgn.Union(wxFromNSRect(slf,rects[i]));
>
>}
>
>#else
>
>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>
>#endif
>
>
> …which will /also/ cause the whole window to be repainted if there’s
> both an invalidated horizontal strip and a vertical one.
>
> And the latter turns out to be pretty much guaranteed by this one, which
> batches repaints:
>
>voidwxNonOwnedWindow::Update()
>
>{
>
>if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
>
>{
>
>s_lastFlush=clock();
>
>m_nowpeer->Update();
>
>}
>
>}
>
>
> But even Kicad isn’t blameless.  Once you fix all those there’s still no
> checking in SCH_SCREEN::Draw() to see if the individual draw items
> intersect the update region.  (Sure, the actually drawing is clipped in
> the end, but you still go through a /lot/ of code to get there.)
>
> All of these are fixable, and we’ve already crossed the Rubicon of
> having our own OSX wxWidgets branch.
>
> But it’s still a reasonable amount of work, with a non-trivial risk
> profile.  Should I continue?
>
> Cheers,
> Jeff.
>
>
>
> On 4 Mar 2018, at 01:30, Bernhard Stegmaier  >> wrote:
>
> No.
>
> On 4. Mar 2018, at 01:51, Andrey Kuznetsov  >> wrote:
>
> Would it be an easy fix to change the text/font such that it does not
> affect performance so significantly on MacOS?
>
> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh  >> wrote:
>
>On 03/03/2018 07:33 AM, Jeff Young wrote:
>
>Hi Andrey,
>
>I did some profiling and I’d guess that the difference in
>eeschema and pcbnew-legacy performance is down to there being
>more text in the schema.  Since we use a stroke font, there’s
>a lot of stroke segments in each letter.
>
>@Devs,
>
>I understand why we use a stroke font on the PCB, but there’s
>not much reason in eeschema, is there?
>
>
>This is possibly one of the things that I plan on changing after
>the new schematic file format is written.  The new file format
>will support font definitions so replacing the stroke font in
>Eeschema should be doable. Whether or not I have time to make
>this change remains to be seen.
>
>Wayne
>
>
>Cheers,
>Jeff.
>
>
>On 3 Mar 2018, at 08:18, Andrey Kuznetsov
> >
>
>
>The motherboard project is not 

Re: [Kicad-developers] Mac HighDPI performance

[Bernhard Stegmaier]

I would judge it wrt eeschema GAL conversion.
If that starts with v6, I don’t know if it is worth the effort.
If it is unsure when this will happen, it might be worth it.


> On 4. Mar 2018, at 20:30, Wayne Stambaugh  wrote:
> 
> Ughh!  I don't have a good answer for this one.  My best guess is to fix
> the wx macos code first and see what performance issues are left.  The
> problem with messing with any of this is that if you break something it
> will break all of the legacy canvas rendering not just the schematic
> editor.  I would move extremely carefully here.  I would prefer that we
> don't go too crazy this late in the v5 release cycle.  If the
> performance is truly not usable on macos, then we may have no choice.
> 
> On 03/04/2018 02:07 PM, Jeff Young wrote:
>> It turns out the fonts aren’t really the problem.
>> 
>> It starts with this gem in wxWidgets:
>> 
>>voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
>> 
>>{
>> 
>>#if1
>> 
>>SetNeedsDisplay();
>> 
>>#else
>> 
>>//Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
>> 
>>if(GetNeedsDisplay())
>> 
>>{
>> 
>>SetNeedsDisplay() ;
>> 
>>}
>> 
>>NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
>> 
>>NSSizeoffset=NSMakeSize((float)dx,(float)dy);
>> 
>>[m_osxViewscrollRect:rby:offset];
>> 
>>#endif
>> 
>>}
>> 
>> 
>> SetNeedsDisplay() with no rectangle argument invalidates the entire window.
>> 
>> Even if you fix that (to scroll most of the window and only invalidate
>> the newly-exposed parts), you run into this:
>> 
>>voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
>> 
>>{
>> 
>>//preparingtheupdateregion
>> 
>>wxRegionupdateRgn;
>> 
>> 
>>
>> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
>> 
>>#if0
>> 
>>constNSRect*rects;
>> 
>>NSIntegercount;
>> 
>>[slfgetRectsBeingDrawn::];
>> 
>>for(inti=0;i> 
>>{
>> 
>>updateRgn.Union(wxFromNSRect(slf,rects[i]));
>> 
>>}
>> 
>>#else
>> 
>>updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
>> 
>>#endif
>> 
>> 
>> …which will /also/ cause the whole window to be repainted if there’s
>> both an invalidated horizontal strip and a vertical one.
>> 
>> And the latter turns out to be pretty much guaranteed by this one, which
>> batches repaints:
>> 
>>voidwxNonOwnedWindow::Update()
>> 
>>{
>> 
>>if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
>> 
>>{
>> 
>>s_lastFlush=clock();
>> 
>>m_nowpeer->Update();
>> 
>>}
>> 
>>}
>> 
>> 
>> But even Kicad isn’t blameless.  Once you fix all those there’s still no
>> checking in SCH_SCREEN::Draw() to see if the individual draw items
>> intersect the update region.  (Sure, the actually drawing is clipped in
>> the end, but you still go through a /lot/ of code to get there.)
>> 
>> All of these are fixable, and we’ve already crossed the Rubicon of
>> having our own OSX wxWidgets branch.  
>> 
>> But it’s still a reasonable amount of work, with a non-trivial risk
>> profile.  Should I continue?
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>> 
>>> On 4 Mar 2018, at 01:30, Bernhard Stegmaier >> >> wrote:
>>> 
>>> No.
>>> 
 On 4. Mar 2018, at 01:51, Andrey Kuznetsov 
 >> wrote:
 
 Would it be an easy fix to change the text/font such that it does not
 affect performance so significantly on MacOS?
 
 On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh 
 >> wrote:
 
On 03/03/2018 07:33 AM, Jeff Young wrote:
 
Hi Andrey,
 
I did some profiling and I’d guess that the difference in
eeschema and pcbnew-legacy performance is down to there being
more text in the schema.  Since we use a stroke font, there’s
a lot of stroke segments in each letter.
 
@Devs,
 
I understand why we use a stroke font on the PCB, but there’s
not much reason in eeschema, is there?
 
 
This is possibly one of the things that I plan on changing after
the new schematic file format is written.  The new file format
will support font definitions so replacing the stroke font in
Eeschema should be doable. Whether or not I have time to make
this change remains to be seen.
 
Wayne
 
 
Cheers,
Jeff.
 
 
On 3 Mar 2018, at 08:18, Andrey Kuznetsov
 
 >

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Wayne, I am seeing the same funny stuff on my old Debian box.
I didn’t follow up, because I thought it might have to do something with my 
OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not that 
good maintained.

But, the first picture is the OpenGL renderer, so this one is OK?


Bernhard

> On 4. Mar 2018, at 20:20, Wayne Stambaugh  wrote:
> 
> I'm not seeing any crash on Debian testing but there is some rather
> amusing artifacts on the rendering.  It looks like all of my 3D models
> have been deconstructed to tiny bits all over the model space.  Last
> time I checked it was fine on windows.
> 
> On 03/04/2018 02:06 PM, Maciej Suminski wrote:
>> Bernhard,
>> 
>> I suppose this is about raytrace rendering? Anyway, I see it crashing
>> even without any design loaded. 3D viewer passes the first phase so I
>> see the design rendered, but during 'Post processing shader' stage it
>> crashes.
>> 
>> Cheers,
>> Orson
>> 
>> On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote:
>>> Hi all,
>>> 
>>> could please anybody test the following on a Windows/Linux OpenMP version?
>>> 
>>> I have a PCB with only components placed (via “Update from Schematic”), no 
>>> routing done yet.
>>> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
>>> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for 
>>> only this footprint (no changes in footprint needed).
>>> Open 3d-viewer again.
>>> 
>>> Or:
>>> Open PCB as above with only components and no routing yet.
>>> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
>>> Delete some of the components and reimport them vie “Update PCB from 
>>> Schematic”.
>>> Open 3d-viewer again.
>>> 
>>> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang 
>>> (all cores at 100%, grey window, nothing happens) 3d-viewer .
>>> It doesn’t hang/crash in my non-OpenMP builds.
>>> 
>>> If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer 
>>> of OpenMP build is also fine again.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 3. Mar 2018, at 20:33, Bernhard Stegmaier  
 wrote:
 
 Hi all,
 
 So, I played around a bit to get OpenMP and GCD into something like a 
 “parallel_for” wrapper which either uses OpenMP or GCD.
 Unfortunately, OpenMP seems to require that the “for” statement directly 
 follows the “#pragma omg for …”.
 That currently killed all my attempts to define such a “parallel_for” (as 
 function, #define, ?) so that the code will stay the same for both.
 One option would be to pull the “#pragma omp for …” into the wrapper, but 
 I guess this is not really acceptable (since you can’t specify any 
 specific schedule parameters any longer).
 
 I will think about it some more just because of the challenge… but I am 
 not very optimistic at the moment to get something nice.
 If anyone else has a nice idea, I’d be very interested to learn freaky new 
 stuff… :)
 
 On the other side, I looked at using a non-Xcode OpenMP capable clang.
 The only caveat seems to be not to mix standard C++ libraries (in the past 
 libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to 
 find out if that is resolved).
 Default on macOS now is libc++, but it seems that at least MacPorts builds 
 clang with libstdc++ per default (no idea why).
 The MacPorts build can easily be switched to libc++.
 That clang-mp builds KiCad without problems even if dependencies have been 
 built with Xcode clang.
 Everything seems to work as expected, multithreading is there where it 
 should be.
 
 So, for now it seems to be the most easy solution to switch to a suitable 
 non-Xcode clang for building packages - if we want to have OpenMP for 
 macOS.
 
 AFAIK our build machines use Homebrew.
 Seems as if Homebrew decides which standard library to use depending on 
 macOS version (https://docs.brew.sh/C++-Standard-Libraries 
 ).
 So, if everything is recent enough it might not be a problem at all… like 
 it obviously also has been for Seth below.
 
 
 Regards,
 Bernhard
 
> On 1. Mar 2018, at 17:47, Seth Hillbrand  > wrote:
> 
> Hi All-
> 
> I was playing with this last night (don't normally compile on the mac) 
> and found that using homebrew's llvm 3.8.1 seems to compile fine with 
> -fopenmp.  Running some OMP test code from 
> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
>  
> shows expected result of 4 threads.  I didn't get OpenMP errors when 
> compiling KiCad although I didn't really notice a substantial difference 
> in 

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

Ughh!  I don't have a good answer for this one.  My best guess is to fix
the wx macos code first and see what performance issues are left.  The
problem with messing with any of this is that if you break something it
will break all of the legacy canvas rendering not just the schematic
editor.  I would move extremely carefully here.  I would prefer that we
don't go too crazy this late in the v5 release cycle.  If the
performance is truly not usable on macos, then we may have no choice.

On 03/04/2018 02:07 PM, Jeff Young wrote:
> It turns out the fonts aren’t really the problem.
> 
> It starts with this gem in wxWidgets:
> 
> voidwxWidgetCocoaImpl::ScrollRect(constwxRect*rect,intdx,intdy)
> 
> {
> 
> #if1
> 
> SetNeedsDisplay();
> 
> #else
> 
> //Weshoulddosomethinglikethis,butitwasn'tworkingin10.4.
> 
> if(GetNeedsDisplay())
> 
> {
> 
> SetNeedsDisplay() ;
> 
> }
> 
> NSRectr=wxToNSRect([m_osxViewsuperview],*rect);
> 
> NSSizeoffset=NSMakeSize((float)dx,(float)dy);
> 
> [m_osxViewscrollRect:rby:offset];
> 
> #endif
> 
> }
> 
> 
> SetNeedsDisplay() with no rectangle argument invalidates the entire window.
> 
> Even if you fix that (to scroll most of the window and only invalidate
> the newly-exposed parts), you run into this:
> 
> voidwxWidgetCocoaImpl::drawRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
> 
> {
> 
> //preparingtheupdateregion
> 
> wxRegionupdateRgn;
> 
> 
> 
> //sinceaddingmanyrectstoaregionisacostlyprocess,bydefaultusetheboundingrect
> 
> #if0
> 
> constNSRect*rects;
> 
> NSIntegercount;
> 
> [slfgetRectsBeingDrawn::];
> 
> for(inti=0;i 
> {
> 
> updateRgn.Union(wxFromNSRect(slf,rects[i]));
> 
> }
> 
> #else
> 
> updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
> 
> #endif
> 
> 
> …which will /also/ cause the whole window to be repainted if there’s
> both an invalidated horizontal strip and a vertical one.
> 
> And the latter turns out to be pretty much guaranteed by this one, which
> batches repaints:
> 
> voidwxNonOwnedWindow::Update()
> 
> {
> 
> if(clock()-s_lastFlush>CLOCKS_PER_SEC/30)
> 
> {
> 
> s_lastFlush=clock();
> 
> m_nowpeer->Update();
> 
> }
> 
> }
> 
> 
> But even Kicad isn’t blameless.  Once you fix all those there’s still no
> checking in SCH_SCREEN::Draw() to see if the individual draw items
> intersect the update region.  (Sure, the actually drawing is clipped in
> the end, but you still go through a /lot/ of code to get there.)
> 
> All of these are fixable, and we’ve already crossed the Rubicon of
> having our own OSX wxWidgets branch.  
> 
> But it’s still a reasonable amount of work, with a non-trivial risk
> profile.  Should I continue?
> 
> Cheers,
> Jeff.
> 
> 
> 
>> On 4 Mar 2018, at 01:30, Bernhard Stegmaier > > wrote:
>>
>> No.
>>
>>> On 4. Mar 2018, at 01:51, Andrey Kuznetsov >> > wrote:
>>>
>>> Would it be an easy fix to change the text/font such that it does not
>>> affect performance so significantly on MacOS?
>>>
>>> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh >> > wrote:
>>>
>>> On 03/03/2018 07:33 AM, Jeff Young wrote:
>>>
>>> Hi Andrey,
>>>
>>> I did some profiling and I’d guess that the difference in
>>> eeschema and pcbnew-legacy performance is down to there being
>>> more text in the schema.  Since we use a stroke font, there’s
>>> a lot of stroke segments in each letter.
>>>
>>> @Devs,
>>>
>>> I understand why we use a stroke font on the PCB, but there’s
>>> not much reason in eeschema, is there?
>>>
>>>
>>> This is possibly one of the things that I plan on changing after
>>> the new schematic file format is written.  The new file format
>>> will support font definitions so replacing the stroke font in
>>> Eeschema should be doable. Whether or not I have time to make
>>> this change remains to be seen.
>>>
>>> Wayne
>>>
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 3 Mar 2018, at 08:18, Andrey Kuznetsov
>>> 
>>> >> >> wrote:
>>>
>>> The motherboard project is not very complex, I would say
>>> that performance should be tolerable UP to that size
>>> complexity, if we set the bar any lower, usability will
>>> suffer and people won't like KiCad because it's sluggish
>>> and interface lag is the worst kind of lag.
>>> My project isn't finished and Chris' project is available
>>> now, is just the right complexity and has layout that can
>>> be used for testing as well as a 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Orson,

no, the raytracing renderer is completely fine in that use-cases.

It is only the OpenGL renderer.
I first noticed the hang when I switched back from Raytracing to OpenGL 
(obviously after I did one of the 2 use-cases).

If it crashes, I get a backtrace of the crashing thread as follows
<<<
Thread 3 Crashed:
0   libomp.dylib0x000109c728e2 
__kmp_release_queuing_lock + 165
1   _pcbnew.kiface  0x000111a1aaa3 
CLAYER_TRIANGLES::AddToMiddleContourns(std::__1::vector, std::__1::allocator > 
> const&, float, float, bool) + 1011
2   _pcbnew.kiface  0x000111a1ad52 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_LINE_CHAIN const&, float, float, 
double, bool) + 546
3   _pcbnew.kiface  0x000111a1b228 .omp_outlined. + 248
4   libomp.dylib0x000109c81b93 
__kmp_invoke_microtask + 147
5   libomp.dylib0x000109c587b7 
__kmp_invoke_task_func + 156
6   libomp.dylib0x000109c57e88 __kmp_launch_thread 
+ 267
7   libomp.dylib0x000109c79e6f 
__kmp_launch_worker(void*) + 588
8   libsystem_pthread.dylib 0x7fff6735b6c1 _pthread_body + 340
9   libsystem_pthread.dylib 0x7fff6735b56d _pthread_start + 377
10  libsystem_pthread.dylib 0x7fff6735ac5d thread_start + 13
>>>

The main thread looks similar.
<<<
Thread 0:: Dispatch queue: com.apple.main-thread
0   libomp.dylib0x000109c728e2 
__kmp_release_queuing_lock + 165
1   _pcbnew.kiface  0x000111a1aaa3 
CLAYER_TRIANGLES::AddToMiddleContourns(std::__1::vector, std::__1::allocator > 
> const&, float, float, bool) + 1011
2   _pcbnew.kiface  0x000111a1ad52 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_LINE_CHAIN const&, float, float, 
double, bool) + 546
3   _pcbnew.kiface  0x000111a1b228 .omp_outlined. + 248
4   libomp.dylib0x000109c81b93 
__kmp_invoke_microtask + 147
5   libomp.dylib0x000109c587b7 
__kmp_invoke_task_func + 156
6   libomp.dylib0x000109c557dc __kmp_fork_call + 
4682
7   libomp.dylib0x000109c4d1fb __kmpc_fork_call + 
183
8   _pcbnew.kiface  0x000111a1b114 
CLAYER_TRIANGLES::AddToMiddleContourns(SHAPE_POLY_SET const&, float, float, 
double, bool) + 628
9   _pcbnew.kiface  0x000111a126ae 
C3D_RENDER_OGL_LEGACY::generate_holes_display_list(std::__1::list > const&, SHAPE_POLY_SET const&, float, float, 
bool) + 462
10  _pcbnew.kiface  0x000111a12d39 
C3D_RENDER_OGL_LEGACY::reload(REPORTER*) + 1545
11  _pcbnew.kiface  0x000111a16e02 
C3D_RENDER_OGL_LEGACY::Redraw(bool, REPORTER*) + 306
12  _pcbnew.kiface  0x000111a09124 
EDA_3D_CANVAS::OnPaint(wxPaintEvent&) + 628
>>>

I am not really familiar with OpenMP, but the AddToMiddleContourns methods look 
good in terms of synchronization (well, at first glance).


Regards,
Bernhard

> On 4. Mar 2018, at 20:06, Maciej Suminski  wrote:
> 
> Bernhard,
> 
> I suppose this is about raytrace rendering? Anyway, I see it crashing
> even without any design loaded. 3D viewer passes the first phase so I
> see the design rendered, but during 'Post processing shader' stage it
> crashes.
> 
> Cheers,
> Orson
> 
> On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote:
>> Hi all,
>> 
>> could please anybody test the following on a Windows/Linux OpenMP version?
>> 
>> I have a PCB with only components placed (via “Update from Schematic”), no 
>> routing done yet.
>> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
>> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for 
>> only this footprint (no changes in footprint needed).
>> Open 3d-viewer again.
>> 
>> Or:
>> Open PCB as above with only components and no routing yet.
>> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
>> Delete some of the components and reimport them vie “Update PCB from 
>> Schematic”.
>> Open 3d-viewer again.
>> 
>> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang 
>> (all cores at 100%, grey window, nothing happens) 3d-viewer .
>> It doesn’t hang/crash in my non-OpenMP builds.
>> 
>> If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer 
>> of OpenMP build is also fine again.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 3. Mar 2018, at 20:33, Bernhard Stegmaier  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> So, I played around a bit to get OpenMP and GCD into something 

Re: [Kicad-developers] Mac HighDPI performance

[Jeff Young]

It turns out the fonts aren’t really the problem.

It starts with this gem in wxWidgets:

void wxWidgetCocoaImpl::ScrollRect( const wxRect *rect, int dx, int dy )
{
#if 1
SetNeedsDisplay() ;
#else
// We should do something like this, but it wasn't working in 10.4.
if (GetNeedsDisplay() )
{
SetNeedsDisplay() ;
}
NSRect r = wxToNSRect( [m_osxView superview], *rect );
NSSize offset = NSMakeSize((float)dx, (float)dy);
[m_osxView scrollRect:r by:offset];
#endif
}

SetNeedsDisplay() with no rectangle argument invalidates the entire window.

Even if you fix that (to scroll most of the window and only invalidate the 
newly-exposed parts), you run into this:

void wxWidgetCocoaImpl::drawRect(void* rect, WXWidget slf, void *WXUNUSED(_cmd))
{
// preparing the update region

wxRegion updateRgn;

// since adding many rects to a region is a costly process, by default use 
the bounding rect
#if 0
const NSRect *rects;
NSInteger count;
[slf getRectsBeingDrawn: count:];
for ( int i = 0 ; i < count ; ++i )
{
updateRgn.Union(wxFromNSRect(slf, rects[i]));
}
#else
updateRgn.Union(wxFromNSRect(slf,*(NSRect*)rect));
#endif

…which will also cause the whole window to be repainted if there’s both an 
invalidated horizontal strip and a vertical one.

And the latter turns out to be pretty much guaranteed by this one, which 
batches repaints:

void wxNonOwnedWindow::Update()
{
if ( clock() - s_lastFlush > CLOCKS_PER_SEC / 30 )
{
s_lastFlush = clock();
m_nowpeer->Update();
}
}

But even Kicad isn’t blameless.  Once you fix all those there’s still no 
checking in SCH_SCREEN::Draw() to see if the individual draw items intersect 
the update region.  (Sure, the actually drawing is clipped in the end, but you 
still go through a lot of code to get there.)

All of these are fixable, and we’ve already crossed the Rubicon of having our 
own OSX wxWidgets branch.  

But it’s still a reasonable amount of work, with a non-trivial risk profile.  
Should I continue?

Cheers,
Jeff.



> On 4 Mar 2018, at 01:30, Bernhard Stegmaier  wrote:
> 
> No.
> 
>> On 4. Mar 2018, at 01:51, Andrey Kuznetsov > > wrote:
>> 
>> Would it be an easy fix to change the text/font such that it does not affect 
>> performance so significantly on MacOS?
>> 
>> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh > > wrote:
>> On 03/03/2018 07:33 AM, Jeff Young wrote:
>> Hi Andrey,
>> 
>> I did some profiling and I’d guess that the difference in eeschema and 
>> pcbnew-legacy performance is down to there being more text in the schema.  
>> Since we use a stroke font, there’s a lot of stroke segments in each letter.
>> 
>> @Devs,
>> 
>> I understand why we use a stroke font on the PCB, but there’s not much 
>> reason in eeschema, is there?
>> 
>> This is possibly one of the things that I plan on changing after the new 
>> schematic file format is written.  The new file format will support font 
>> definitions so replacing the stroke font in Eeschema should be doable. 
>> Whether or not I have time to make this change remains to be seen.
>> 
>> Wayne
>> 
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>> On 3 Mar 2018, at 08:18, Andrey Kuznetsov >  > >> wrote:
>> 
>> The motherboard project is not very complex, I would say that performance 
>> should be tolerable UP to that size complexity, if we set the bar any lower, 
>> usability will suffer and people won't like KiCad because it's sluggish and 
>> interface lag is the worst kind of lag.
>> My project isn't finished and Chris' project is available now, is just the 
>> right complexity and has layout that can be used for testing as well as a 
>> schematic.
>> 
>> *LG 5K 27" display running 3200x1800 (the highest resolution without making 
>> text blurry, using this for work every day, so it's extravagant, it's 
>> practical)*
>> 
>> *Actions:* pan with middle mouse, zoom back and forth.
>> 
>> *eeschema:*
>> Low Res - at least 2 times slower than would be considered normal, I would 
>> have to guess ~400ms lag
>> Normal - 4-5x slower compared to low res mode ~1700ms lag
>> Even in low res mode, and removing 75% of the items from Chris' schematic, 
>> the lag is still ~200-300ms, that's just not right. Additionally, I filed 
>> https://bugs.launchpad.net/kicad/+bug/1753054 
>>  because the mouse zoom is 
>> screwed up in eeschema, coupled with the lag, it's unusable. Maybe the pan 
>> lag is related to the zoom, maybe there are multiple steps being rendered 
>> when it should just jump to where the mouse ended up at, I don't know.
>> 
>> *pcbnew - **Normal Resolution:*
>> Accelerated: No-AA, <50ms
>> Fallback: 500-1000ms for panning, 300-600ms for 

Re: [Kicad-developers] MacOS + OpenMP

[Maciej Suminski]

Bernhard,

I suppose this is about raytrace rendering? Anyway, I see it crashing
even without any design loaded. 3D viewer passes the first phase so I
see the design rendered, but during 'Post processing shader' stage it
crashes.

Cheers,
Orson

On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote:
> Hi all,
> 
> could please anybody test the following on a Windows/Linux OpenMP version?
> 
> I have a PCB with only components placed (via “Update from Schematic”), no 
> routing done yet.
> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for only 
> this footprint (no changes in footprint needed).
> Open 3d-viewer again.
> 
> Or:
> Open PCB as above with only components and no routing yet.
> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
> Delete some of the components and reimport them vie “Update PCB from 
> Schematic”.
> Open 3d-viewer again.
> 
> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang 
> (all cores at 100%, grey window, nothing happens) 3d-viewer .
> It doesn’t hang/crash in my non-OpenMP builds.
> 
> If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer 
> of OpenMP build is also fine again.
> 
> 
> Regards,
> Bernhard
> 
>> On 3. Mar 2018, at 20:33, Bernhard Stegmaier  wrote:
>>
>> Hi all,
>>
>> So, I played around a bit to get OpenMP and GCD into something like a 
>> “parallel_for” wrapper which either uses OpenMP or GCD.
>> Unfortunately, OpenMP seems to require that the “for” statement directly 
>> follows the “#pragma omg for …”.
>> That currently killed all my attempts to define such a “parallel_for” (as 
>> function, #define, ?) so that the code will stay the same for both.
>> One option would be to pull the “#pragma omp for …” into the wrapper, but I 
>> guess this is not really acceptable (since you can’t specify any specific 
>> schedule parameters any longer).
>>
>> I will think about it some more just because of the challenge… but I am not 
>> very optimistic at the moment to get something nice.
>> If anyone else has a nice idea, I’d be very interested to learn freaky new 
>> stuff… :)
>>
>> On the other side, I looked at using a non-Xcode OpenMP capable clang.
>> The only caveat seems to be not to mix standard C++ libraries (in the past 
>> libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to 
>> find out if that is resolved).
>> Default on macOS now is libc++, but it seems that at least MacPorts builds 
>> clang with libstdc++ per default (no idea why).
>> The MacPorts build can easily be switched to libc++.
>> That clang-mp builds KiCad without problems even if dependencies have been 
>> built with Xcode clang.
>> Everything seems to work as expected, multithreading is there where it 
>> should be.
>>
>> So, for now it seems to be the most easy solution to switch to a suitable 
>> non-Xcode clang for building packages - if we want to have OpenMP for macOS.
>>
>> AFAIK our build machines use Homebrew.
>> Seems as if Homebrew decides which standard library to use depending on 
>> macOS version (https://docs.brew.sh/C++-Standard-Libraries 
>> ).
>> So, if everything is recent enough it might not be a problem at all… like it 
>> obviously also has been for Seth below.
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 1. Mar 2018, at 17:47, Seth Hillbrand >> > wrote:
>>>
>>> Hi All-
>>>
>>> I was playing with this last night (don't normally compile on the mac) and 
>>> found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp. 
>>>  Running some OMP test code from 
>>> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
>>>  
>>> shows expected result of 4 threads.  I didn't get OpenMP errors when 
>>> compiling KiCad although I didn't really notice a substantial difference in 
>>> speed for the quick tests I was running.  Maybe with more involved 
>>> operations.
>>>
>>> I'm not sure if this will require us to distribute a different libstdc++ 
>>> with KiCad.  Probably.  Does that seem feasible to the packing team?
>>>
>>> -S
>>>
>>> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier >> >:
>>> Hmm?
>>> You keep everything as is (especially creating threads), but just put the 
>>> “#pragma …” before the for-loop.
>>> So, there is one thread for the progress and one for the workers.
>>> In the workers thread OpenMP (if there) takes care of adding additional 
>>> threads for parallelising the loop?
>>>
>>> Or, am I wrong with that?
>>>
 On 1. Mar 2018, at 16:11, Jeff Young > wrote:

 But then the progress reporter won’t work (and you’ve got no way to 
 cancel).

 Non-pooling 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Debian testing package reports libgomp1 version 8-20180218-1 and CMake
finds it as version 4.5.  I'm not sure why the disconnect.  I'm using
gcc 7.3.0.  I'll check windows when I get a chance.


On 03/04/2018 01:36 PM, Bernhard Stegmaier wrote:
> Hi all,
> 
> could please anybody test the following on a Windows/Linux OpenMP version?
> 
> I have a PCB with only components placed (via “Update from Schematic”),
> no routing done yet.
> Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
> Now, edit a footprint (“e”) and do a “Update Footprint from Library” for
> only this footprint (no changes in footprint needed).
> Open 3d-viewer again.
> 
> Or:
> Open PCB as above with only components and no routing yet.
> Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
> Delete some of the components and reimport them vie “Update PCB from
> Schematic”.
> Open 3d-viewer again.
> 
> In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or
> hang (all cores at 100%, grey window, nothing happens) 3d-viewer .
> It doesn’t hang/crash in my non-OpenMP builds.
> 
> If I save the PCB after the changes, close and reopen KiCad, then
> 3d-viewer of OpenMP build is also fine again.
> 
> 
> Regards,
> Bernhard
> 
>> On 3. Mar 2018, at 20:33, Bernhard Stegmaier > > wrote:
>>
>> Hi all,
>>
>> So, I played around a bit to get OpenMP and GCD into something like a
>> “parallel_for” wrapper which either uses OpenMP or GCD.
>> Unfortunately, OpenMP seems to require that the “for” statement
>> directly follows the “#pragma omg for …”.
>> That currently killed all my attempts to define such a “parallel_for”
>> (as function, #define, ?) so that the code will stay the same for both.
>> One option would be to pull the “#pragma omp for …” into the wrapper,
>> but I guess this is not really acceptable (since you can’t specify any
>> specific schedule parameters any longer).
>>
>> I will think about it some more just because of the challenge… but I
>> am not very optimistic at the moment to get something nice.
>> If anyone else has a nice idea, I’d be very interested to learn freaky
>> new stuff… :)
>>
>> On the other side, I looked at using a non-Xcode OpenMP capable clang.
>> The only caveat seems to be not to mix standard C++ libraries (in the
>> past libc++/libstdc++ haven’t been compatible in some aspects - didn’t
>> try to find out if that is resolved).
>> Default on macOS now is libc++, but it seems that at least MacPorts
>> builds clang with libstdc++ per default (no idea why).
>> The MacPorts build can easily be switched to libc++.
>> That clang-mp builds KiCad without problems even if dependencies have
>> been built with Xcode clang.
>> Everything seems to work as expected, multithreading is there where it
>> should be.
>>
>> So, for now it seems to be the most easy solution to switch to a
>> suitable non-Xcode clang for building packages - if we want to have
>> OpenMP for macOS.
>>
>> AFAIK our build machines use Homebrew.
>> Seems as if Homebrew decides which standard library to use depending
>> on macOS version (https://docs.brew.sh/C++-Standard-Libraries).
>> So, if everything is recent enough it might not be a problem at all…
>> like it obviously also has been for Seth below.
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 1. Mar 2018, at 17:47, Seth Hillbrand >> > wrote:
>>>
>>> Hi All-
>>>
>>> I was playing with this last night (don't normally compile on the
>>> mac) and found that using homebrew's llvm 3.8.1 seems to compile fine
>>> with -fopenmp.  Running some OMP test code
>>> from https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5
>>> shows expected result of 4 threads.  I didn't get OpenMP errors when
>>> compiling KiCad although I didn't really notice a substantial
>>> difference in speed for the quick tests I was running.  Maybe with
>>> more involved operations.
>>>
>>> I'm not sure if this will require us to distribute a different
>>> libstdc++ with KiCad.  Probably.  Does that seem feasible to the
>>> packing team?
>>>
>>> -S
>>>
>>> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier >> >:
>>>
>>> Hmm?
>>> You keep everything as is (especially creating threads), but just
>>> put the “#pragma …” before the for-loop.
>>> So, there is one thread for the progress and one for the workers.
>>> In the workers thread OpenMP (if there) takes care of adding
>>> additional threads for parallelising the loop?
>>>
>>> Or, am I wrong with that?
>>>
>>> > On 1. Mar 2018, at 16:11, Jeff Young >> > wrote:
>>> >
>>> > But then the progress reporter won’t work (and you’ve got no
>>> way to cancel).
>>> >
>>> > Non-pooling parallel threads are sufficient for zone filling,
>>> aren’t they?
>>> >
>>> >
>>> >> On 1 

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Bernhard Stegmaier]

Please note that the fix is only needed with a non-Xcode clang.
My cmake is 3.10.x, I had the problem both with clang-5.0.1 and clang-6.0 from 
MacPorts.
clang-6.0 only did work because it defaults to C++-14.

Xcode clang is fine without the change.


Bernhard

> On 4. Mar 2018, at 19:15, Seth Hillbrand  wrote:
> 
> I see no issues on Mac OS.
> 
> -S
> 
> 
> 
> On Mar 4, 2018 10:00 AM, "Wayne Stambaugh"  > wrote:
> I didn't notice any issues on linux builds.  Has anyone else confirmed
> this doesn't break anything on macos builds?
> 
> On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote:
> > Hi,
> >
> > Attached patch fixes building on macOS with non-Xcode clang:
> > * To avoid problems make documentation suggest that 
> > cmake_minimum_required(...) has to be the very first statement directly 
> > followed by project(...)
> > * Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake 
> > will ignore CMAKE_CXX_STANDARD with non-Xcode clang
> >
> > Tested on macOS with native and non-Xcode clang.
> >
> >
> > Regards,
> > Bernhard
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > 
> > Post to : kicad-developers@lists.launchpad.net 
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > 
> > More help   : https://help.launchpad.net/ListHelp 
> > 
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

Hi all,

could please anybody test the following on a Windows/Linux OpenMP version?

I have a PCB with only components placed (via “Update from Schematic”), no 
routing done yet.
Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer.
Now, edit a footprint (“e”) and do a “Update Footprint from Library” for only 
this footprint (no changes in footprint needed).
Open 3d-viewer again.

Or:
Open PCB as above with only components and no routing yet.
Make sure that 3d-viewer in OpenGL mode is fine, close 3d-viewer.
Delete some of the components and reimport them vie “Update PCB from Schematic”.
Open 3d-viewer again.

In both cases my OpenMP builds (clang-5.0.1 with libomp-3.1) crash or hang (all 
cores at 100%, grey window, nothing happens) 3d-viewer .
It doesn’t hang/crash in my non-OpenMP builds.

If I save the PCB after the changes, close and reopen KiCad, then 3d-viewer of 
OpenMP build is also fine again.


Regards,
Bernhard

> On 3. Mar 2018, at 20:33, Bernhard Stegmaier  wrote:
> 
> Hi all,
> 
> So, I played around a bit to get OpenMP and GCD into something like a 
> “parallel_for” wrapper which either uses OpenMP or GCD.
> Unfortunately, OpenMP seems to require that the “for” statement directly 
> follows the “#pragma omg for …”.
> That currently killed all my attempts to define such a “parallel_for” (as 
> function, #define, ?) so that the code will stay the same for both.
> One option would be to pull the “#pragma omp for …” into the wrapper, but I 
> guess this is not really acceptable (since you can’t specify any specific 
> schedule parameters any longer).
> 
> I will think about it some more just because of the challenge… but I am not 
> very optimistic at the moment to get something nice.
> If anyone else has a nice idea, I’d be very interested to learn freaky new 
> stuff… :)
> 
> On the other side, I looked at using a non-Xcode OpenMP capable clang.
> The only caveat seems to be not to mix standard C++ libraries (in the past 
> libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find 
> out if that is resolved).
> Default on macOS now is libc++, but it seems that at least MacPorts builds 
> clang with libstdc++ per default (no idea why).
> The MacPorts build can easily be switched to libc++.
> That clang-mp builds KiCad without problems even if dependencies have been 
> built with Xcode clang.
> Everything seems to work as expected, multithreading is there where it should 
> be.
> 
> So, for now it seems to be the most easy solution to switch to a suitable 
> non-Xcode clang for building packages - if we want to have OpenMP for macOS.
> 
> AFAIK our build machines use Homebrew.
> Seems as if Homebrew decides which standard library to use depending on macOS 
> version (https://docs.brew.sh/C++-Standard-Libraries 
> ).
> So, if everything is recent enough it might not be a problem at all… like it 
> obviously also has been for Seth below.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 17:47, Seth Hillbrand > > wrote:
>> 
>> Hi All-
>> 
>> I was playing with this last night (don't normally compile on the mac) and 
>> found that using homebrew's llvm 3.8.1 seems to compile fine with -fopenmp.  
>> Running some OMP test code from 
>> https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5 
>>  
>> shows expected result of 4 threads.  I didn't get OpenMP errors when 
>> compiling KiCad although I didn't really notice a substantial difference in 
>> speed for the quick tests I was running.  Maybe with more involved 
>> operations.
>> 
>> I'm not sure if this will require us to distribute a different libstdc++ 
>> with KiCad.  Probably.  Does that seem feasible to the packing team?
>> 
>> -S
>> 
>> 2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier > >:
>> Hmm?
>> You keep everything as is (especially creating threads), but just put the 
>> “#pragma …” before the for-loop.
>> So, there is one thread for the progress and one for the workers.
>> In the workers thread OpenMP (if there) takes care of adding additional 
>> threads for parallelising the loop?
>> 
>> Or, am I wrong with that?
>> 
>> > On 1. Mar 2018, at 16:11, Jeff Young > > > wrote:
>> >
>> > But then the progress reporter won’t work (and you’ve got no way to 
>> > cancel).
>> >
>> > Non-pooling parallel threads are sufficient for zone filling, aren’t they?
>> >
>> >
>> >> On 1 Mar 2018, at 15:00, Bernhard Stegmaier > >> > wrote:
>> >>
>> >> For now it would probably be fine to just restore the pragma for the for 
>> >> loop optimisation.
>> >> Mac users are used to work single-threaded, all others would get back 
>> >> multithreading here.
>> >>

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Seth Hillbrand]

I see no issues on Mac OS.

-S



On Mar 4, 2018 10:00 AM, "Wayne Stambaugh"  wrote:

> I didn't notice any issues on linux builds.  Has anyone else confirmed
> this doesn't break anything on macos builds?
>
> On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote:
> > Hi,
> >
> > Attached patch fixes building on macOS with non-Xcode clang:
> > * To avoid problems make documentation suggest that
> cmake_minimum_required(...) has to be the very first statement directly
> followed by project(...)
> > * Policy CMP0025 must be set with min version <3.1 to NEW otherwise
> cmake will ignore CMAKE_CXX_STANDARD with non-Xcode clang
> >
> > Tested on macOS with native and non-Xcode clang.
> >
> >
> > Regards,
> > Bernhard
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Jeff Young]

I works for me (although I’m using more-or-less the same dev env as Bernhard so 
it’s not much of a second datapoint).

Cheers,
Jeff.


> On 4 Mar 2018, at 18:00, Wayne Stambaugh  wrote:
> 
> I didn't notice any issues on linux builds.  Has anyone else confirmed
> this doesn't break anything on macos builds?
> 
> On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> Attached patch fixes building on macOS with non-Xcode clang:
>> * To avoid problems make documentation suggest that 
>> cmake_minimum_required(...) has to be the very first statement directly 
>> followed by project(...)
>> * Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake 
>> will ignore CMAKE_CXX_STANDARD with non-Xcode clang
>> 
>> Tested on macOS with native and non-Xcode clang.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Improving Eagle Import netlist matching

[Maciej Suminski]

I have just merged the patches.

On 02/28/2018 12:38 PM, Russell Oliver wrote:
> Hi Orson,
> 
> All I can say is thanks for taking the time to polish this further.
> 
> Just went through the matching code and am now kicking myself that i didn't
> think of that approach before.

No worries, it was not my first idea either.

Regards,
Orson

> Good pick up on the missing junctions.
> 
> Kind Regards
> Russell
> 
> 
> On 28 Feb 2018 22:14, "Maciej Sumiński"  wrote:
> 
>> I think I have finally reached the point where I am completely satisfied
>> with the Eagle import results. I do not see any changes when invoking
>> 'Update PCB from schematics'. No connectivity issues observed and pretty
>> local net labels are used whenever possible.
>>
>> Thank you Russell, your patch to use local net labels where applicable
>> works fine - I have no idea what went wrong on my side previously. Your
>> net remapping algorithm for zones also helped, but I had to change it a
>> bit.
>>
>> There are some more patches [1], as I have discovered a few other issues
>> that needed fixing:
>>
>> - Changed the zone/track/via net remapping algorithm to handle unnamed
>> nets. The new algorithm maps net names to pads before and after netlist
>> updates. Then it is easy to compare the maps and apply the same net name
>> changes to tracks and zones.
>>
>> - Added junction dots when necessary. It turns out if a pin is placed
>> perpendicular to a wire, then eeschema does not recognize it as
>> connected whereas Eagle does. Normally one gets a junction dot in such
>> places when a component is placed manually, so it is done for imported
>> schematics as well.
>>
>> - Adjusted footprint LIB_IDs in imported schematics and board files to
>> point to the imported Eagle library.
>>
>> I will leave the branch for testing for a few days to see if there are
>> any problems reported. I am going to merge the branch during the weekend.
>>
>> Cheers,
>> Orson
>>
>> 1.
>> https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+
>> ref/eagle_import_fixes
>>
>> On 02/26/2018 12:10 PM, Russell Oliver wrote:
>>> Awesome,
>>>
>>> I'm excited to finally see v5 come to pass. I think we should nickname
>> the
>>> release, Godot, since we have all be waiting for it for so long.
>>>
>>> Russ
>>>
>>> On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński >>
>>> wrote:
>>>
 Hi Russell,

 I plan to merge your changes, I have almost finished the refactor to use
 KiWay mail. I will test the patches a bit and given no extra issues
 appear, I will push them to the master branch.

 Regards,
 Orson

 On 02/25/2018 10:30 PM, Russell Oliver wrote:
> Just wondering what approach we are going to use for v5? Global labels
>> or
> my latest matching algorithm?
>
> Kind Regards
> Russell
>
>
>
> On 25 Feb 2018 08:43, "Russell Oliver"  wrote:
>
>> Hi Orson,
>>
>> I looked at the Kicad project from the and I don't see any global
 labels,
>> just local labels. The PCB will still have the global nets though,
>> since
>> they are created during import of the eagle pcb file.
>> Just to be clear my patches are intended to only generate global
>> labels
>> when necessary, which should only occur when there are multiple sheets
 in
>> the original Eagle schematic.
>>
>> Russell
>>
>>
>>
>> On Tue, Feb 20, 2018 at 9:55 AM Maciej Suminski <
 maciej.sumin...@cern.ch>
>> wrote:
>>
>>> Hi Russell,
>>>
>>> On 02/19/2018 08:25 PM, Russell Oliver wrote:
 Hi Orson,

 I wasn't sure about using the KiMail, since I didn't know how
 immediate
 those calls are processed plus I didn't have the time to implement
>> it
>>> using
 that anyway.
>>>
>>> That is fine, no problem. I realize it takes more time and is a bit
>>> clunky compared to direct function calling, but I can refactor the
>> code
>>> to use KiMail.
>>>
 I'm a bit puzzled by the statement that you are getting global
>> labels
>>> using
 the Arduino project. Can you send me your copy of the project and
>> the
>>> kicad
 files that are generated?
>>>
>>> Sure, this is the official Arduino Mega 2560 rev3 [1]. I uploaded the
>>> import result to my private server [2].
>>>
>>> Best regards,
>>> Orson
>>>
>>> 1. https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-
>>> ref-design.zip
>>> 2. https://orson.net.pl/pub/Arduino_MEGA_2560-Rev3.tar.xz
>>>
 Kind Regards
 Russell

 On Tue, Feb 20, 2018 at 2:05 AM Maciej Sumiński <
>>> maciej.sumin...@cern.ch>
 wrote:

> Hi Russell,
>
> I am grateful for your continuous support. I confirm your patch
 handles
> local net labels and zones in the 

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Wayne Stambaugh]

I didn't notice any issues on linux builds.  Has anyone else confirmed
this doesn't break anything on macos builds?

On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> Attached patch fixes building on macOS with non-Xcode clang:
> * To avoid problems make documentation suggest that 
> cmake_minimum_required(...) has to be the very first statement directly 
> followed by project(...)
> * Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake 
> will ignore CMAKE_CXX_STANDARD with non-Xcode clang
> 
> Tested on macOS with native and non-Xcode clang.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Fix clang-mp-6.0 compile error

[Wayne Stambaugh]

Bernhard,

I merged your patch.  Thanks!

Wayne

On 03/03/2018 02:02 PM, Bernhard Stegmaier wrote:
> Hi,
> 
> Small patch to fix a compile error with (MacPorts) clang-6.0-mp.
> See
>   https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg20164.html
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Git noob question

[Nick Østergaard]

With the shorter notation with -r for --rebase

2018-03-03 21:50 GMT+01:00 Maciej Suminski :

> [...] git pull would do a fetch and merge together, but you want to fetch
>> and rebase -- you can set your .gitconfig to do the fetch and rebase, but I
>> think it's easier to follow along with what's going on if you do the fetch
>> separately and check the tree each time with git hist.
>>
>
> If we are speaking about git tips - I think 'git pull --rebase' is even
> simpler in this case.
>
> Cheers,
> Orson
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

[Bernhard Stegmaier]

Hi,

Attached patch fixes building on macOS with non-Xcode clang:
* To avoid problems make documentation suggest that cmake_minimum_required(...) 
has to be the very first statement directly followed by project(...)
* Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake will 
ignore CMAKE_CXX_STANDARD with non-Xcode clang

Tested on macOS with native and non-Xcode clang.


Regards,
Bernhard




0002-Fix-missing-C-11-compiler-flags-when-building-on-mac.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp