Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

The problem with this branching method is that virtually no one else but
the developer who is working in a feature branch actually tests the code
in the feature branch.  If you are lucky, one other person developer
will test it.  That is why I don't really like this model.  Our
development branch gets a high amount of user testing since it's readily
available in nightly builds.  This results in bugs being fixed quickly
and helps keep the development branch reasonably stable.

On 3/5/2018 10:23 AM, Jon Evans wrote:
> I think you're describing something similar to
> this: http://nvie.com/posts/a-successful-git-branching-model/
> which I think can work pretty well.  It does require more
> work/dedication than the model KiCad uses today.
> 
> On Mon, Mar 5, 2018 at 10:19 AM, José Ignacio  > wrote:
> 
> Once the point release is done, no more bugfix releases are
> necessary on the previous one, that should reduce the effort of
> backporting fixes to a codebase that was branched way back. As it is
> right now, fixing a bug that affects both stable and dev 1 year in
> the future would mean writing a patch for 2 pretty different looking
> codebases (and the bug might not even exist in dev because the code
> was rewritten), so either the effort is (almost) duplicated or the
> bug goes unfixed.
> 
> One way this could work is to, instead of keeping a stale branch
> with the stable release where fixes need to be
> backported/cherry-picked to, just keep big destabilizing changes
> away from Master. And make all stable releases be just a tag in
> Master, with a x.x-bugfix branch existing only if a bug fix had to
> be backported before the next point release was ready, big features
> that can leave kicad unstable or incompatible can go into a staging
> branch that gets pulled into master when the next point release
> merge window opens. Those disruptions almost never happened during
> 5.0 development, most of the time devs have been exceptionally good
> at keeping kicad stable and compatible throughout the dev process,
> except where it couldn't be avoided (like the big sym-lib-table change).
> 
> On Mon, Mar 5, 2018 at 8:52 AM, Wayne Stambaugh
> > wrote:
> 
> There is no formal process.  It's primarily based on discussion
> on the
> mailing list and me making the final decisions.  The road maps
> live in
> the kicad source repo in the /Documentation/development/
> folder.  They
> definitely need updated.  I just haven't gotten around to
> updating them.
>  I was going to do that sometime after the v5 release.
> 
> As for a v5.1, we have not done point releases in the past due
> to lack
> of manpower.  I have done most of the stable branch maintenance
> and it's
> more work than you would think and I just don't have the time to add
> point releases to my list of responsibilities.  If someone
> proposes a
> reasonable way to do this without tying up a lot of developer
> time then
> I'm  not opposed to it.  Please keep in mind the long term
> ramifications
> of potentially maintaining multiple stable branches when developers
> leave the project.  If we could always depend on a given level of
> developer time, this probably wouldn't be that big of an issue
> but we
> cannot depend on any guaranteed level of manpower.  Maybe in the
> future
> that is a luxury we will have.
> 
> Wayne
> 
> On 3/5/2018 9:36 AM, Jon Evans wrote:
> > Do we have a process or workflow for proposing changes to the 
> roadmap? 
> > A number of the things from the V5 roadmap didn't happen, so it 
> might
> > make sense to move some things around to V6 (and possibly a V5.1) 
> roadmaps
> >
> > -Jon
> >
> > On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh 
> 
> > >> wrote:
> >
> >     Jon,
> >
> >     The v6 road map is here:
> >
> >     http://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> >      >
> >
> >     I was planning on working on the schematic object but I 
> wouldn't be
> >     offended if you want to implement it.  If you do decide to work 
> on this,
> >     please keep me in the loop.  I have some things that I 
> definitely want
> >     implemented as part of this object most of which 

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

There is no formal process.  It's primarily based on discussion on the
mailing list and me making the final decisions.  The road maps live in
the kicad source repo in the /Documentation/development/ folder.  They
definitely need updated.  I just haven't gotten around to updating them.
 I was going to do that sometime after the v5 release.

