kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #34673
Re: Mac HighDPI performance
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 <stambaughw@xxxxxxxxx>
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 <jeff@xxxxxxxxx <mailto:
>> jeff@xxxxxxxxx>> 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 <jeff@xxxxxxxxx
>>> <mailto:jeff@xxxxxxxxx>> 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 <jon@xxxxxxxxxxxxx
>>>> <mailto:jon@xxxxxxxxxxxxx>> 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 <stambaughw@xxxxxxxxx
>>>> <mailto:stambaughw@xxxxxxxxx>> 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
>>>> <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>
>>>> > <mailto:stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>>> 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
>>>> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>>> >> <mailto:stambaughw@xxxxxxxxx
>>>> <mailto:stambaughw@xxxxxxxxx>>> 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::Sc
>>>> rollRect(constwxRect*rect,intdx,intdy)
>>>> >>>
>>>> >>> {
>>>> >>>
>>>> >>> #if1
>>>> >>>
>>>> >>> SetNeedsDisplay();
>>>> >>>
>>>> >>> #else
>>>> >>>
>>>> >>> //Weshoulddosomethinglike
>>>> this,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::dr
>>>> awRect(void*rect,WXWidgetslf,void*WXUNUSED(_cmd))
>>>> >>>
>>>> >>> {
>>>> >>>
>>>> >>> //preparingtheupdateregion
>>>> >>>
>>>> >>> wxRegionupdateRgn;
>>>> >>>
>>>> >>>
>>>> >>> //sinceaddingmanyrectstoa
>>>> regionisacostlyprocess,bydefaultusetheboundingrect
>>>> >>>
>>>> >>> #if0
>>>> >>>
>>>> >>> constNSRect*rects;
>>>> >>>
>>>> >>> NSIntegercount;
>>>> >>>
>>>> >>> [slfgetRectsBeingDrawn:&rectscount:&count];
>>>> >>>
>>>> >>> for(inti=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:
>>>> >>>
>>>> >>> 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
>>>> >>>> <stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>
>>>> <mailto:stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx
>>>> >>
>>>> >>>> <mailto:stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>>> wrote:
>>>> >>>>
>>>> >>>> No.
>>>> >>>>
>>>> >>>>> On 4. Mar 2018, at 01:51, Andrey Kuznetsov
>>>> <kandrey89@xxxxxxxxx <mailto:kandrey89@xxxxxxxxx>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>> 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
>>>> >>>>> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>>> <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>>>> >>>>> <mailto:stambaughw@xxxxxxxxx
>>>> <mailto:stambaughw@xxxxxxxxx>>> 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
>>>> >>>>> <kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>>> 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
>>>> <https://bugs.launchpad.net/kicad/+bug/1753054>
>>>> >>>>> <https://bugs.lau
>>>> nchpad.net/kicad/+bug/1753054
>>>> <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.
>>>> >>>>> <image.png>
>>>> >>>>>
>>>> >>>>> 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?
>>>> >>>>> <image.png>
>>>> >>>>>
>>>> >>>>> On Fri, Mar 2, 2018 at 9:53 AM, Bernhard
>>>> Stegmaier
>>>> >>>>> <stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>
>>>> >>>>> <mailto:stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>> <mailto:stegmaier@sw-syste
>>>> ms.de
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>>
>>>> >>>>> <mailto:stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>
>>>> >>>>> <mailto:stegmaier@xxxxxxxxxxxxx
>>>> <mailto:stegmaier@xxxxxxxxxxxxx>>>> 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
>>>> >>>>> <devel@xxxxxxxxx <mailto:devel@xxxxxxxxx>
>>>> >>>>> <mailto:devel@xxxxxxxxx
>>>> <mailto:devel@xxxxxxxxx>> <mailto:devel@xxxxxxxxx
>>>> <mailto:devel@xxxxxxxxx>>
>>>> >>>>>
>>>> >>>>> <mailto:devel@xxxxxxxxx
>>>> <mailto:devel@xxxxxxxxx> <mailto:devel@xxxxxxxxx
>>>> <mailto:devel@xxxxxxxxx>>>> wrote:
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >> On Mar 1, 2018, at 8:53 PM, Seth
>>>> Hillbrand
>>>> >>>>> <seth.hillbrand@xxxxxxxxx
>>>> <mailto:seth.hillbrand@xxxxxxxxx>
>>>> >>>>> <mailto:seth.hillbrand@xxxxxxxxx
>>>> <mailto:seth.hillbrand@xxxxxxxxx>>
>>>> >>>>> <mailto:seth.hillbrand@xxxxxxxxx
>>>> <mailto:seth.hillbrand@xxxxxxxxx>>
>>>> >>>>> <mailto:seth.hillbrand@xxxxxxxxx
>>>> <mailto:seth.hillbrand@xxxxxxxxx>
>>>> >>>>> <mailto:seth.hillbrand@xxxxxxxxx
>>>> <mailto:seth.hillbrand@xxxxxxxxx>>>> 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
>>>> >>>>> <kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>>>:
>>>> >>>>> >> 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
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> <https://launchpad.net/~
>>>> kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>>
>>>> >>>>> > Post to
>>>> >>>>> : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-developers@list
>>>> s.launchpad.net
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>>>> >>>>> > Unsubscribe :
>>>> >>>>> https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> <https://launchpad.net/~
>>>> kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>>
>>>> >>>>> > More help :
>>>> https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> _____________________________
>>>> __________________
>>>> >>>>> Mailing
>>>> >>>>> list: https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> <https://launchpad.net/~
>>>> kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>>
>>>> >>>>> Post to
>>>> >>>>> : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-developers@list
>>>> s.launchpad.net
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>>>> >>>>> Unsubscribe
>>>> >>>>> : https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> <https://launchpad.net/~
>>>> kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>>
>>>> >>>>> More help :
>>>> https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <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]
>>>> >>>>>
>>>> >>>>> kandrey89@xxxxxxxxx <mailto:kandrey89@xxxxxxxxx>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>
>>>> >>>>> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx> <mailto:kandrey89@xxxxxxxxx
>>>> <mailto:kandrey89@xxxxxxxxx>>>
>>>> >>>>> Live Long and Prosper,
>>>> >>>>> Andrey
>>>> >>>>> _________________
>>>> ______________________________
>>>> >>>>> Mailing list:
>>>> https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> Post to :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-dev
>>>> elopers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>>
>>>> >>>>> Unsubscribe :
>>>> https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> More help :
>>>> https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>
>>>> >>>>> <https://help.launchpad.net/ListHelp
>>>> <https://help.launchpad.net/ListHelp>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> ______________________
>>>> _________________________
>>>> >>>>> Mailing list:
>>>> https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>> >>>>> Post to :
>>>> kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >>>>> Unsubscribe :
>>>> https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>
>>>> >>>>> <https://launchpad.net/~kicad-developers
>>>> <https://launchpad.net/~kicad-developers>>
>>>
>>>
--
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]
kandrey89@xxxxxxxxx
Live Long and Prosper,
Andrey
Follow ups
References
-
Re: Mac HighDPI performance
From: Seth Hillbrand, 2018-03-02
-
Re: Mac HighDPI performance
From: Andy Peters, 2018-03-02
-
Re: Mac HighDPI performance
From: Bernhard Stegmaier, 2018-03-02
-
Re: Mac HighDPI performance
From: Andrey Kuznetsov, 2018-03-03
-
Re: Mac HighDPI performance
From: Jeff Young, 2018-03-03
-
Re: Mac HighDPI performance
From: Wayne Stambaugh, 2018-03-03
-
Re: Mac HighDPI performance
From: Andrey Kuznetsov, 2018-03-04
-
Re: Mac HighDPI performance
From: Bernhard Stegmaier, 2018-03-04
-
Re: Mac HighDPI performance
From: Jeff Young, 2018-03-04
-
Re: Mac HighDPI performance
From: Wayne Stambaugh, 2018-03-04
-
Re: Mac HighDPI performance
From: Bernhard Stegmaier, 2018-03-04
-
Re: Mac HighDPI performance
From: Jon Evans, 2018-03-04
-
Re: Mac HighDPI performance
From: Wayne Stambaugh, 2018-03-04
-
Re: Mac HighDPI performance
From: Jon Evans, 2018-03-04
-
Re: Mac HighDPI performance
From: Jeff Young, 2018-03-04
-
Re: Mac HighDPI performance
From: Jeff Young, 2018-03-04
-
Re: Mac HighDPI performance
From: Andrey Kuznetsov, 2018-03-05
-
Re: Mac HighDPI performance
From: Wayne Stambaugh, 2018-03-05
