kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 12/23/2015 8:09 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> I got a trace and that doesn’t look very different to what e.g. I see on
> my machine.
> 
> One observation is that we are spending almost 1/3 of the drawing time
> in drawing the grid.
> Unfortunately, on OSX wxWidgets DrawPoint() has no native expression, so
> it is mapped to drawing a line (x, y, x+1, y+1).
> So, we draw many very small lines here…

That's ugly.

> Scrolling with deactivated grid is by far more smooth/snappy, so
> improving this would definitely help.

This will at least help users in the short term but we should look at a
better long term solution.

> 
> I’ll try if some other basic drawing primitive like rectangle or circle
> or a different pen might result in better performance (I don’t have very
> much hope in that).
> 
> Another idea:
> In GAL canvas grid is already drawn as lines and not as dots as in legacy.
> Personally, I also like dots as grid better but as a last resort to
> improve performance any objections about drawing grid as lines also in
> default canvas (maybe only on OSX)?

I'm not a big fan of lines for the grid so if you do make a change,
please make it optional.  Either run time with a user selectable option
or build time for OSX only is fine.

> 
> And:
> In the DrawGrid() code there has been some Blit-Code to draw/copy the
> grid which obviously didn’t work according to the comment and was
> removed somewhen (comment is still there…).
> Does anybody know why it was not used or didn’t work and would this
> probably be another alternative?

The problem is how we calculated the damaged area to redraw the blit.
We never got it right and the scrolling issues only complicate the
matter.  If the blit is off by even 1 pixel, you end up with some pretty
interesting display issues.  The other option is to blit the entire
visible area of the drawing but that requires redrawing and refreshing
the entire display which can be a lot of addition overhead.  Technically
it should be faster to draw to a bitmap in memory and blit the results
to the display than the constant XOR redrawing we do but my guess is
that it would require some major reworking to get it right.  I worked on
this a long time ago and gave up due to the design of our drawing code.

> 
> 
> Regards,
> Bernhard
> 
> 
>> On 22 Dec 2015, at 21:41, Chris Pavlina <pavlina.chris@xxxxxxxxx
>> <mailto:pavlina.chris@xxxxxxxxx>> wrote:
>>
>> He can install xcode but isn't familiar with it (does embedded
>> development, but not PC) - is this something that would be relatively
>> easy to do for an otherwise computer-literate non-developer?
>>
>> On Dec 22, 2015 4:57 AM, "Bernhard Stegmaier" <stegmaier@xxxxxxxxxxxxx
>> <mailto:stegmaier@xxxxxxxxxxxxx>> wrote:
>>
>>     I did the profiling Adam mentioned and found that dotted/dashed
>>     lines didn’t work well in pcbnew and footprint editor.
>>     This was fixed in rev6278.
>>
>>     How complex is the project?
>>     Compared to some of the demo projects?
>>
>>     Does he have Xcode on his machine?
>>     I could provide some hints on how to make a profiling trace of his
>>     slow use-cases… I think it can be saved and probably I could
>>     analyse a bit.
>>
>>
>>     Regards,
>>     Bernhard
>>
>>     > On 22 Dec 2015, at 01:20, Chris Pavlina <pavlina.chris@xxxxxxxxx
>>     <mailto:pavlina.chris@xxxxxxxxx>> wrote:
>>     >
>>     > Apparently even eeschema is unusable on this particular setup. :(
>>     >
>>     > On Mon, Dec 21, 2015 at 06:08:44PM -0600, Adam Wolf wrote:
>>     >> IIRC, OS X doesn't have an XOR draw mode.
>>     >>
>>     >> After a certain size PCB, PCBnew legacy graphics on OS X is
>>     unusable.  This
>>     >> size is much lower than it is in Linux, on the same hardware.
>>     >>
>>     >> Someone awesome on the list, I forget who right now, did some
>>     profiling and
>>     >> fixed a wx issue that was causing some slowness, and I used the
>>     profiler a
>>     >> bit more after that and was unable to find substantial
>>     increases with the
>>     >> same technique.
>>     >>
>>     >> Adam Wolf
>>     >>
>>     >> Okay, this is just a quick call for information for now, not
>>     sure if this
>>     >> is a known issue (and I'm relaying from a friend, don't have
>>     one here to
>>     >> test) - have any OSX users noticed some severe slowness in the
>>     legacy
>>     >> graphics (including eeschema) while panning, zooming, and
>>     picking up and
>>     >> moving objects? This is on a relatively recent (2014, IIRC, and
>>     another
>>     >> 2015) Macbook. Apparently it's borderline unusable.
>>     >>
>>     >> _______________________________________________
>>     >> Mailing list: https://launchpad.net/~kicad-developers
>>     >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>     >> Unsubscribe : https://launchpad.net/~kicad-developers
>>     >> More help   : https://help.launchpad.net/ListHelp
>>     >
>>     > _______________________________________________
>>     > Mailing list: https://launchpad.net/~kicad-developers
>>     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>     > Unsubscribe : https://launchpad.net/~kicad-developers
>>     > More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>