As for a v5.1, we have not done point releases in the past due to lack
of manpower.  I have done most of the stable branch maintenance and it's
more work than you would think and I just don't have the time to add
point releases to my list of responsibilities.  If someone proposes a
reasonable way to do this without tying up a lot of developer time then
I'm  not opposed to it.  Please keep in mind the long term ramifications
of potentially maintaining multiple stable branches when developers
leave the project.  If we could always depend on a given level of
developer time, this probably wouldn't be that big of an issue but we
cannot depend on any guaranteed level of manpower.  Maybe in the future
that is a luxury we will have.

Wayne

On 3/5/2018 9:36 AM, Jon Evans wrote:
> Do we have a process or workflow for proposing changes to the roadmap? 
> A number of the things from the V5 roadmap didn't happen, so it might
> make sense to move some things around to V6 (and possibly a V5.1) roadmaps
> 
> -Jon
> 
> On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh  > wrote:
> 
> Jon,
> 
> The v6 road map is here:
> 
> http://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> 
> I was planning on working on the schematic object but I wouldn't be
> offended if you want to implement it.  If you do decide to work on this,
> please keep me in the loop.  I have some things that I definitely want
> implemented as part of this object most of which you have probably
> already run into with your connectivity work.
> 
> Cheers,
> 
> Wayne
> 
> 
> On 3/4/2018 3:07 PM, 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 

Re: [Kicad-developers] Mac HighDPI performance

[Jon Evans]

Do we have a process or workflow for proposing changes to the roadmap?  A
number of the things from the V5 roadmap didn't happen, so it might make
sense to move some things around to V6 (and possibly a V5.1) roadmaps

-Jon

On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh 
wrote:

> Jon,
>
> The v6 road map is here:
>
> http://docs.kicad-pcb.org/doxygen/v6_road_map.html
>
> I was planning on working on the schematic object but I wouldn't be
> offended if you want to implement it.  If you do decide to work on this,
> please keep me in the loop.  I have some things that I definitely want
> implemented as part of this object most of which you have probably
> already run into with your connectivity work.
>
> Cheers,
>
> Wayne
>
>
> On 3/4/2018 3:07 PM, 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;
> > >>>
> > >>>
> > >>>
> >   

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

Jon,

The v6 road map is here:

http://docs.kicad-pcb.org/doxygen/v6_road_map.html

I was planning on working on the schematic object but I wouldn't be
offended if you want to implement it.  If you do decide to work on this,
please keep me in the loop.  I have some things that I definitely want
implemented as part of this object most of which you have probably
already run into with your connectivity work.

Cheers,

Wayne


On 3/4/2018 3:07 PM, 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));
>

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

It is not possible for me to make any kind of accurate time predictions
about when v6 might be released.  KiCad development does not move at a
constant pace.  Right now, we are at an all time high with developer
involvement but that may not last.  We have had a number of developers
come and go over the years so the project development tends to happen in
short bursts.  I wish I could give you a better answer than that but I
cannot.  I suspect this is the case with most if not all open source
projects.

Wayne

On 3/4/2018 8:40 PM, Andrey Kuznetsov wrote:
> 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    >> 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 

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] 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] 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] 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] 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] 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] 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] 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] Mac HighDPI performance

[Bernhard Stegmaier]

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 zoom
> Legacy: 1300-1700ms for panning, 600ms for zoom
> Low Res mode: did not notice speed increase, except maybe Fallback was ~400ms 
> faster.
> 
> I'm not saying halt the horses, certain modes are obviously limited, ie 
> Legacy and Fallback by the nature of the task presented, but eeschema is 
> barely displaying 10% of the content pcbnew is but lagging so much worse!
> 
> Just thought I'd include rendering of the Accelerated Graphics (top to 
> bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
> All 3 modes are responsive, probably <50-100ms lag, I'd consider this 
> performance great, considering the amount of elements on screen.
> 
> 
> How long should it take to delete this many selected elements in pcbnew?
> Answer: about 50x too long! I think it was like 3mins, perhaps ESC key should 
> be available to press anytime to undo the delete action and restore to 
> pre-delete screen when accidental actions are triggered that take forever to 
> complete?
> 
> 
> On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier    >> wrote:
> 
> Hi,
> 
> to be honest, I don’t really know what this is about.
> 
> @Andrey:
> You looked for a very complex (foreign) project (Chris mainboard?)
> to prove that eeschema is slow on Mac?
> Well, we know that and we told you already some weeks/months ago
> why it is like it is (if memory serves me right).
> 
> Or, do you have an own project that is so ridiculously slow, that
> you can’t work with it?
> If so, please provide it so that we can analyse why this specific
> project behaves like that.
> If you can’t or don’t want to provide it we could tell you how to
> do some performance measurements so that we might see something.
> 
> Obviously, there are a number of Mac users here and also over at
> the KiCad forum who might also be happy to get some more
> performance here and there, but who are in general reasonably able
> to work on their projects (including myself, on a 2012 Retina
> MacBook with only an i5).
> 
> 
> Regards,
> Bernhard
> 
> > On 2. Mar 2018, at 17:59, Andy Peters 

