Re: [Kicad-developers] Mac HighDPI performance

2018-03-05 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-05 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-05 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-05 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-05 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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: >

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-04 Thread 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()

Re: [Kicad-developers] Mac HighDPI performance

2018-03-03 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-03 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-02 Thread 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,

Re: [Kicad-developers] Mac HighDPI performance

2018-03-02 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-02 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-02 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-01 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-01 Thread 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

Re: [Kicad-developers] Mac HighDPI performance

2018-03-01 Thread 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