Hi Bernhard,
I have just pushed your patch (rev 6560). It is better to avoid #ifdefs
if possible, but I am not able to provide a better solution at the
moment and your changes have a positive impact on the overall
performance. Thank you for taking care of the problem.
Regards,
Orson
On 02/12/201
Hi Orson,
I just tried with some ThinkPad mouse I have from my work laptop on my MacBook.
Panning seems to be fine with that mouse with and without the timer (panning
with the usual shift/ctrl-scrollwheel).
Especially, there are no hangs with the timer.
Regards,
Bernhard
> On 12 Feb 2016, at 1
Hi Bernhard,
I see your patch significantly affects the performance, but I need to
know one thing before I apply it. Does panning work fine with other
input devices (i.e. ones that do not send events with high frequency)?
If so, then maybe we should have a second look at the
wx_view_controls.cpp #
If you want to get an impression… here
https://drive.google.com/open?id=0Bxxu6Mh3pHubZ3BGSjFGNV9oYXc
is a small video with the touchpad panning I am currently working on.
First part is with timer, second without.
Watch my fingers in the first part… yes, they do move even if KiCad does
nothing a
Some devices provide what are termed precise scrolling deltas and generate a
far greater number of scrolling events. The trackpad is such a device. Cocoa
events have a hasPreciseScrollingDeltas method that will provide this
information. It is used in wxWidgets window.mm, for instance, when tr
Yes, I have mentioned this feature for years now.
Would be good to have the zoom sensitive to distance moved rather than
events received. High resolution trackpads and mice (which are very nice
for positioning tracks and pads) generate more events/sec than $3.99
Inland mice from China.
Have
> On 08 Feb 2016, at 18:18, Maciej Sumiński wrote:
>>
>
> Does it mean the issue depends on the input device?
AFAIK yes.
“Normal” mice seem to produce much less events than Mac devices.
Especially my MacBook touchpad is very sensitive and usual zoom is pretty
useless with it.
If you only sli
On 02/08/2016 06:17 PM, Andy Peters wrote:
>
>> On Feb 8, 2016, at 9:25 AM, Wayne Stambaugh wrote:
>>
>> I'm surprised other osx users have not complained about this before now.
>> Is it possible that this is due a particular version of wxWidgets
>> and/or osx and only Bernhard is seeing this?
>
> On Feb 8, 2016, at 9:25 AM, Wayne Stambaugh wrote:
>
> I'm surprised other osx users have not complained about this before now.
> Is it possible that this is due a particular version of wxWidgets
> and/or osx and only Bernhard is seeing this?
I haven’t seen it because I rarely use Kicad on t
On Mon, Feb 8, 2016 at 9:46 AM, Bernhard Stegmaier
wrote:
> But, I guess most OS X users are just used to such things with KiCad
> because especially legacy canvas is also not really smooth.
This is what I experienced as well. The UI responsiveness is pretty bad all
around, so my expectations
No, this has been there as long as I use GAL…
But, I guess most OS X users are just used to such things with KiCad because
especially legacy canvas is also not really smooth.
> On 08 Feb 2016, at 15:34, Maciej Sumiński wrote:
>
> Redrawing has to be done with every mouse movement (at least to
I see it on both of my machines with 10.10 and 10.11.
It is probably not so obvious with the current way of panning.
With the touchpad panning patch/function (what also many OS X users would like
to have) I’ll post these days it is very obvious.
Those who tested preliminary versions of this patch
I'm surprised other osx users have not complained about this before now.
Is it possible that this is due a particular version of wxWidgets
and/or osx and only Bernhard is seeing this?
On 2/8/2016 9:34 AM, Maciej Sumiński wrote:
> Redrawing has to be done with every mouse movement (at least to red
Redrawing has to be done with every mouse movement (at least to redraw
the cursor), so to avoid issuing too frequent paint events, the timer
limits the number of requests per second.
I cannot really tell why there is such discrepancy in wxTimer behavior
depending on the platform. Was this the case
I wonder if the throttling is done by wxWidgets, do we even need to
throttle on windows and linux? Would one of our gal devs please comment
on why this is necessary? Is this patch good to go on OSX?
On 2/6/2016 10:25 AM, Bernhard Stegmaier wrote:
> Hi,
>
> attached a patch to disable the below
I just made a simple test and took the time between onPaint() calls without the
timer.
Even with heaviest scrolling I usually see it called only >16ms (looks like
only the last call when I stop scrolling can be <16ms).
So, it seems at least on OS X someone else (wxWidgets or OS X) is already doin
Any other OSX devs object to this being committed? Also, do we really
need to throttle on the other platforms? If not, I would rather not
have the ugly platform specific #ifdef/#endif code if we don't need it.
On 2/6/2016 10:25 AM, Bernhard Stegmaier wrote:
> Hi,
>
> attached a patch to disable
Hi,attached a patch to disable the below mentioned FPS limitation on OS X.Without limitation/timer scrolling is smooth as expected.Even with heaviest scrolling or other use-cases I tested I did not observe any increased CPU load.At least, from a user perspective possibly drawing too often seems way
18 matches
Mail list logo