Re: [Kicad-developers] Mac HighDPI performance

[Wayne Stambaugh]

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 zoom
Legacy: 1300-1700ms for panning, 600ms for zoom
Low Res mode: did not notice speed increase, except maybe Fallback was 
~400ms faster.


I'm not saying halt the horses, certain modes are obviously limited, 
ie Legacy and Fallback by the nature of the task presented, but 
eeschema is barely displaying 10% of the content pcbnew is but lagging 
so much worse!


Just thought I'd include rendering of the Accelerated Graphics (top to 
bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
All 3 modes are responsive, probably <50-100ms lag, I'd consider this 
performance great, considering the amount of elements on screen.



How long should it take to delete this many selected elements in pcbnew?
Answer: about 50x too long! I think it was like 3mins, perhaps ESC key 
should be available to press anytime to undo the delete action and 
restore to pre-delete screen when accidental actions are triggered 
that take forever to complete?



On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier 
> wrote:


Hi,

to be honest, I don’t really know what this is about.

@Andrey:
You looked for a very complex (foreign) project (Chris mainboard?)
to prove that eeschema is slow on Mac?
Well, we know that and we told you already some weeks/months ago
why it is like it is (if memory serves me right).

Or, do you have an own project that is so ridiculously slow, that
you can’t work with it?
If so, please provide it so that we can analyse why this specific
project behaves like that.
If you can’t or don’t want to provide it we could tell you how to
do some performance measurements so that we might see something.

Obviously, there are a number of Mac users here and also over at
the KiCad forum who might also be happy to get some more
performance here and there, but who are in general reasonably able
to work on their projects (including myself, on a 2012 Retina
MacBook with only an i5).


Regards,
Bernhard

> On 2. Mar 2018, at 17:59, Andy Peters > wrote:
>
>
>
>> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand
> wrote:
>>
>> Andrey-
>>
>> I'm moving this to a new thread so that we don't conflate the
OpenMP discussion with this.
>>
>> Can you test running Kicad with the "Open in Low Resolution"
mode enabled?  You can activate this by choosing "Get Info" on the
main KiCad application and checking the option that says "Open in
Low Resolution".  You may need to do the same for the other
applications (Eeschema, pcbnew, etc) as well.
>
> testing on my 2017” touch-bar MBP …
  

Re: [Kicad-developers] Mac HighDPI performance

[Bernhard Stegmaier]

Hi,

to be honest, I don’t really know what this is about.

@Andrey:
You looked for a very complex (foreign) project (Chris mainboard?) to prove 
that eeschema is slow on Mac?
Well, we know that and we told you already some weeks/months ago why it is like 
it is (if memory serves me right).

Or, do you have an own project that is so ridiculously slow, that you can’t 
work with it?
If so, please provide it so that we can analyse why this specific project 
behaves like that.
If you can’t or don’t want to provide it we could tell you how to do some 
performance measurements so that we might see something.

Obviously, there are a number of Mac users here and also over at the KiCad 
forum who might also be happy to get some more performance here and there, but 
who are in general reasonably able to work on their projects (including myself, 
on a 2012 Retina MacBook with only an i5).


Regards,
Bernhard

> On 2. Mar 2018, at 17:59, Andy Peters  wrote:
> 
> 
> 
>> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand  wrote:
>> 
>> Andrey-
>> 
>> I'm moving this to a new thread so that we don't conflate the OpenMP 
>> discussion with this.
>> 
>> Can you test running Kicad with the "Open in Low Resolution" mode enabled?  
>> You can activate this by choosing "Get Info" on the main KiCad application 
>> and checking the option that says "Open in Low Resolution".  You may need to 
>> do the same for the other applications (Eeschema, pcbnew, etc) as well.
> 
> testing on my 2017” touch-bar MBP … 
> 
> Good g-d, low-res mode looks fuzzy and weird!
> 
> I don’t notice any specific differences in EESchema performance. Maybe my 
> schematic isn’t busy enough? I’m a fan of using more smaller sheets with less 
> info on each than one big sheet with everything.
> 
> I know, anecdote is not evidence.
> 
> -a
> 
> 
>> 
>> -Seth
>> 
>> ​​2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>> Hi,
>> 
>> So for now I've had a chance to test the motherboard project on my Retina 
>> macbook display.
>> eeschema: horrible zoom, feels like elastic band zoom and I have all scroll 
>> wheel accelerations and similar disabled, zoom response is super laggy, 
>> cannot work like this, will need to make schematics on windows.
>> pcbnew by order of slowness:
>> legacy - pretty slow, zoom lag is major, boo boo
>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom 
>> responsiveness
>> 
>> I'll report tomorrow on 5K LG display.
>> ​
> 
> 
> ___
> 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

[Andy Peters]

> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand  wrote:
> 
> Andrey-
> 
> I'm moving this to a new thread so that we don't conflate the OpenMP 
> discussion with this.
> 
> Can you test running Kicad with the "Open in Low Resolution" mode enabled?  
> You can activate this by choosing "Get Info" on the main KiCad application 
> and checking the option that says "Open in Low Resolution".  You may need to 
> do the same for the other applications (Eeschema, pcbnew, etc) as well.

testing on my 2017” touch-bar MBP … 

Good g-d, low-res mode looks fuzzy and weird!

I don’t notice any specific differences in EESchema performance. Maybe my 
schematic isn’t busy enough? I’m a fan of using more smaller sheets with less 
info on each than one big sheet with everything.

I know, anecdote is not evidence.

-a


> 
> -Seth
> 
> ​​2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
> Hi,
> 
> So for now I've had a chance to test the motherboard project on my Retina 
> macbook display.
> eeschema: horrible zoom, feels like elastic band zoom and I have all scroll 
> wheel accelerations and similar disabled, zoom response is super laggy, 
> cannot work like this, will need to make schematics on windows.
> pcbnew by order of slowness:
> legacy - pretty slow, zoom lag is major, boo boo
> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom 
> responsiveness
> 
> I'll report tomorrow on 5K LG display.
> ​


___
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]

Hi Andrey,

I just tried some and I didn't see a large difference in zoom behavior
between eeschema and pcbnew.  They do use different zoom mechanisms when
you use Modern toolset in PcbNew, but the difference is minor.
Eeschema is not hardware-accelerated so I would expect that running it in
low resolution mode makes a much bigger difference than with PcbNew in
Modern toolset.

-Jon

On Fri, Mar 2, 2018 at 12:52 AM, Andrey Kuznetsov 
wrote:

> Thanks, I didn't know that, Open in Low Resolution definitely speeds up
> eeschema, I know kicad has this info on the website, however that fact that
> you have to go inside the package and set that to low res mode as far as I
> remember was not stated!
>
> The docs should be updated to properly show how to enable low res mode,
> step by step! Setting the main kicad.app to low res mode is not enough,
> eeschema.app inside kicad.app package needs to be set.
>
> It didn't feel like pcbnew got faster, I'll have to try on 5K monitor and
> I found some supersampling and anti-aliasing modes that I want to turn on
> to check.
>
> Thank you to someone on the dev team I guess for getting rid of the mouse
> warp events from right click, however the zoom mouse warp to the center of
> the screen is still a major WTF.
>
> Question: Is there something different in the way pcbnew does the zooming
> compared to eeschema? My mouse zooming feels weird in escheema, but not in
> pcbnew.
> I think pcbnew has a linear incremental step and the zooming is crisp,
> display changes per mouse wheel click, while eeschema what feels like
> rubber banding between wheel clicks, step sizes are not linear thus causing
> zooming ooogles. My mouse is a logitech mx master 2s using the ratchet
> mode. In pcbnew, the zoom happens every ratchet, while in eeschema the zoom
> can happen inbetween ratchets, like I just tilt the wheel and bring it back
> but the zoom changed in one direction only, ie I can zoom all the way in
> without ratcheting. In pcbnew you cannot do that, and it feels natural.
>
>
> Bug or not? When I open eeschema and pcbnew from KiCad app, eeschema opens
> as a standalone app and shows up in the dock on macOS while pcbnew opens as
> another window that's part of kicad app. This caused issues with my logitec
> options software for custom mouse button settings because I only programmed
> kicad, but not eeschema.
>
> On Thu, Mar 1, 2018 at 8:37 PM, Seth Hillbrand 
> wrote:
>
>> Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
>> right-click and go to "Show Original", you will get the actual
>> application.  Get Info there will allow you to select "Open in Low
>> Resolution" for that application.
>>
>> -S
>>
>> 2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov :
>>
>>> Only KiCad app has Open in Low Resolution Mode, and I already had it
>>> enabled!
>>>
>>> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand >> > wrote:
>>>
 Andrey-

 I'm moving this to a new thread so that we don't conflate the OpenMP
 discussion with this.

 Can you test running Kicad with the "Open in Low Resolution" mode
 enabled?  You can activate this by choosing "Get Info" on the main KiCad
 application and checking the option that says "Open in Low Resolution".
 You may need to do the same for the other applications (Eeschema, pcbnew,
 etc) as well.

 -Seth

 ​
 ​
 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :

> Hi,
>
> So for now I've had a chance to test the motherboard project on my
> Retina macbook display.
> eeschema: horrible zoom, feels like elastic band zoom and I have all
> scroll wheel accelerations and similar disabled, zoom response is super
> laggy, cannot work like this, will need to make schematics on windows.
> pcbnew by order of slowness:
> legacy - pretty slow, zoom lag is major, boo boo
> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
> modern (accelerated) - almost cannot feel the lag, very nice, nice
> zoom responsiveness
>
> I'll report tomorrow on 5K LG display.
>
 ​


 ___
 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
>>>
>>
>>
>
>
> --
> 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
>
> 

Re: [Kicad-developers] Mac HighDPI performance

[Kliment (Future Bits)]

On 02.03.2018 06:52, Andrey Kuznetsov wrote:

> Thank you to someone on the dev team I guess for getting rid of the mouse
> warp events from right click, however the zoom mouse warp to the center of
> the screen is still a major WTF.
That is an option in preferences -> general -> pan and zoom

___
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]

Thanks, I didn't know that, Open in Low Resolution definitely speeds up
eeschema, I know kicad has this info on the website, however that fact that
you have to go inside the package and set that to low res mode as far as I
remember was not stated!

The docs should be updated to properly show how to enable low res mode,
step by step! Setting the main kicad.app to low res mode is not enough,
eeschema.app inside kicad.app package needs to be set.

It didn't feel like pcbnew got faster, I'll have to try on 5K monitor and I
found some supersampling and anti-aliasing modes that I want to turn on to
check.

Thank you to someone on the dev team I guess for getting rid of the mouse
warp events from right click, however the zoom mouse warp to the center of
the screen is still a major WTF.

Question: Is there something different in the way pcbnew does the zooming
compared to eeschema? My mouse zooming feels weird in escheema, but not in
pcbnew.
I think pcbnew has a linear incremental step and the zooming is crisp,
display changes per mouse wheel click, while eeschema what feels like
rubber banding between wheel clicks, step sizes are not linear thus causing
zooming ooogles. My mouse is a logitech mx master 2s using the ratchet
mode. In pcbnew, the zoom happens every ratchet, while in eeschema the zoom
can happen inbetween ratchets, like I just tilt the wheel and bring it back
but the zoom changed in one direction only, ie I can zoom all the way in
without ratcheting. In pcbnew you cannot do that, and it feels natural.


Bug or not? When I open eeschema and pcbnew from KiCad app, eeschema opens
as a standalone app and shows up in the dock on macOS while pcbnew opens as
another window that's part of kicad app. This caused issues with my logitec
options software for custom mouse button settings because I only programmed
kicad, but not eeschema.

On Thu, Mar 1, 2018 at 8:37 PM, Seth Hillbrand 
wrote:

> Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
> right-click and go to "Show Original", you will get the actual
> application.  Get Info there will allow you to select "Open in Low
> Resolution" for that application.
>
> -S
>
> 2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov :
>
>> Only KiCad app has Open in Low Resolution Mode, and I already had it
>> enabled!
>>
>> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand 
>> wrote:
>>
>>> Andrey-
>>>
>>> I'm moving this to a new thread so that we don't conflate the OpenMP
>>> discussion with this.
>>>
>>> Can you test running Kicad with the "Open in Low Resolution" mode
>>> enabled?  You can activate this by choosing "Get Info" on the main KiCad
>>> application and checking the option that says "Open in Low Resolution".
>>> You may need to do the same for the other applications (Eeschema, pcbnew,
>>> etc) as well.
>>>
>>> -Seth
>>>
>>> ​
>>> ​
>>> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>>>
 Hi,

 So for now I've had a chance to test the motherboard project on my
 Retina macbook display.
 eeschema: horrible zoom, feels like elastic band zoom and I have all
 scroll wheel accelerations and similar disabled, zoom response is super
 laggy, cannot work like this, will need to make schematics on windows.
 pcbnew by order of slowness:
 legacy - pretty slow, zoom lag is major, boo boo
 modern (fallback) - decent, but the lag can be felt, zoom lag is minor
 modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
 responsiveness

 I'll report tomorrow on 5K LG display.

>>> ​
>>>
>>>
>>> ___
>>> 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
>>
>
>


-- 
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] Mac HighDPI performance

[Seth Hillbrand]

Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
right-click and go to "Show Original", you will get the actual
application.  Get Info there will allow you to select "Open in Low
Resolution" for that application.

-S

2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov :

> Only KiCad app has Open in Low Resolution Mode, and I already had it
> enabled!
>
> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand 
> wrote:
>
>> Andrey-
>>
>> I'm moving this to a new thread so that we don't conflate the OpenMP
>> discussion with this.
>>
>> Can you test running Kicad with the "Open in Low Resolution" mode
>> enabled?  You can activate this by choosing "Get Info" on the main KiCad
>> application and checking the option that says "Open in Low Resolution".
>> You may need to do the same for the other applications (Eeschema, pcbnew,
>> etc) as well.
>>
>> -Seth
>>
>> ​
>> ​
>> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>>
>>> Hi,
>>>
>>> So for now I've had a chance to test the motherboard project on my
>>> Retina macbook display.
>>> eeschema: horrible zoom, feels like elastic band zoom and I have all
>>> scroll wheel accelerations and similar disabled, zoom response is super
>>> laggy, cannot work like this, will need to make schematics on windows.
>>> pcbnew by order of slowness:
>>> legacy - pretty slow, zoom lag is major, boo boo
>>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
>>> responsiveness
>>>
>>> I'll report tomorrow on 5K LG display.
>>>
>> ​
>>
>>
>> ___
>> 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] Mac HighDPI performance

[Andrey Kuznetsov]

Only KiCad app has Open in Low Resolution Mode, and I already had it
enabled!

On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand 
wrote:

> Andrey-
>
> I'm moving this to a new thread so that we don't conflate the OpenMP
> discussion with this.
>
> Can you test running Kicad with the "Open in Low Resolution" mode
> enabled?  You can activate this by choosing "Get Info" on the main KiCad
> application and checking the option that says "Open in Low Resolution".
> You may need to do the same for the other applications (Eeschema, pcbnew,
> etc) as well.
>
> -Seth
>
> ​
> ​
> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>
>> Hi,
>>
>> So for now I've had a chance to test the motherboard project on my Retina
>> macbook display.
>> eeschema: horrible zoom, feels like elastic band zoom and I have all
>> scroll wheel accelerations and similar disabled, zoom response is super
>> laggy, cannot work like this, will need to make schematics on windows.
>> pcbnew by order of slowness:
>> legacy - pretty slow, zoom lag is major, boo boo
>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
>> responsiveness
>>
>> I'll report tomorrow on 5K LG display.
>>
> ​
>
>
> ___
> 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