Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault

[Torsten Hüter]

Chris:
>> With a proper implementation this should be indistinguishable from
>> coroutines, including to wx.

This is your opinion not mine, I'm not sure. Again, read the paragraph about 
secondary threads:
http://docs.wxwidgets.org/3.1/overview_thread.html

"[..] under Win32 a thread can only access GDI objects such as pens, brushes, 
device contexts created by itself and not by the other threads [..]"

One of the reasons why they strongly recommend "no secondary threads call GUI 
functions".

--

However, if you can ensure that the coroutines never call GUI functions, 
threads should be a nice alternative. I remember Orson has written, that this 
should be possible. Maybe he can answer the question if this restriction is 
still acceptable. Then I could rescue my implementation from my backups.

Thanks,
Torsten

___
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] [PATCH] Fix MacOS coroutine segfault

[Torsten Hüter]

Hi Chris,
 
please read the mail archive (Jan 2016), I've already tried this and 
experimented with different coroutine implementations. I've tested of course a 
variant based on pthreads too.
 
The major showstopper was, that's not recommended to use threads for GUI work, 
please read:
http://docs.wxwidgets.org/3.1/overview_thread.html
 
"[..] When writing a multi-threaded application, it is strongly recommended 
that no secondary threads call GUI functions. [..]"
 
This would be very restrictive and can't be guaranteed.
 
If you're still interested, I could upload this implementation on launchpad 
again. I've stopped working on this, because Tom proposed his libcontext and 
with the bugfixes it was working so far well on Windows.
 
--
 
In my opinion I'd drop coroutines entirely - they are nice if they're a 
build-in language concept (like Modula-2 coroutines), but C++ has not yet the 
best support for that. Alternatives are simple FSMs, sure that makes the code a 
bit bulkier, but would work on every machine without having to maintain 
assembler code.  The disadvantage is the work that you have to invest there (I 
have not much time to develop KiCad code anymore).
 
Thanks,
Torsten

Sorry for the double post, forgotten to switch to plain text.
 
>> My point is that threading could be used to implement a *drop-in
>> replacement*...not that the tool framework should be structured around
>> them, but that it continues to use coroutines, and we make a coroutine
>> library that is implemented using threads... :P

___
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] [PATCH] Fix MacOS coroutine segfault

[Torsten Hüter]

Hi Chris,

 

please read the mail archive (Jan 2016), I've already tried this and experimented with different coroutine implementations.

Of course a variant based on pthreads too. 

 

The major showstopper was, that's not recommended to use threads for GUI work, please read:

http://docs.wxwidgets.org/3.1/overview_thread.html

 

"[..] When writing a multi-threaded application, it is strongly recommended that no secondary threads call GUI functions. [..]"

 

This would be very restrictive and can't be guaranteed.

 

If you're still interested, I could upload this implementation on launchpad again. I've stopped working on this, because Tom proposed his libcontext and with the bugfixes it was working so far well on Windows.

 

--

 

In my opinion I'd drop coroutines entirely - they are nice if they're a build-in language concept (like Modula-2 coroutines), but C++ has not yet the best support for that.

An alternative are simple FSMs, sure that makes the code a bit bulkier, but would work on every machine without having to maintain assembler code.  The disadvantage is the work that you have to invest there (I have not much time anymore to develop KiCad code).

 

Thanks,

Torsten

 

My point is that threading could be used to implement a *drop-in
replacement*...not that the tool framework should be structured around
them, but that it continues to use coroutines, and we make a coroutine
library that is implemented using threads... :P
 




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

[Torsten Hüter]

Hi Orson,

 

the usecase for me is information reduction; sometimes you can loose the overview when too much at once is displayed.

 

For instance if you want to optimize only the placement of a component group, such as a DC-DC converter, the ratnest of other

components is uninteresting and could be blended out. Also it would be great to hide nets like GND where often a groundplane is used. 

 

In summary:

 

* Local ratsnest for a group or selection of components (the old feature is a special case for 1 component)

* Filter for certain nets like GND

 

Thanks,

Torsten

 

Do you use it? If so, what are your use cases? Do you think it would be
better to control ratsnest visiblity per net, instead of per module?
 




___
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] pcbnew - enable editing of associated net for tracks

[Torsten Hüter]

Hi Strontium,

 

I've just checked that, my latest design uses 1252 stitch vias (medium complexity board, 4 layers). I'm a professional KiCad user (I'm not using KiCad for private projects) and I've given our employees the same hint. We have done of course some RF designs as well. You can move the stitch vias around just like any component.

Also I like that I can control some pad properties like the mask opening.

 

Thanks,

Torsten

 



 



Hello Torsten,

I can clearly understand why you went down this road.

The patch I proposed handles all kinds of vias, blind, buried and through.  And doesn’t require a special component.  The problem I had with the "special component" which I did try, possibly after reading one of your posts, is you either have tons of them matching on your Schematic, OR you have tons of manually placed components with no schematic representation.  Neither of which feels like a great solution to me, I dont consider a via as a Component, regardless of if its stitching or not. 

And lets put the problem into perspective for people who havent used stitching vias, when I say a "ton" of vias, I mean potentially hundreds of them in a very small area.  Its not just one or two.  RF Designs require them at small (tiny) intervals down the edges of fills as guards and regularly placed throughout your fill zones to reduce capacitance between the gnd layers.  Its a HUGE problem for people who need to use them, not just some minor annoyance.  And then you do something like move a resistor, and suddenly your gnd layer reflows around it, well now you have to restitch that new area.  Its a whole lot easier to just move existing vias around.

Stront
 






___
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] pcbnew - enable editing of associated net for tracks

[Torsten Hüter]

Hi Jean-Pierre,

 

I have done several designs with KiCad and stitch vias. The simplest way for me is to create a module with a single through hole pad.

I've even written a python script to automate the placement of these stitch vias (see the mailing list archive). That was never a big problem and works well with the stable KiCad version, no issues with zone filling or net calculations.

 

I'm guessing that Altium PCB using a special primitive for stitch vias as well.

See http://techdocs.altium.com/display/ADOH/Via+Stitching

 

Only blind vias or burried vias are not possible when using a single pad module; Altium uses the start and end layer as attribute for these purposes.

 

--

 

So maybe having free pads with similar attributes - like Altium is using - is here an alternative solution. Also for mounting holes as well (currently you need to create a module for them).

 

Thanks,

Torsten

 



When this entity is defined, netnames will be no more a problem.

So: first, define what is this entity (The best choice is not trivial for me, and deserves to think
about it), how vias are linked to (or owned by) this entity, how they are taken in account by DRC
and zone filling algorithms, and only after see if net names issues still exist.




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

[Torsten Hüter]

Hi Tom & Michael,

 

I'm using the scripting interface quite often and had never that much trouble with it.
The currently missing std::unique_ptr is not an argument, it is still possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig

 

I'm quite sure that in the future almost any C++ 11 features will be supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is exactly the downside.

You have to write wrappers yourself, while with swig you're simply including headers in the *.i files.

 

--

 

About the pythonish API:

Although this sounds good, I'm sceptical - simply because the very limited ressources of the KiCad developers,
something like this has to be regularly maintained. This means documentation too, both C++ and Python.

 

As Miguel has written, there is already some work by Piers Titus van der Torren, see
https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py

 

I've not used that, because I've found it easy enough to work with the swigged functions.
Even when internals are refactored, in most cases I've found it easy to adapt my scripts, this is only an issue between

the releases - even with an abstraction layer you don't know if something has to be changed.

 

Python helper functions would be nice, but I'd still like to have full access to as much as possible PCBNEW methods.

 

--

 

In my opinion the work should be invested elsewhere - for instance a launcher for python scripts is missing.
Sure there is a console, but ideally I'd like to press a button, a keystroke or similar to launch my script.

Also several functions are not yet wrapped, like the P router or the tool framework (working with selections etc.).

 

Thanks,
Torsten


 



> when activating python bindings on my msvc build with a few refactor
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.
>
> With this message I want to ask what is the common view whether it is
> okay to have SWIG thumbscrew the project's source code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.
> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.

Hi Michael,

It may sound controversial, but I'd say using SWIG is a bad idea: we
expose for the people the internal APIs of pcbnew that we intend to
refactor in the near future. Any change to the BOARD storage model means
a change to the scripting API. IMHO we should have a more pythonish API
that hides all C++ stuff from the python side completely and is
independent from the changes in pcbnew's core.

Cheers,
Tom
 




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

[Torsten Hüter]

Hi Orson,

 

thanks for your nice work. I remember that we have discussed about this subject a few years ago - in general I think it's an advantage to

have an alternative for the stroke font. Not for performance, but for the visual quality.

 

I'd call it rather "outline font" instead of bitmap font, because that's more general - see also 

https://en.wikipedia.org/wiki/Computer_font#OUTLINE

Of course you're using a texture for the font atlas, but the origin was a outline (or vector-) font.

 

For a higher quality at small sizes you need also a font atlas with different detail levels. I did some research back then and

found freetype-gl the best libary for these purposes.

 

https://github.com/rougier/freetype-gl

 

Perhaps you can reuse some code from them, for instance the atlas creation or the shaders.

 

Thanks,

Torsten

 

 

I have just enabled regular OpenGL mipmapping, but I do not see a
significant difference. I consider the mentioned text (net name on pad
1, C2) to be just too small to make it readable. If you compare the
original font and legacy view, they have the same problem and I am not
sure we can do much about it.

Regards,
Orson
 




___
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] Python functionality on Windows

[Torsten Hüter]

Hi Wayne,
 
this is of course true, but seems to be a misunderstanding - he needs 
pythonw.exe but not a python variant that is build with MSVC.
And this executable is also provided by MSYS2, just look in the folder 
msys64\mingw64\bin for instance (python2w.exe).
The difference is explained here: https://docs.python.org/2/using/windows.html
 
All other libraries that he needs are there as well (python2-pip, wxPython 
etc.). I've shortly tried to install odfpy with pip on MSYS2 and that was 
working well. So that's perhaps mainly an issue for the Windows package 
maintainers.
 
In my opinion - ideally a concept should be written, which Python libraries 
should be included / what should be wrapped by SWIG/Python.
 
Thanks,
Torsten
 

Konstantin,

I have no interest in using the native windows Python because the amount
of effort to implement this would not be trivial. We would have to
completely overhaul the build system for wxPython and the kicad python
scripting on windows builds to compile an link against the the native
system Python libraries which are built with MSVC. I don't know if you
have ever attempted to do this but I have and it's a nightmare to build
native Python libraries with the GNU tool chain on Windows. I'm not
saying that if someone provided a complete native python build solution
that didn't break the msys2/mingw builds that I wouldn't accept it but
I'm not going to work on it and I would rather the kicad developers work
on more pressing matters. If you want an integrated Python solution,
try installing msys2/mingw32 (or mingw64) and build and install kicad
from source. This way you have a full python implementation along with
pip and setuptool support. This is what I use and it works almost as
well as the native window Python solution.

Cheers,

Wayne
 

___
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] [RFC PATCH] No more boost::context

[Torsten Hüter]

Hi Wayne,

for a short term solution also an older Boost version can be used for Windows - 
or Tom's patch - it's at least not a blocker. 
I'm guessing Tom could do more productive stuff :)

For the long term solution it's of course possible to drop the coroutines 
completely and use the well known event-driven finite-state machines 
(https://en.wikipedia.org/wiki/Event-driven_finite-state_machine) - I think 
that's what you're meaning with the second suggestion. 

I can do this job, because I've implemented a lot of them in various languages 
- but this needs more time and I'd have to touch more files. The tool framework 
uses already an event system and most tools with coroutines look to me 
simplistic (they have an init part, an event loop and some finishing 
instructions).
Makes of course only sense, if we have an agreement, would an example be 
helpful?

Thanks,
Torsten 

>> I've been following this thread for a few days and honestly I'm not
>> excited about anything proposed thus far. Tom's latest patch solves the
>> immediate problem of the MinGW64 build issues but creates build on other
>> platforms that Boost supports (although I don't know how well they are
>> supported). We would also be responsible for maintaining the library
>> forever which goes against the whole point of using a library like
>> boost. It will also completely kill MSVC support for those devs who are
>> doing their own thing. Not that that is an issue but we would be
>> throwing them completely under a bus because we don't allow msvc
>> specific code in kicad.
>> 
>> I know a lot of effort has been put forth and that is not lost on me but
>> I'm not sure anything presented thus far is a viable long term solution
>> for the project. I'm not rejecting it completely it's just not as
>> elegant of a solution as I was hoping for. It seems like a lot of work
>> to fix the one platform where boost context doesn't work. What I would
>> like to see happen is one of two things.
>> 
>> 1) Fix the boost context library 64 bit windows gnu assembly files so
>> that it works and create a patch which can be sent upstream to boost and
>> the msys2 project. The 32 bit windows gas file version works fine as do
>> the linux and osx versions. I'm assuming the other supported boost
>> platforms work as well (arm, mips?, etc.). Since version 1.60 boost is
>> supply gas files for windows builds so it appears they have changed
>> their mind about this. I'm guessing they would be more receptive to
>> patches now that they are providing the gas files for windows builds. I
>> know the msys2 devs are more than happy to apply patches that fix known
>> bugs so that would solve our short term problem.
>> 
>> or
>> 
>> 2) Dump the context switching design and fall back to a message based
>> approach which is more in line with how most event base GUI libraries
>> are designed.

___
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] [RFC PATCH] No more boost::context

[Torsten Hüter]

Hi,
 
Chris:
>> I really think that if we're going to have to support this, it should be
>> something conceptually simpler, like an emulation of coroutines using a
>> set of threads and locks.

I've tried that, but there are side effects with 3rd party libraries 
(wxWidgets, OpenGL),
so that is not a solution in my opinion. I found with my research, that no 
convincing 
C/C++ context switching library is existing, when it should work on all major 
platforms and with
the constraint that the tool code shouldn't be modified.

So I also think using assembler in one header is not the ideal but a very good 
solution,
it addresses the two most important goals (a) Bugfix for Windows/Msys2 and (b) 
removes the
dependency on boost::context. 

Tom:
Thank you very much for this patch.

I've tried it shortly with my test, it runs so far well (up to 500 coroutines 
on my system). There are some
minor things (compiler warnings, missing doxygen comments, open fixme comments) 
- I can work on that if you like.

Thanks,
Torsten

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

[Torsten Hüter]

Hi,
 
Lorenzo:
 
Sorry, perhaps I've expressed it not correctly in my latest mail, I've just 
written down my subjective impressions, while working on the code, that are 
mostly rhetoric questions.
 
>> Stackless coroutines:
>> -
>>
>> * Relative easy to handle, because based on switch()/case().
>> * Safer, a wrong state causes only the exit of the coroutine but not a crash.
>> * Simple implementation
>>Simple?!? Well, maybe implementing but maintaining is another thing...
 
I don't understand this comment. Maintaining of this code is easier, because it 
depends only on the C++ standard library, works on every platform - as long as 
the language specification is not changed. If you mean the functions itself, 
yes - more work but still not very hard to maintain - as long as you're knowing 
the restrictions of this approach.
 
>>In my experience once you do the stack initialization correctly the
>>setjmp/longjmp is the 'best' coroutine you can do; the non-portable code
>>is relegated to the coroutine creation code so it's easily locked away
>>in some untouchable source file :P
>>
>>OTOH I never did that on Win32/64 so maybe it's totally undependable to work 
>>:D
>>Isn't there some MSDN article on doing that?
 
But this is the whole point :) - an robust implementation that works on every 
platform, with minimal side effects and ideally easy to maintain, dropping the 
dependency of the Boost library. I've not the impression that 
setjmp()/longjmp() is the easiest/best solution - please also read the first 
mail about this subject. In the "Protothreads" link you can find also a 
discussion about setjmp()/longjmp().
 
--
 
There are multiple ways to solve these issues and there is no requirement to 
use coroutines at all. They are just used by the tool framework code to avoid 
writing explicit state machines, also the coroutines itself manage there the 
events. So the most radical way would be to completely drop coroutines. I've 
shown with my examples some alternatives.
 
Thanks,
Torsten

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

[Torsten Hüter]

Hi Tom,
 
thanks for your point of view - I'm guessing I've missed that you're working 
already on your variant of boost::context. This is of course a feasible way. 
I'm not the biggest fan of that either, because the (low level) assembler code 
has to be maintained, tested on all platforms, but as long as you can guarantee 
that it works always, it should be good.
 
I've reviewed also the tool code and I've found there not such a huge demand to 
have coroutines, they're "nice to have".
 
--
 
I've used protothreads for some embedded projects, you're right they look 
"uglier" and are sometimes a bit tricky - but easier than state machines to 
write. The Contiki OS is based on them. The comment about the stability was 
related to the implementation of the coroutine itself and is a *subjective 
impression*, it's of course true that it can't prevent a segfault somewhere 
else.
 
--
 
I can of course test your code, I'll use the "stress test" for that :):)
 
Thanks,
Torsten
 

Many thanks for your work. I'm not particularly thrilled about stackless
coroutines for the reasons below:
- They would require a major rewrite of the tool code. If we were to
rewrite it, I'd rather drop coroutines completely.
- Performance is not an issue. The tools just handle UI events.
protothreads library was invented for asynchronous I/O, where
performance is critical. In Kicad, coroutines overhead is minimal.
- They are based on macros, which not only means strange-looking (not to
say ugly) code, but is also hard to debug.
- I can't agree that if something goes wrong, the stackless coroutine
will just exit, but a stackful one will crash. If there's a segfault,
you'll get a crash independently of the coroutine implementation.

Back to the original issue: Boost::context stopped working on MSYS2. The
reason is Boost developers don't want to use GNU assembler on Windows,
and the GNU asm port of the context switching functions is not the same
as the MASM one (since the authors have changed the context ABI at some
point). We shouldn't play cat and mouse with Boost devs by maintaining
MSYS patches that won't get accepted into official Boost tree.

I've been working recently on a library [1] derived from Boost::context,
but which can be easily added to any C++ project, as it consists only of
2 files (.h and .cpp), just like ClipperLib, which we successfully used
for processing polygons.

Libcontext contains all Boost::context switching functions converted to
inline assembly, with compiler and ABI detection. So far,
it has been tested on: i386/x86_64 Linux, Win32/Win64 (GCC) and OSX
(both 32 and 64-bit) - so all the platforms Kicad runs on are already
supported (I'll also enable ARM support - as soon as I have a working
test program a raspi). I think this should be sufficient for the
foreseeable future.

Best,
Tom

[1] https://github.com/twlostow/libcontext

 

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

[Torsten Hüter]

Hi Tom,

I've uploaded now a few different implementations on my personal branch:

https://code.launchpad.net/~torstenhtr/+junk/coroutines

I've tried, as I've written in my first mail, Windows Fibers and Pthreads. I've 
implemented a "stress test" to compare the implementations and also "stackless" 
coroutines. 

My impressions are so far:

Stackful coroutines:


* It's very tricky to get stackful implementations to run stable. Any small 
fault results in a crash or deadlock.

* The most critical part is stack handling. For Windows Fibers / Pthreads the 
library does the job. There are also 
some hacks to get Setjmp()/Longjmp() working with multiple stacks, as 
Jean-Pauls link has shown, I've tried it but that was crashing 
(Setjmp()/Longjmp() seems to be broken too on MinGW64).

* Side effects / show stoppers: It's not recommened to use threads for the 
wxWidgets GUI, OpenGL requires a context switch per thread.

* As already known, Boost::Context is broken on Msys2 - makes it sense that 
such a low level library has to be maintained by KiCad developers (?)

* Is context switching always safe (side effects with 3rd party libraries / 
Python etc.)? 

Stackless coroutines:
-

* Relative easy to handle, because based on switch()/case().
* Safer, a wrong state causes only the exit of the coroutine but not a crash.
* Simple implementation

* More verbose, you need to use macros like CR_BEGIN(..) CR_END(..)
* Syntax restrictions
* Special care of local variables is required

You can find a paper about this approach here:
http://dunkels.com/adam/dunkels06protothreads.pdf

I've used your coroutine class and have adapted it to be similar to 
protothreads. The actual state is stored in the instance of this class. Compare 
also the "stress test" example. All implementations have the same output as 
result of this test program.

The stackless implementation is my favorite. There are less side effects, based 
on the C++ standard library and the coroutines consume less resources. This 
outweights in my opinion the disadvantage, that the coroutine functions are 
more time-consuming to write.

Thanks,
Torsten

>> void my_tool()
>> {
>> wait(event1);
>> do_something();
>> wait(event2);
>> do_something_else();
>> }
>> 
>> All of the stack switching "magic" is hidden. You can find an example in
>> include/tool/examples/coroutine_example.cpp
>> 
>> 
>> Concerning boost::context, I see two options:
>> - get rid of the coroutines (i.e. rewrite all event loops/calls in the
>> GAL tools). Painful but doable, I would prefer to spend my time doing
>> something more productive (e.g. porting the remaining tools to GAL).
>> - turn boost::context into a single .cpp file library that one can
>> just add to the project and forget about it (think of ClipperLib as an
>> example).
>> 
>> As a side comment, I'm not surprised that boost devs insist on using
>> MASM under Windows - the syntax of the GNU assembler on x86/x86_64
>> platforms is just disgusting.
>> 
>> Tom

___
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

[Kicad-developers] wxDC GAL (Re: Grid in GAL canvas)

[Torsten Hüter]

Hi,
 
 Are we even still going to have legacy pcbnew at the next release?
 What's the schedule for fully deprecating it?
>>
>>It will not be deprecated until we have one for one feature parity
>>between the canvases and we can get by without it on all supported
>>platforms. AFAIK, Tom is working on a wxDC gal implementation which
>>should eliminate the second part. If this happens before the next
>>release, then there is no reason to continue to support the legacy canvas.
 
Is this a new decision? I thought that wxDC is not that much interesting, 
because it uses deprecated functions and is problematic on some platforms.

I did an wxDC implementation, this was my last work on the GAL and then Orson 
continued it and he should know this implementation.

You can find the code here:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/kicad-gal/files/head:/gal/wxdc/

Funny that this is almost 4 years old :)

That could be helpful for Tom.

Thanks,
Torsten

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

[Torsten Hüter]

Hi Tom,

 

I'm working on some alternatives, that I'm getting a better impression. I'll upload the example code this weekend, then we can discuss. One alternative are for instance stackless coroutines. I've also checked how you're using them in your code and have some ideas to modify that.

 

Thanks,

Torsten

 



@Edwin: Coroutines are not a replacement for threads. They *aren't*
there for improving performance, just to simplify event handling in
complex state machines. For example:

case 1) - without coroutines - we need to code a (possibly large) FSM
by hand. This doesn't scale well in terms of code complexity,
especially if there are nested state machines .

void handle_event(event)
{
switch(state)
{
case state1:
if (event == event1) {
do something();
state = state2;
}
case state2:
if (event == event2) {
do_something();
state = state3;
}
case state3:
/// and so on
}
}

case 2) - with coroutines - we can execute our FSM in sequential code
and receive events using a wait() function, which yields the current
coroutine (i.e. transfers the control to the master event loop in case
of pcbnew) and wakes up the execution of the tool that called wait()
when a matching event arrives:

void my_tool()
{
wait(event1);
do_something();
wait(event2);
do_something_else();
}

All of the stack switching "magic" is hidden. You can find an example in
include/tool/examples/coroutine_example.cpp


Concerning boost::context, I see two options:
- get rid of the coroutines (i.e. rewrite all event loops/calls in the
GAL tools). Painful but doable, I would prefer to spend my time doing
something more productive (e.g. porting the remaining tools to GAL).
- turn boost::context into a single .cpp file library that one can
just add to the project and forget about it (think of ClipperLib as an
example).

As a side comment, I'm not surprised that boost devs insist on using
MASM under Windows - the syntax of the GNU assembler on x86/x86_64
platforms is just disgusting.

Tom


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

[Torsten Hüter]

Hi Wayne,

this is of course right, but the idea would be to emulate cooperative 
multitasking with threads. This is done by synchronizing the threads with 
condition variables and mutexes. The principle can be found in the articles [1] 
or [2].

The idea is good, BUT after further research I'd say that there are two show 
stoppers:

(a) it's not recommended to use secondary threads to call GUI functions

http://docs.wxwidgets.org/trunk/overview_thread.html

(b) the OpenGL context is only valid for the current thread, it's required to 
change the context for every thread

https://www.opengl.org/wiki/OpenGL_and_multithreading

Ideally rendering and gui handling should happen only in the main thread; but 
that would be to restrictive for our purposes. 

This makes threads in my opinion unattractive for coroutines.

--

Yes, state machines or stackless coroutines are possible too, but then the 
tool-framework code has to be changed a lot. I'll evaluate the other options 
first. Setjmp/longjmp could work also, but here is stack handling the major 
issue.

Thanks,
Torsten


[1] Coroutines in C/C++: beyond Duff's Device, 
http://sjansen.blogspot.de/2008/04/coroutines-in-cc-beyond-duffs-device.html 
[2] Cross-Platform Coroutines in C++, 
http://www.drdobbs.com/cpp/cross-platform-coroutines-in-c/184404529 
 

> Torsten,
>
> I've been thinking about your proposed changes and I'm not sure I'm
> comfortable making KiCad multi-threaded using a library such as pthreads
> or any other threading implementation. Context switching (cooperative
> multi-tasking) is bad enough but at least everything is happening in the
> same thread so no locking is required. Pre-emptive multi-tasking is
> much more difficult to deal with. Access to everything being touched by
> multiple threads has to be protected with locks which can make for some
> ugly code and debugging threaded applications can be difficult. What
> about using a state machine or some clever way to use events?

Wayne

On 1/6/2016 10:48 AM, Tomasz Wlostowski wrote:
> On 04.01.2016 15:07, Mark Roszko wrote:
>>> My offer would be to test an alternative implementation, to drop another 
>>> Boost dependency and build upon a standard library foundation.
>>> pthreads is not standard library <.<
>>
>
> Hi Mark & Torsten,
>
> Feel free to test any implementation you like (personally I would try
> with setjmp() first). I don't have much time to work on this issue (I'm
> busy these days adding a reasonably fast wxDC support to the GAL canvas...).
>
> Cheers,
> Tom
>

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

[Torsten Hüter]

Hi Jean-Pierre,

this is a good argument, if Boost does not have to be compiled anymore. I'll 
see what I can do and give feedback, at least an alternative was then tried.

@Mark:
Pthreads are standardised, because they're part of the POSIX family of 
standards (https://standards.ieee.org/findstds/standard/1003.1-2008.html) 
They're not of course part of the C++ standard library. I'll compare them to 
C++11 threads, but I'd say the implementation would be very similar (that's a 
later topic, KiCad is not yet ready for C++11). First I have to check, if the 
concept works.

Thanks,
Torsten

>AFAIK, boost libraries are mainly used in Avhttp and coroutines.
>Bye Avhttp (thanks, Mark).
>boost::coroutine still use them, and it was always a nightmare, since
>the beginning.

>So, if an alternative implementation to boost::context exists, I will be
>*very* happy.

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

[Torsten Hüter]

Mark,

 

You're right Pthreads should eventually work on Windows/MinGW too.

 

I don't know if their policy has changed, but the official documentation lists still MASM as requirement for Windows. I did no further research about the reasons.

 

Please read the (old) statement of our project leader here:

 

http://mingw-users.1079350.n2.nabble.com/Boost-Context-MinGW-EXPORT-keyword-td7582532.html

 

Quote from Wayne:

 

"[..] Good luck!  The KiCad project had the same issue.  We even submitted our
patch but they refused it.  The answer was always the same.  Use MASM
with no reasonable explanation as to why the gnu assembler was
unacceptable.

[..]

I'm beginning to regret using Boost in KiCad.

[..]"

 

I don't know if this opinion is still valid.

 

--

 

My offer would be to test an alternative implementation, to drop another Boost dependency and build upon a standard library foundation.

 

Thanks,

Torsten

 

 

Gesendet: Montag, 04. Januar 2016 um 06:07 Uhr
Von: "Mark Roszko" <mark.ros...@gmail.com>
An: "Torsten Hüter" <torsten...@gmx.de>
Cc: "KiCad Mailinglist" <kicad-developers@lists.launchpad.net>
Betreff: Re: [Kicad-developers] KiCad Coroutines

>Summary: Fibers (Windows) and Pthreads (all POSIX-compliant operating systems) seem to be the most promising alternatives for context switching

Since msys2 uses mingw, it used to have a pthreads implementation when
I used it years ago. Not sure if the latest has a package for it.





>I did some research and this thing seems to cause constantly trouble, because some assembly "hackery" is required and only MASM is officially supported

Not true at all.
MINGW64 is supported, someone just broke it in boost context
1.59 on our use case.
Works fine in 1.57. The problem is finding
someone brave enough to debug assembly <.<




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

[Torsten Hüter]

Hi Wayne,
 
> What version(s) of Windows support fibers? I didn't see any indication
> on the links above.
 
See this link:

https://support.microsoft.com/en-us/kb/128531

Fibers were added to the WIN32-API with the Service Pack 5 for Windows NT 3.51.

Quote from the above link:

"[..] 
Service Pack 5 contains 3 additions to the Win32 API:

Fibers
--
A fiber is a lightweight thread that is manually scheduled.  Fibers do not
provide advantages over a well-designed multithreaded application.
However, fibers can make it easier to port applications that were designed
to schedule their own threads.
[..]"

So any actual desktop Windows version (XP and later) should support these 
functions.

I've tried the provided example from Microsoft on MSYS2 / Windows 10 (64 Bit) 
and it was running well.

> I don't have any strong opinions either way. However, I did not write
> the code. Tom may have a stronger opinion about this than I do since he
> wrote the code. Personally I'm not the biggest fan of coroutines. I
> know the make the code easier to read but I'm not convinced they are
> necessary in an event driven design.

This is true, but as you have written - the code is easier to read. Another 
alternatives would be to use state machines (with switch/case etc.) or 
stackless coroutines (Protothreads are an example, 
https://en.wikipedia.org/wiki/Protothreads). In Python are Coroutines a 
language concept, see also https://wiki.python.org/moin/Generators .

An example use case would be a long running computation, with a coroutine you 
could yield to the main thread and update a status bar or similar. 
 
Thanks,
Torsten

___
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

[Kicad-developers] KiCad Coroutines

[Torsten Hüter]

Hi Wayne,

I've recently tried to compile KiCad on Windows (64Bit) and I've noticed that 
PcbNew is crashing at context switching - but I had no problems early 2015 with 
that. I've seen that you have already filed a bug report [1]. I did some 
research and this thing seems to cause constantly trouble, because some 
assembly "hackery" is required and only MASM is officially supported [2].

Rather than trying to fix Boost, makes it sense to consider an alternative way 
or library for the same purpose?

I've found so far these alternatives as back-end for "stackful" coroutines:

(1) Fibers on Windows

https://msdn.microsoft.com/de-de/library/windows/desktop/ms682661%28v=vs.85%29.aspx
https://en.wikipedia.org/wiki/Fiber_%28computer_science%29

This seems to be the safest alternative for Windows, because Fibers are fully 
supported by the OS and are thread-safe.

(2) POSIX ucontext.h - setcontext, getcontext, makecontext and swapcontext

Very similar compared to Windows Fibers, but deprecated since POSIX.1-2008, 
quote from https://en.wikipedia.org/wiki/Setcontext :

"[..] POSIX.1-2004 obsoleted these functions, and in POSIX.1-2008 they were 
removed [..]"

It is still possible to use these functions on Linux, but these are not 
future-proof and there are no replacement functions.

An interesting talk about this topic can be found here:
http://stackoverflow.com/questions/4298986/is-there-something-to-replace-the-ucontext-h-functions

(3) POSIX Threads

https://computing.llnl.gov/tutorials/pthreads/

It is possible to emulate Fibers with pthreads, here is a good article about 
this subject:

http://sjansen.blogspot.de/2008/04/coroutines-in-cc-beyond-duffs-device.html

The downside is the larger overhead, but this shouldn't be a big issue for 
KiCad, I'm sure that not more than a few coroutines are created for the tool 
framework. Quote from the above article:

"[..] As an interesting sidenote, I'm not sure how debuggers such as gdb and 
valgrind handle applications that switch their stacks. It might be that using 
threads actually makes things easier to debug in this case (as the tools 
already have support for threads). [..]"

Pthreads offer also some mechanisms for stack overflow detection.

(4) setjmp / longjmp

https://en.wikipedia.org/wiki/Setjmp.h

Context switching is also possible using these functions and some libraries 
like "picoro" use that for Coroutines. However stack handling is difficult, 
especially stack overflow protection is not easy to implement.

http://dotat.at/cgi/git/picoro.git

--

Summary: Fibers (Windows) and Pthreads (all POSIX-compliant operating systems) 
seem to be the most promising alternatives for context switching. This way it 
would be possible to get rid of the Boost.Context dependency while using 
standard libraries.

What do you think, should I invest more time into this topic (refactoring of 
coroutine.h using these alternatives and write a stress test application)?

Thanks, 
Torsten

[1] KiCad issues with Boost 1.59, bug report, 
https://github.com/Alexpux/MINGW-packages/issues/836
[2] Boost context requirements, 
http://www.boost.org/doc/libs/1_60_0/libs/context/doc/html/context/requirements.html

___
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] PATCH: To facilitate easier Via Curtain/Filling

[Torsten Hüter]

Hi Steven,

 

my question are the side-effects of this patch, do you have checked all possible cases?

 

For instance if I'm retaining the nets, what happens if I've forgotten to erase tracks or vias in my design, would that create copper islands?

 

How can I discriminate between the intentional and nonintentional placement of free vias?

 

--

 

I've seen that you have startet your own python script for stitching. Please have a look at my code, I'd really like that we don't have too many implementations of the same feature (Ben has also announced another version). I'm using single pad components for the vias, but should be relative easy to adapt.

 

http://bazaar.launchpad.net/~torstenhtr/kicad/kicad_via_stitching/files/head:/pcbnew/scripting/tools/viastitching/

 

--

 

I like the idea of a special via class. I could imagine that the pcbnew/class_pad.h could be extended or a new class is derived from that. The reason is, that DRC and zone calculations work already well for it and a free via is for manufacturing the same as having a through hole pad. Just a start/stop layer needs to be added for burried/blind vias.

 

Thanks,

Torsten

 

Gesendet: Mittwoch, 16. Dezember 2015 um 02:49 Uhr
Von: Strontium 
An: kicad-developers@lists.launchpad.net
Betreff: Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

Hi Wayne, Everyone,

This is the process now. If you have a fill zone, and you start to lay
a track within it, KiCad will assign that track/via to the net of the
zone of the layer you are on. AND, as a board Designer, that's exactly
what you would expect. But then, following this design process, you
press the DRC button.

All of a sudden the Track/Via you just laid in the fill zone, and which
KiCad gave you a Net for, loses its net assignment, and becomes
"unconnected". Now the fill area flows around it, avoiding it by the
distance of the fill clearance.

Its a case of Kicad Giving with one hand (the net from the fill) and
then taking away with the other (net reassignment). All my patch does,
is align these so that once the net has been given by KiCad, it wont
needlessly be taken away. It might be reassigned because of a pad
connection, but it wont otherwise be "lost".

This "misalignment" between the DRC Net reassignment and the laying
code, causes multiple problems, on real boards:

1. If you do this, and it doesn't cause a DRC. You may not notice it,
because a "unconnected" track/via is not a DRC error or warning. So the
design intent of your board is thwarted, you may have fill planes now
disconnected at certain points and not enough vias connecting them,
disconnected islands of fill, etc. This board goes to production, and
is actually flawed. All because the designer ran "DRC" check before
sending it AND there is nothing obvious to highlight the change KiCad
made to the board, to the designer. The only way to find them is a
detailed visual inspection, after every DRC Check.

2. To work around point 1, you need need to criss cross your board with
interconnecting tracks from pads with that net to the vias, so they keep
their assignment. This causes a problem that if you now edit, you have
all of these tracks, which you are only using to keep nets assigned to
your vias, making it very difficult to edit/relay, etc. In many cases
the nearest pad may be on the other side of the board, requiring you to
manually lay a track to it.

OR Place a single pad component which simulates a VIA, but then you cant
use microvias, and you need to now manage the "extra" components.

3. Changing vias/tracks to "unassigned" may introduce "DRC" errors on
the board that weren't there before the DRC pass. So, in effect, KiCad
is actually generating these DRC errors with the DRC check Pass, they
didn’t exist BEFORE the DRC check, but do after. Which, as a board
designer, is surprising and off-putting.

Basically, and at its core, this patch makes the net reassignment code
compatible with the code that lets you place a track/via on a fill plane
and pick up its net. Without it, its like KiCad telling you what you
are doing while editing is OK. But then changing its mind later.

And while my patch allows me to much more easily, manually, lay GND vias
for filling, etc, its utility is not limited to "Via Curtains" or "Via
Fills". For example, you may simply want to put a few extra vias
between two VCC planes to share the current load. This patch makes that
easy and consistent.

I can certainly understand the desire not to implement "quick fixes"
that increase "cruftiness", I wouldn't want that either. And while this
patch is small, I don't think this patch increases cruftiness but
actually reduces cruftiness and makes the board design DRC process less
surprising to a board designer and more consistent with the way the
layout tools work.

Steven

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] Library license update.

[Torsten Hüter]

Hi Wayne,

thank you very much for your efforts. I'm guessing that this is not an easy 
topic and takes thus more time. 
Hopefully a good solution can be found this way.

Maybe it makes then sense to announce this change on the KiCad homepage, I 
could also imagine to add a definition of the "audience" - just like on the 
FreeCad homepage. 

Quote from http://www.freecadweb.org/:

"[..] 
Who is FreeCAD for? A couple of user cases:
The home user/hobbyist. 
Got yourself a project you want to build, have built, or 3D printed? Model it 
in FreeCAD. No previous CAD experience required. Our community will help you 
get the hang of it quickly!

The experienced CAD user. 
If you use commercial CAD or BIM modeling software at work, you will find 
similar tools and workflow among the many 
workbenches[http://www.freecadweb.org/wiki/?title=Workbenches] of FreeCAD. 
[..]"

Thanks,
Torsten

>I just wanted to give everyone a heads up that I did not forget about
>our library license issue.  I sent a modified version of the gEDA symbol
>library (GPL font exception) to the FSF for comment on November 20.  I
>received a reply that they are looking at and will get back to me.  I'm
>not sure what is taking so long but as I'm not a lawyer, I would rather
>get some feedback before making it public.  As soon as I hear back from
>the FSF and we have an acceptable license, I will forward the license to
>the library and website devs.  Who knows, if I did a good enough job,
>maybe I can start my second career as lawyer. 

___
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] PATCH: To facilitate easier Via Curtain/Filling

[Torsten Hüter]

Hi Wayne & Jean-Pierre,

 

please consider also my implementation, I've announced this already (April/August 2015) on the mailing list:

 

https://lists.launchpad.net/kicad-developers/msg19584.html

 

Now is the stable release finished and we can talk about this.

 

I'm using there pads for stitching because they offer some advantages. Just like Jean-Pierre has written I need meta-informations (the netname, a time stamp, the RefDes for erasing stitching vias, padstack informations like mask opening etc.).

 

The only unsupported feature is stitching of blind or burried vias, because there is AFAIK no layer concept for pads existing.

 

--

 

Ideally pcbnew would support free vias with meta informations, like Wayne has written.

 

However I could imagine as well, that simply the through hole pad code is used for this purpose and a top level entity (or component) contains these "stitching pads". For blind and burried vias a start and stop layer needs to be added to such pads as well.

 

Such special free vias should be pretty easy to manage by the python script.

 

Thanks,

Torsten

 



Stitching vias must be added, but also removed and edited (size, drill,
net name..) all in once.
Therefore they need a "link" (for instance a time stamp) to be removed

A good via placement tool in not "quite trivial", but feasible, obvioulsy.

The first work is not write code, but define how vias stitching are
managed (are they a group, and/or items inside a parent polygon like a
zone ...)

 


>
> I would rather we do a complete free via
>> implementation and not introduce a stop gap measure into Pcbnew. We've
>> discussed the idea of incorporating free vias many times in the past.
>> Since we are in a new development cycle, now is the time to revisit
>> this. At a minimum this should include the following:
>>
>> 1) Board file format support for free vias. Do we need to add any new
>> tokens to the board file format and where do we want to put the free
>> vias in the board file? We need to define what capabilities our free
>> vias require and plan accordingly. This will be a file format change so
>> we need to consider this carefully.
>>
>> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
>> adding and editing free vias. Our array tool could come in handy here.
>>
>> 3) Update DRC to handle free vias.
>>
>> 4) Verify support code still works. I'm guessing we wont need to change
>> our plotting, printing, and/or export code since we already support
>> through hole, micro, and blind/buried vias (are there any other types of
>> vias?).
>>
>> Please consider this instead of quick fixes. This is one of the reasons
>> the KiCad code base is so crufty. We need to start doing a better job
>> of looking at the big picture.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>>> On 14.12.2015 14:40, Strontium wrote:
 Hi Thomas,

 I considered this, but tracking zones is non trivial.

 For example, imagine the stackup:

 GND
 VCC
 GND
 VCC

 A Through Via, from top to bottom could be connected validly connected
 to either GND or VCC.

 Once the net is removed from the via by the reassignment pass, there is
 no longer any information left to tell kicad which pair of zones was
 connected by the via.
>>>
>>> Indeed, in case of such a conflict retaining the via's net is IMHO the
>>> only good solution.
>>>

 The approach I suggest will fix this problem, because it just wont
 change the net for those vias. It wont consider if there is a zone or
 not, it just says "hey, you gave it the GND net, so i will leave it as
 GND."
>>>
>>> It also seems Altium is managing via's nets this way. I would vote for
>>> merging the patch.
>>>
>>> Cheers,
>>> Tom
>>>


 On 14/12/15 21:21, Tomasz Wlostowski wrote:
> On 12.12.2015 02:41, Strontium wrote:
>> This change should not break or modify any current behaviour, EXCEPT to
>> retain the nets of tracks/vias which Kicad is otherwise incapable of
>> determining automatically.
> Hi Steven,
>
> Thanks for the patch, it also (partially) fixes the via stitching issue
> many people have been complaining about. The origin of the problem is
> that the net propagation code does not take zones into account - so a
> via that is not connected to any pad with a chain of tracks is treated
> as disconnected.
>
> Adding zone support in the net calculation code should AFAIK fix this
> for good, but it may also require enhancing the DRC (so that it will
> report every object with no pad connection) and the 'clean tracks'
> tool code.
>
> Regards,
> Tom


--
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help 

Re: [Kicad-developers] Release - licenses and legal issues

[Torsten Hüter]

Hi Wayne,

 

very good news. Maybe it makes sense to add the GPL font exception to the KiCad license too, although the font license

is now CC0 the newstroke-font will be part of the KiCad-binary (and thus GPL3+). You can find a template here:

 

https://www.gnu.org/software/freefont/license.html

 

In general, I could imagine that the same license is used for all KiCad components (GPL3+), that means

software, fonts, libraries - and exception clauses are defined for anything that's embedded into the

user's design. I'm guessing the critical part is then to formulate these clauses correctly, ideally an expert (lawyer?)

should do proofreading.

 

--

 

BTW For ADA Gnat is also the GPL with an exception clause used (so commercial applications with their libraries are possible):

https://en.wikipedia.org/wiki/GNAT_Modified_General_Public_License

 

Thanks,

Torsten

 



Just a quick update on the licensing front. I just committed a change
that included updating the KiCad source from GPL2+ to GPL3+ per the FSF.
I also updated the newstroke font license from CC-BY to CC0 per the
original author. I am waiting to hear back from the geda devs about
using their GPL exception clause for our libraries.

Would one of our website devs please update the KiCad licensing from
GPL2+ to GPL3+. As soon as I get an answer from the geda devs, I will
submit an GPL exception clause for our libraries.
 




___
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] Release - licenses and legal issues

[Torsten Hüter]

Hi Wayne,
 

>> Is there somewhere an overview of the used libraries / 3rd party software 
>> and their licenses? (for instance an list, >LibreOffice table or similar)
>
>No.

Would it be helpful to create a table for the internal documentation? If yes, 
how should the table look like and what kind of format should be used?
 
>> The push and shove router is covered by the GPLv3+. This means the whole 
>> KiCad package has to be released under the terms of >>the GPLv3 license, if 
>> you're including the P
>>
>>However, all of the license files in kicad say 2+.
>>
>> However, the "About../License" tab shows the following text:
>>
>> "The complete KiCad EDA Suite is released under the GNU General Public 
>> License (GPL) version 2 or any later version"
>>
>>I would think this would be adequate but I have not asked the FSF. Do
>>we actually have to do this or is the GPL2+ statement OK.

I'm not a lawyer but would say that it is a one-way road, you can't "downgrade" 
from GPL3+ to GPL2+ and
the whole package has to be distributed under the terms of the GPL3+ license. 
You can find on slashdot.org an interesting discussion about this subject:

http://ask.slashdot.org/story/07/06/16/1818241/gplv2-and-gplv3-coexisting-in-the-same-project

Perhaps it makes sense to ask an (license) expert too.

>Is it directly derived or is it a clean room implementation? It doesn't
>say anywhere that I could see that it is derived from the Hershey font.
>If it's a clean room implementation than we could ask if it can be
>re-licensed to be GPL compatible.

This is indeed a very good question. I've seen in the 
helpers/tools_to_build_newstroke-font/README.txt the following line:
font_draft1.lib - old draft glyph library with the metrics from Hersheys Simplex
So I'm guessing he has extended the Hershey font. Of course it could be that he 
has repainted all chars/symbols. Still then is the problem, that he has 
released the font under the terms of the CC-BY license.

Asking the original author is a very good idea. 

> This would push back the stable release. How do you suggest we package
> the fonts? Packaging them separately is going to be painful.

This is quite true, but only required if the font can't be relicensed to GPL. 
If the GPL is choosen, it would make sense to define a GPL font exception for 
the KiCAD suite - so that the font can be embedded into the user design without 
affecting the design license.

If the author does not agree, it could be necessary to seperate the font from 
the program. The "newstroke" font is contained in a header 
(helpers/tools_to_build_newstroke-font/newstroke_font.h). This is an array of 
strings, the format is relative simple - one way could be a reader, that parses 
this header at runtime - or put the strings into a separate file and parse them 
there.

> I like what the geda folks did. They basically give you permission to
> modify the symbols for use in your designs but enforced the GPL if you
> are going to provide libraries of files derived from the symbols. We
> should make a similar statement about our libraries since they are GPL
> licensed if no one objects.

Sounds like a good plan! 
It would be important to define a policy as well; any contributor has to agree 
with the terms of this license. 
I don't know if that's true for all parts of the library - last time I've seen 
some contributions with a different licenses.

Thanks,
Torsten

___
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

[Kicad-developers] Release - licenses and legal issues

[Torsten Hüter]

Hi Wayne,
 
thanks for the great work, I'm looking forward to the release. I have several 
questions about licenses / legal issues:

Is there somewhere an overview of the used libraries / 3rd party software and 
their licenses? (for instance an list, LibreOffice table or similar)
 
Are all individual (library) licenses compatible with the KiCad license (GPL 
2+)?
 
What kind of restrictions do I have to expect when I'm using KiCad for my 
designs?
 
--
 
I'm asking, because I've seen a few examples which are unclear for me:
 
(1) The GPLv3 is not compatible with the GPLv2
 
Quote from the FSF (http://www.gnu.org/licenses/license-list.en.html):
"Please note that GPLv3 is not compatible with GPLv2 by itself. However, most 
software released under GPLv2 allows you to use the terms of later versions of 
the GPL as well. When this is the case, you can use the code under GPLv3 to 
make the desired combination. To learn more about compatibility between GNU 
licenses, please see our FAQ."

The push and shove router is covered by the GPLv3+. This means the whole KiCad 
package has to be released under the terms of the GPLv3 license, if you're 
including the P 

However, the "About../License" tab shows the following text:

"The complete KiCad EDA Suite is released under the GNU General Public License 
(GPL) version 2 or any later version"
 
(2) License of the embedded stroke font
 
This is a particular problem, because the stroke font is hard coded to the 
KiCad binary. The user has no way to load his own font at run-time.

The font itself is derived from the Hershey font family and the Hershey fonts 
are covered by a special license which includes advertising clauses and is thus 
not compatible with the GPLv2. The author of the font was Vladimir Uryvaev and 
the README.txt (helpers/tools_to_build_newstroke-font) states "Released under 
CC-BY licence". This license is also incompatible with both the Hershey license 
and the GPLv2.

One way to solve this issue could be to write an simple loader for the font, 
this way the font is not part of the program itself and the Hershey font 
license has to be distributed with the KiCad package. And maybe for the distant 
future it makes sense to use a different stroke font like the ISO 3098 font 
from Wikipedia (public domain, 
https://commons.wikimedia.org/wiki/File:ISO3098.svg) or Lorenzo's variant.

You can find the Hershey font license here: 
http://ghostscript.com/doc/current/Hershey.htm

The GPL-license itself is not ideal for a font, because if you're embedding the 
font in a design (schematics etc.) the whole work has to be distributed under 
the terms of the GPL-license.
 
(3) The KiCad library license
 
The used GNU Library General Public License is the predecessor of the GNU 
Lesser General Public License. See also:
http://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html 
 
What was the motivation for selecting this license? 
 
Does this license offer any advantages over the GPL? 
 
Section 5 states:
 
"[..] However, linking a "work that uses the Library" with the Library creates 
an executable that is a derivative of the Library (because it contains portions 
of the Library), rather than a "work that uses the library". The executable is 
therefore covered by this License. Section 6 states terms for distribution of 
such executables. [..]"

Using a library to create a PCB design is quite similar to linking and creating 
a executable, thus any distributed design falls under section 6 - that means 
you need to "[..] permit modification of the work for the customer's own use 
and reverse engineering [..]" and accompany the work "[..] with the complete 
machine-readable "work that uses the Library", as object code and/or source 
code, so that the user can modify the Library and then relink to produce a 
modified executable containing the modified Library". [..]"
 
Basically this is the same challenge like with any GPL-licensed font. The Free 
Software Foundation published 2005 the so-called "GPL font exception " (see 
https://en.wikipedia.org/wiki/GPL_font_exception). The gEDA developers found in 
my opinion a similar and better solution, they have defined a exception clause 
for their library - just like the GPL font exception - so you can use the 
library also for commercial (closed) projects (see 
http://wiki.geda-project.org/geda:license).
 
Thanks,
Torsten

___
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] suggested resolution (and other specs)

[Torsten Hüter]

Hi,

I'd also argue for a lower minimum resolution like 1366x768 or 1024x768 - 
simple because still a lot of mainstream laptops are sold with that.
 
Have a look at the Wikipedia display resolution page:

https://en.wikipedia.org/wiki/Display_resolution

According to the table "Most common display resolutions in May of 2015" you can 
find 
that the HD display (1366x768) is among the largest group of web users: 26,63% !

One way could be to define a minimum resolution but also a recommended 
resolution - such as 1600x900.

Thanks,
Torsten
 

>I would really like to see KiCad work better on 1366x768 screens. This was 
>pretty much the de facto standard laptop >screen resolution until the last 
>year or two.
 
>The laptop I currently use daily is this resolution and I expect to get 
>another few years out of it at least. I realize >it is a fairly small 
>resolution, but it is what I have and I know is still super, super common.
 
>Jon
 

___
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

[Kicad-developers] Via stitching (Python)

[Torsten Hüter]

Hi,

as promised, I've pushed my stitching tool to launchpad, you can find my 
branch here:

http://code.launchpad.net/~torstenhtr/kicad/kicad_via_stitching

if you like to try this tool, get my branch, compile KiCad as usual (with 
scripting), open
the scripting console and use these commands:

import os
os.chdir(stitching tool path)  # The tool can be found under KiCad 
sources/pcbnew/scripting/tools/viastitching
import via_stitching_dialog
via_stitching_dialog.start_dialog()

(Change to the GAL view / select a zone with the selection tool first) 

See also the attached screenshot.

--

It's possible to use this tool from the Python console as well:

import via_stitching

vs = via_stitching.ViaStitching()
vs.stitch_zone() # Stitches a selected zone
vs.stitch_edge() # Stiches the zone edge only

vs.delete_vias() # Deletes the stitch vias, if a zone was selected deletes only 
the vias inside that zone

--

Supported is so far:

* Stitching of zones
* Stitching of zone edges
* Staggered rows
* Randomize of the via position
* Alignment of the vias to the selected grid
* Netclass defaults
* Undo

--

The tool is written in Python and I've tried to avoid to use C++ as much as 
possible 
(just here and there an accessor / small helper). 
I think via stitching is a great application for the Python scripting 
interface, because it's
used mostly at the end of the design process it don't has to be fast - but with 
Python you're
much more flexible, changes require no rebuild of KiCad, it can be used easily 
as plugin etc.

I've used a single pad module for the vias, because this has practical 
advantages - e.g. I can 
store meta-information, the via can be moved just like any other module, no 
change of the file 
format is required, solder mask can be adjusted and no issues with the net 
connectivity so far.

Thanks,
Torsten___
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] Stitching vias

[Torsten Hüter]

Hi Mikk,
 
I hope that I find this or next weekend some time to upload a recent version. I 
need to merge the actual KiCad code and have to do more testing. It's a tool to 
automate the stitching using the scripting window and also with a simple 
dialog, roughly inspired by Altium.
 
Thanks,
Torsten
 

Hi Torsten,
 Yes, i have obviously missed that. I tried to search via in mailing list 
but couldn't find a search button :/
Is it like some add-on tool to editor or some script with command line 
arguments?
Can you share some link or demo?
 
BR,
Mikk

 

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

[Torsten Hüter]

Hi Mikk,
 
perhaps you have missed that; I've written a while ago that I'm working on a 
VIA stitching tool. It's mostly written as KiCad Python script with minimal 
additions to the scripting engine. A first version (as proof of concept) is 
almost ready and I've used it for my latest PCB. I need to do a bit more 
testing until I'll make it public.
The basic idea is to use a single pad component and the PS router for 
collision testing.
 
Bye,
Torsten
 

___
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] on incorrect polygon behavior

[Torsten Hüter]

Hi Tom,

just for reference, you can find a benchmark of various polygon libraries here:

http://rogue-modron.blogspot.de/2011/04/polygon-clipping-wrapper-benchmark.html

It shows as well that Clipper performs better than Boost.Polygon and thus is a 
good selection. And CGAL is well known but slow compared to the alternatives. 
However it makes maybe sense to have a look at Boost.Geometry (not 
Boost.Polygon) - because this library has almost the same performance compared 
to Clipper but is more general; because they use metaprogramming (header-only 
template library). There you can find many useful algorithms and also spatial 
indexes like R-Trees. One advantage that I'd see is that you can adapt directly 
the VECTOR2 class.

http://www.boost.org/doc/libs/1_58_0/libs/geometry/doc/html/index.html

Greetings,
Torsten

 Hi,

 It took me a bit longer than initially anticipated to write the
 fracturing (polygon with holes - single outline conversion) algorithm
 that was missing in Clipper. I managed to generate correct zones and the
 algorithm does not crash on the test cases that were crashing
 Boost.Polygon. My plan is now to:
 - clean SHAPE_POLY_SET code and send the patch asap (perhaps Monday, I'm
 out for the weekend),
 - optimize fracturing, which is taking most of the calculation time. To
 my surprise, Clipper performs calculations faster than BPL,
 - look into possibility of having a single polygon set class, merging
 the functionality of CPolyLine, CPOLYGONS_LIST and all BPL-derived classes,
 - keep fallback BPL zone code which could be switched on in the
 preferences.
 - add an option to dump zone geometry (outline, holes, thermals, full
 poly) to a text file while refilling zones.

 The last two options are temporary - to gather confidence in Clipper,
 compare the performance of BPL/Clipper and, in case of trouble, obtain
 test cases for both backends.

 Cheers,
 Tom


___
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] GAL questions (with regarding 3d-viewer)

[Torsten Hüter]

Hi Mario,

 
Orson is the current maintainer of the GAL, because I have to little ressources 
for that at the moment (and he does a very good job!). However, I can write 
somthing about my ideas:

 - Would it be possible in a near future, to detach the glm library from GAL 
 (folder) and maybe make a common include file for the use glm? 
 Since the 3d-viewer is also using the glm, and last time we had problems with 
 the define of radius in radians.. maybe it can be a way to fix 
 this issue.

 Hi Mario,

 Sure. As far as I remember, initially glm was used by GAL exclusively,
 that is why I put it in the gal/opengl directory.
 
The GLM Library seems to be well established; I've seen it used for many 
projects; also the MIT-license is compatible with the GPL2. Of course it makes 
sense if you're sharing this ressource.

 - Would it be possible in a next near future, think to reimplement some of 
 (general) modules related with openGL to have in mind the reuse 
 in other modules in kicad? I mean, example: can we have a shader loader 
 manager to be used by different parts in the sources and not just 
 for GAL? Or any other (openGL / gml) very general code that can be reused in 
 other parts..? So it will not be rewritten and duplicated in the  sources..

 SHADER is already quite separated from GAL. It is just a class to load,
 link  apply shaders basing on generic OpenGL calls.
 
Indeed, this was written to be universal so I see no problems if you're using 
this module.

 Now more specific questions, just so I can try to understand a bit more of 
 the openGL / GAL / Pcbnew:

 - openGL / GAL is not currently the default mode, does it have anything to do 
 with openGL support? Does Kicad have any limitation policy to  not support 
 or limit the use of openGL (I mean.. openGL versions and shaders versions in 
 this case). (Other way to make the question:
 Does kicad want to support old-school PC plataforms / graphics board? so we 
 can't make the full step switch)

 As Nick mentioned - GAL is not complete yet, so KiCad should start with
 the default canvas now. People who understand its limitations and
 features should switch by themselves.
 
Not really ideal for the release; but with the given manpower I'm guessing the 
legacy canvas can't be dropped yet.
We're using the unstable version of KiCad already for our boards; you have 
still to switch often between the the old canvas / OpenGL, because not all 
features are implemented. This can be pretty confusing, our working student has 
already complained much about that :)

 There are also people complaining about OpenGL incompatibility, even
 though the standard we use is not very modern and lowering it would defy
 its purpose.
 
Well, I'm guessing that still OpenGL 2.1 is used as minimum requirement. 
According to Wikipedia (http://en.wikipedia.org/wiki/OpenGL), the standard was 
released 2006. That's almost 9 years ago; and I think at some point you simply 
can't support all old hardware. So that's a good decision to change here 
nothing.
 
Of course a software renderer is a good alternative, if Cairo is too slow, 
there is also a work package for students:
http://www.ohwr.org/projects/cern-kicad/wiki/StudentProjects
 
I had the same idea; but I've given up shortly, because the investment is high 
and the benefit low (only for people using old hardware).

 - Do you think is would be possible to do in some way what GAL/openGL do in 
 Pcbnew but now to display it in 3D? Would that be an appropriated way to do 
 it for the 3D-viewer? (Ie: generate it via shaders (lines, circles, etc) VS 
 generate it via polygon mesh)

 - If that makes sense, would it be eventually possible to reuse GAL/openGL 
 code in the 3d-viewer some how? in that case?
 GAL was designed with 2.5D view in mind and so was its interface,
 including auxiliary classes. Maybe I am wrong, but changing GAL to work
 in real 3D mode would cause a lot of major changes. Apart from that,
 there is also Cairo renderer which is not capable of 3D drawing at all.
 
2.5D is a good description. However, I had also in mind that it should be 
possible to overlay the 3D models for checking the mechanics. But that's rather 
a feature for the distant future. From (my) user perspective 3D editing is in 
my opinion absolutely unimportant, I don't know much use cases for that. 
Another idea was that it's possible to mirror the whole board, such that you 
can edit the backside.
 
Thanks Orson for the great work,
Torsten

___
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] Update on OpenGL performance on Intel GPUs

[Torsten Hüter]

Well Lorenzo,
 
this was always my argument when I've started to write the GAL ..
 
Today even the Raspberry Pi 2 for 30 Euro has a GPU for OpenGL (ES 2.0).
 
Greetings,
Torsten
 

Gesendet: Donnerstag, 05. Februar 2015 um 11:53 Uhr
Von: Miguel Ángel Ajo majop...@redhat.com
An: Lorenzo Marcantonio l.marcanto...@logossrl.com
Cc: Kicad Developers kicad-developers@lists.launchpad.net
Betreff: Re: [Kicad-developers] Update on OpenGL performance on Intel GPUs

Where I said CPU, I was meaning Laptop… I must proofread before I
click the “Send” button.

 
Miguel Ángel Ajo
 
On Thursday, 5 de February de 2015 at 11:49, Miguel Ángel Ajo wrote:

Nice, it’s good to know that the 300EUR cpu range runs
OpenGL nice for our needs. That means we’re not adding a huge
entry barrier with the OpenGL implementation.

 
Miguel Ángel Ajo
 
On Thursday, 5 de February de 2015 at 11:10, Lorenzo Marcantonio wrote:

Well, I got rich (more or less) and plundered the store for a 300 EUR
laptop for the office. CPU power is slightly better but the GPU is not
a 'classic' i915 but an HD one.
 
Performance on the opengl view is *wy* better; this time opengl is
better than xlib drawing.
 
(the reason is that in the HD GPUs shaders are run on the GPU, not in
the mesa library :D)
 
So I'd say that Intel's GPUs are now adequate, if you have at least an
HD one.
 
--
Lorenzo Marcantonio
Logos Srl
 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 
kicad-developers@lists.launchpad.net[kicad-developers@lists.launchpad.net]
Unsubscribe : 
https://launchpad.net/~kicad-developers[https://launchpad.net/~kicad-developers]
More help : 
https://help.launchpad.net/ListHelp[https://help.launchpad.net/ListHelp]
 

___
Mailing list: 
https://launchpad.net/~kicad-developers[https://launchpad.net/~kicad-developers]
Post to : 
kicad-developers@lists.launchpad.net[kicad-developers@lists.launchpad.net]
Unsubscribe : 
https://launchpad.net/~kicad-developers[https://launchpad.net/~kicad-developers]
More help : 
https://help.launchpad.net/ListHelp[https://help.launchpad.net/ListHelp]
 ___ Mailing list: 
https://launchpad.net/~kicad-developers[https://launchpad.net/~kicad-developers]
 Post to : kicad-developers@lists.launchpad.net Unsubscribe : 
https://launchpad.net/~kicad-developers[https://launchpad.net/~kicad-developers]
 More help : 
https://help.launchpad.net/ListHelp[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] Trapezoidal pads and planes.

[Torsten Hüter]

HiJean-Pierre,



I agree that a the trapezoidal pad is seldom used for most circuits and this feature isnt important. However,commercial tools like Altium Designer or Mentor Expedition support custom pad shapes, there is a lot of freedom for the pad geometry (any polygonal shape). Have a look here, how Altium does this:



http://techdocs.altium.com/display/ADOH/Creating+a+Custom+Pad+Shape



For custom shapes, you have to define there polygon connection points - see the section Thermal Connections for Custom Pads.



--



About the discontinuities:Ive used a few years ago the RF package of Mentor Expedition, there you can create tapered striplines for these purposes. And of course the copper fill follows these shapes.



You can find on youtube a good video about a typical RF design process; have a look here:



https://www.youtube.com/watch?v=qaeOii1rLN0index=8list=PL1QigjJyYCd-TquuBSXc31Y8RHbXA3RbB



Bye,

Torsten







Currently, this is by design.

The primary goal of these trapezoidal pads is microwave applications.

For these microwave applications, they are used to connect a large track
to a narrow pin ( transistor or IC) ( or a narrow track to a large pin)
*without discontinuity* of the copper width.
(A discontinuity between a track and a copper pad area can create signal
integrity issues. In fact any discontinuity on the signal path creates
issues, at very high frequencies )
A trapezoidal shape with an edge having the same size as the track, and
the opposite edge having the size of the transistor or IC pin does not
create discontinuity.
One could use also rectangular pads, and trapezoidal track segments to
avoid discontinuity, but Pcbnew does not know trapezoidal track
segments, mainly because they are not easy to handle in DRC.

When you are using trapezoidal shapes for pads, you are expected connect
a track to these pads using the right edge, and the right track width
(or the right pad size)
If this is not the case, a rectangular pad or an oval pad is better
(more easy to use).

Adding thermal relief to a trapezoidal shape creates discontinuity, and
the shape is no more a trapezoid.
In fact, using a trapezoidal shape for a pad in a copper zone has no
interest.

For these reasons, I did not spent time to code thermal reliefs for
trapezoidal shapes.

Of course, trapezoidal shapes can have now applications outside the
microwave applications, but I dont know these applications.

--
Jean-Pierre CHARRAS

___
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] Trapezoidal pads and planes.

[Torsten Hüter]

Hi Jean-Pierre,
 
I agree that a the trapezoidal pad is seldom used for most circuits and this 
feature isn't important. However, commercial tools like Altium Designer or 
Mentor Expedition support custom pad shapes, there is a lot of freedom for the 
pad geometry (any polygonal shape). Have a look here, how Altium does this:
 
http://techdocs.altium.com/display/ADOH/Creating+a+Custom+Pad+Shape
 
For custom shapes, you have to define there polygon connection points - see the 
section Thermal Connections for Custom Pads.
 
--
 
About the discontinuities: I've used a few years ago the RF package of Mentor 
Expedition, there you can create tapered striplines for these purposes. And of 
course the copper fill follows these shapes.
 
You can find on youtube a good video about a typical RF design process; have a 
look here (RF Design with Expedition PCB):
 
https://www.youtube.com/watch?v=qaeOii1rLN0
 
Bye,
Torsten
 
PS: The mailing list does not like HTML, so I've send it again as text, sorry.

___
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] PS plans for the near future

[Torsten Hüter]

Hi Tomasz,



this sounds good.



Id add



5) Shoving of routed components



When a component was fully routed, it is possible to shove it. Currently the KiCad PS router supports only dragging of traces but no component dragging. For this purpose all to the component attached tracks need to be rerouted, when the particular component was dragged.Typical application would be, you have the board routed and like to reduce the board space by dragging the components nearer to each other.



This is one of the nicest features that only few commercial EDA tools support. Ive used Mentor Expedition, which has one of the best PS routers of the market. Freerouter supports that too, but is pretty slow while dragging components.



--



Do you have any access to the Mentor Graphics products / Altium Designer / Zuken CadStar or similar for inspirations like the user interface?

If not, there are somepromotional films on YouTube:

https://www.youtube.com/user/MentorXpedition/videos

https://www.youtube.com/user/PADSPCBDesign/videos




Bye,

Torsten




Gesendet:Donnerstag, 18. September 2014 um 18:04 Uhr
Von:Tomasz Wlostowski tomasz.wlostow...@cern.ch
An:Kicad Developers kicad-developers@lists.launchpad.net
Betreff:[Kicad-developers] PS plans for the near future

Dear all,

We are planning to introduce some improvements to the PS router before
the first lightweight stable release of Kicad comes out. Heres are the
things wed like to get done by the end of November:

1) Length tuning tool

An automatic tool generating accordions/meanders on a chosen trace
to match the given length. The first version of the tool will simply let
you choose the pads and the required electrical distance between them.
We may do the same for diff pairs if time permits.

2) Diff pair router

An extension to the PS allowing to route both traces of a pair with a
constrained gap between and adding vias at appropriate spacing. For the
first version we aim to input the gaps/spacings by hand, later on we
will probably add such the possibility of adding such constraints on the
schematic, but this depends on the eeschema schedule.

3) On-line length measurement - display a fly-over window with the
length/skew of the currently routed trace/diff pair.

4) Some optimizations/improvements/bugfixes
- springback on via dragging
- optimizer improvements (better acute/right angle removal, tighter routing)
- improved layer switching
- optimizations to the PS storage model
- support for non-orthogonal pads

If theres any particular stuff youd like to ask for or discuss, dont
hesitate to tell us!

Most of these changes are internal to the PS code only and dont affect
other Kicad components.

Id also like to add support for arcs on copper layers (for efficient
representation of miters/meanders). Contrary to the current graphical
arc object, Id propose to approximate them using line segments (and
store as such approximations) so that theres no need to add full arc
support (for plotter/DRC/etc). What do you think?

Cheers,
Tom

___
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] Module editor branch merged

[Torsten Hüter]

Hi Orson,



very nice work, this gets KiCad to a new level.



In my opinion custom pad shapes are for todays PCB designs a important feature. There are some parts like MEMS microphones which require arcs as pads.



Do you have any access to professional tools like Altium Designer or Mentor Graphics Expedition for inspirations how that works? (Ive used both) Many tools have a separate padstack editor.



This video shows how complex pad shapes can be created using the Altium Designer:

http://www.newelectronics.co.uk/electronics-videos/altium-design-secret-four-creating-custom-pad-shapes/43959



Also zones can be useful for modules, such as keepout areas.



Maybe thats something for a wishlist.



Bye,

Torsten



Gesendet:Mittwoch, 16. Juli 2014 um 10:16 Uhr
Von:Maciej Sumiski maciej.sumin...@cern.ch
An:kicad-developers@lists.launchpad.net
Betreff:Re: [Kicad-developers] Module editor branch merged

On 07/16/2014 10:08 AM, Nick stergaard wrote:
 2014-07-15 17:45 GMT+02:00 Maciej Sumiski maciej.sumin...@cern.ch:
 Hi Nick,

 In my opinion drawing on copper layers with drawing tools instead of laying
 out tracks should not be allowed unless it is supported by the DRC
 algorithm.

 Sure, the DRC should handle it, but refresh my memory -- as far as I
 remember there was some talk about including tracks in footprints. I
 dont remember the outcome of that or it it is allow or not.

For the time being tracks are not supported by the module editor. The
reason is the same as - it would have to be handled by all algorithms
use tracks as input data (DRC, ratsnest, just to give an example).
It could be relatively easy to implement using iterators that go through
the list of tracks that belong to a board and then do the same for all
tracks that are stored in modules placed on the same board. It is just
an idea that may need some further consideration - I do not volunteer to
code it now.

Regards,
Orson

 6. no new update yet

 Fix pushed to the product branch.

 Yep works now by giving no error.

 ___
 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



___
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] Cairo rendering backend

[Torsten Hüter]

Hi Orson,



have a look here:

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/kicad-gal/view/head:/gal/wxdc/wxdc_gal.cpp



With my test examples it was faster than Cairo. I guess it should be possible to reach the same performance like the old drawing routines. Downside is the missing transparency and that wxDC drawing is deprecated.



Bye,

Torsten





Hi Torsten,

To tell the truth, I must have missed the source code for wxDC backend.
Maybe it is worth a try, but probably now it would have to be adapted to
the changes introduced to GAL. If you have a more or less working
version, maybe you can compare performance of both backends?





___
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] Cairo rendering backend

[Torsten Hüter]

Hi Orson,



thanks for the great work!



When Ive developed the Cairo backend, my idea was not only to use Cairo for printing but also as rendering engine for eeschema. For example compare GEDA gschem, they use there Cairo as well and the screen outputlooks in my opinion much better than eeschema (antialiasing / freetype fonts).



On my machine Ive found Cairo not that slow for smaller boards - but I have an Intel Core I7. Perhaps it makes sense to hide the Cairo switch in another menu entry?



There is also a third backend that Ive written last year, Orson has not included it - it uses wxDC. But wxDC has some drawbacks, it does not support transparency. Perhaps still useful as fallback solution ..



Bye,

Torsten



Gesendet:Donnerstag, 07. November 2013 um 18:59 Uhr
Von:Wayne Stambaugh stambau...@verizon.net
An:Kein Empfnger
Cc:kicad-developers@lists.launchpad.net
Betreff:Re: [Kicad-developers] Cairo rendering backend

On 11/7/2013 12:36 PM, Maciej Sumiski wrote:
 On 11/05/2013 07:40 PM, Wayne Stambaugh wrote:
 On 11/5/2013 4:33 AM, Maciej Sumiski wrote:
 Does anyone have anything against disabling switching (remove its hotkey
 and menu entry) to Cairo backend? I think it may only give a bad
 impression to users, as it is too slow for comfortable work. I am going
 to maintain it in case that there are changes in the GAL, but as it was
 said in the beginning - its main purpose is for PDF generation or
 printing.

 Regards,
 Orson


 Im fine with disabling it. Its not useful for display rendering even
 on my home computer which is very fast. I cant image how slow it must
 be on an older system or laptop. Is there any other reason to Cairo
 rendering around?


 It could be used as a fallback renderer, but right now it is too slow
 for that, so - in fact, there is no sensible reason.

 Regards,
 Orson



Doesnt it make more sense to fallback to the wxDC rendering? Its
known to work well except under certain conditions on OSX. You cannot
perform any editing other than using the PS router so Im not sure that
its very useful as a fallback.

Wayne


___
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] KiCad GAL changelog

[Torsten Hüter]

Hi Maciej,




 Actually, as far as I can see - most of the code you have written for
 display lists is already working, so there is not much to be done. Right
 now I use it for testing of item caching, but I am going to implement
 VBOs and when it is done - push it to repository.



Yes thats right, display list should work already. AFAIK from the VBOs itself we dont get much speedup, Ive read that display lists are sometimes even faster. But the combination of display lists, shaders and more intelligent drawing of the primitives should help to get higher frame rates.




 I agree with Dick - how about working on just one branch? It is based on
 your code, so it should be easy to modify it for you and it would be
 better to maintain just one branch.
 I have already added you to the team, so you should be able to commit
 your changes. Your support is very welcome, as you seem to be
 experienced with graphics programming, every hint is useful.



Thanks, this sounds like a good idea. Ill try next days to compile it on the windows platform.



Bye,

Torsten







___
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] KiCad GAL changelog

[Torsten Hüter]

Hi Maciej,



thanks for your efforts, nice work,Ill try this again for various boards. Indeed Ive spotted the missing callback function as well.

Its the combine callback of the tessellator, but this one is only called if there is an self-overlapping polygon.



So it should be clarified why there is such a polygon existing; if the zone filling algorithm works correctly it shouldnt exist.



Id disagree with Lorenzo, as the originatorof the GAL Id suggest that you stick with the first plan, thatmeans using display list first.

As you have (perhaps)already seen, you can use the group methods for that:

BeginGroup(..)

EndGroup(..)

DrawGroup(..)

DeleteGroup(..)



VBOs are a kind of optimization and Id implement it, after everything else works fine. The reason is, that it requires much more code for the same functionality. For instance you need to keep track of the various objects, like triangles, triangle strips, quadsand you need to organize the memory transfer etc.At this point Id implement also the major drawing routines as shaders using the interface that Ive provided. But Id do that later.





The question for me in general isthe minimum required OpenGL version, this is important for shader handling and other features.



--



Can you use the current location of the GAL for your bug fixes, this would be really nice, so that I and Dick for instance can commit as well:



lp:~kicad-testing-committers/kicad/kicad-gal



--



Im very busy at the moment and cant implement much, but at least I can give you some support.



Thanks,

Torsten



Gesendet:Montag, 22. April 2013 um 18:07 Uhr
Von:Maciej Suminski maciej.sumin...@cern.ch
An:Kicad Developers kicad-developers@lists.launchpad.net
Betreff:[Kicad-developers] KiCad GAL changelog

First of all, thank you for all the comments and suggestions. They are
very useful, especially bug reports (they really save me some time).

- Wayne Stambaugh found out that there were still some compilation
errors using wxWidgets 2.8. He has already sent patches for that -
thanks for a fast response and fix.
- I would like to thank Adam Wolf for launching a PPA for this branch
(available at
https://code.launchpad.net/~adamwolf/+archive/kicad-gal-testing-daily).

Bugfixes:
- Bug related to stroke_font should be already fixed. I suspect that it
was caused by multiline strings, as the newline character did not have a
proper bounding box computed.
- I have managed to recreate the tessellation error and fix it (there
was a callback missing for the GLU tessellator).

Features:
- The most important feature introduced this time is the Cairo-based
rendering backend. Now you can switch between the default renderer,
OpenGL and Cairo (hotkeys Alt+F10/F11/F12 or menu View-Switch canvas
to...). Cairo backend may seem to be slow, but it is a software renderer
and its main purpose is printing or creating PDFs.

Other:
- The branch address has changed to lp:~cern-kicad/kicad/kicad-gal, as I
wanted to make it possible to maintain the branch by more than person,
so now there is a team for that.
- There is also a win32 cross-compilation guide available
(http://www.ohwr.org/documents/251).

Plans:
Now the work is going to focus on speeding up OpenGL renderer, by means
of caching rendered items. It should especially improve render speed for
polygons, as right now they are tessellated every frame and that takes a
lot of time. Using OpenGL display lists at first and Vertex Buffer
Objects in the future should significantly increase FPS.
In the meantime I am also working on a version for Mac OS too.

Maciej Sumiski, CERN

___
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] Kicad GAL branch announcement

[Torsten Hüter]

HiMaciej,



thanks for the great work, really nice to see our stuff in action.



I had only some trouble with polygons, the tesselation seems to be buggy. Perhaps a malformed polygon input or the memory handling is problematic.

An alternative here would be to use simply a fast software tesselator like Poly2Tri (http://www.youtube.com/watch?v=Bt1TYzzr2Rg)- if the graphics card driver tesselator is too instable. Perhaps I can find some time at the weekend to investigate this problem.

With commenting out the DrawPolygon method in opengl_gal.cpp also the larger boards load well without crashing.



Tomasz has asked me already about VBO optimizations; this should work but needs to be well planned IMHO.



Thanks,

Torsten



Gesendet:Mittwoch, 10. April 2013 um 17:13 Uhr
Von:Maciej Suminski maciej.sumin...@cern.ch
An:Kicad Developers kicad-developers@lists.launchpad.net
Betreff:[Kicad-developers] Kicad GAL branch announcement

Dear developers,

As Lorenzo has already unveiled part of the message, I think it should
be announced in the public list, so everyone knows what is the talk about.

I would like to present you the preview version of the Graphics
Abstraction Layer-based rendering engine for Kicad, done according to
the following specification:

http://www.ohwr.org/attachments/1884/view-spec.pdf

The branch is mostly based on efforts of Dick Hollenbeck, Torsten
Hueter, Tomasz Wlostowski and mine.
Currently it uses OpenGL GAL backend for rendering PCBs in pcbnew, with
Cairo support compiled in but disabled due to some graphical
glitches that we still have to debug.

Im eagerly waiting for your feedback - please rememeber that this is
just a demo, it lacks some features, and despite our efforts it may not
compile on platforms other than Linux (with wxWidgets 2.8.12/2.9.4 
Cairo 1.10) and Win32 (with wx 2.9).

You can download it from my branch in Launchpad and compile it with
CMake flag KICAD_GAL=ON:

bzr branch lp:~orsonmmz/kicad/kicad
mkdir build
cd build
cmake -DKICAD_GAL=ON -DKICAD_TESTING_VERSION=ON ..
make

After starting up pcbnew you can switch between GAL and legacy rendering
using Alt+F12 hot key or via View-Switch canvas menu option.
I hope you will notice some speedup during panning  zooming. Currently
GL renderer is not much faster than the legacy one, but there
is a lot of room for optimization (that is, caching the board geometry
in hardware buffers, which will likely increase the performance
by an order of magnitude).

More details about changes introduced by us can be found in the bzr log
(personally I recommend revision 4029 changelog, as it was the
biggest change
[http://bazaar.launchpad.net/~orsonmmz/kicad/kicad/revision/4029]). Note
that the GAL view is currently not editable - as the GAL has no XOR
rendering, editing tools will have to be modified to take advantage of
the new renderer.

Regards,
Maciej Sumiski, CERN

___
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] Kicad-gal and OpenGL supported version under Mingw ( was Plotting/fabricating in nanometers)

[Torsten Hüter]

Hi Jean,

no, usually MESA is not required. What you only need is the opengl32.dll and 
the glu32.dll (e.g. C:\Windows\System32). The graphics card driver should 
provide the latest versions for these files. The old version of the MinGW 
OpenGL headers is normal, that's the same on my system - the purpose of GLEW is 
to wrap the functions of OpenGL  1.3.
So I'd guess you have an old driver/ a conficting library or headers somewhere. 
Perhaps OpenGL 2.1 is not supported on your system ( some older Intel GMA 
Chipsets support only  2.0 ).

A nice tool for troubleshooting is GLview:
http://www.realtech-vr.com/glview/download.html

There you can check, which extensions are supported.

I've found some movies on youtube, which are maybe also helpful:

OpenGL 4.2 + MinGW
http://www.youtube.com/watch?v=i8XRKBk40VA

OpenGL Superbible example (OpenGL 3.3), MinGW:
http://www.youtube.com/watch?v=9PbY7SM7P3w

--

I'll try next week to compile on my notebook (Windows 7 however), I'll check if 
I run into the same troubles ..

Bye,
Torsten


 I also have trouble with GLEW and POINT.
 I just added GLEW in Kicad-gal to compile it with Kicad-gal, and renamed
 POINT.
 (Currently I can run only the Cairo version of demos)
 
 The issue relative to OpenGL (run time error: opengl version 2.1 not
 supported)
 is due to the fact MinGw come from a rather old version of OpenGl (Mesa
 GL, in fact)
 (comments in .h headers show a 2002 version) and not an hardware issue.
 My MinGW installation is a recent version (now including GDIplus).
 
 So my question is:
 Are you using the Opengl libs and headers coming from Mingw,
 or have you installed a recent version of MESA GL under Windows?
 (Recent Mesa version seems do not have an easy install under
 Mingw/Windows)
 
 Thanks.
 
 -- 
 Jean-Pierre CHARRAS
 
 
 ___
 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

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  

Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

___
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] Graphics Limits … Windows CAIRO

[Torsten Hüter]

Hi Marco,

I hope you have the patience to wait for the integration of the GAL. I've done 
these performance tests before I've started to write the code and I've narrowed 
my selection to a direct, simple OpenGL backend for speed and a cairo variant. 
With the interface that I've created you can write your own plugin for another 
backend, but I'd prefer to concentrate on these two first.
Dick has already started to integrate the VECTOR2D class, which is our 
independent implementation of a point/vector.
I'm doing at the moment some code cleaning and go through all examples and then 
I'll upload an updated version.
I need some help for testing it on OSX, perhaps if you have some time left?

Thanks,
Torsten
 

 Jep,
 I'm here advocaciong again wxGraphicsContext.
 I'm feeling that also with nanometers we are going to fit tight with the
 simple wxDC.
 I'm proposing to fade using wxGCDC and use Paths that handles coordinates
 with wxDouble.
 
 
 To test the state of the art i suggest to test it on Windows doing those
 hacks:
 
 Compile wxwidgets statically enabling wxUSE_CAIRO (switches on CAIRO
 instead GDI/GDI+ that was result to be slugghish/slow).
 Change the Kicad code to use wxGCDC (is enough change a bit
 kicad_device_context.h)
 
 This should show us how Kicad + wx + cairo performs on Windows and show if
 we can pass for this way to enhance kicad.
 
 If someone has enough time, compiling CAIRO should also possible test how
 performs its OpenGL backend on windows.
 
 I wish do it, but i haven't a windows platform under my hands, so there is
 any volunteer ?
 
 
 --
 Marco Serantoni
 ___
 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

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

___
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] Plotting/fabricating in nanometers

[Torsten Hüter]

Hi Jean,

 OpenGl creates problems under Windows and MinGw,
 because the available version is old (1.3) and GAL cannot be easily
 compiled.

I'm compiling it currently on Windows, it works so far well - I had only 
problems with GLEW and cairo, it wasn't found automatically. So I'm using 
hard-coded paths on my computer; I have to modify the CMake scripts or provide 
external variables for CMake. On Windows I've renamed Dick's POINT name alias 
for VECTOR2D to POINT2D, because POINT is already existing and I had some 
trouble.  
What kind of hardware are you using? I've raised the requirement to at least 
OpenGL 2.1, usually that shouldn't be any problem on a recent computer - 
because we're now at OpenGL 4.2 : 

http://en.wikipedia.org/wiki/OpenGL

If we need to support 1.3 I have to write some workarounds.

Thanks,
Torsten

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

___
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] Plotting/fabricating in nanometers

[Torsten Hüter]

Hi Dick,

 Supporting wxDC in the GAL is a curious expenditure of time.  Did you see
 the discussion
 about class PAINTER ?

I've written that, because I thought it's nice to have something that's faster 
than cairo and still works when there is no good OpenGL support. Also perhaps 
it makes the transition to the GAL easier - because KiCad uses currently wxDC. 
Sure it required a bit of time. 

 class PAINTER is a *compile time* implementation abstraction.
 
 So I don't see putting wxDC behind the GAL useful when when goes to
 implement the wxDC
 version of a PAINTER.
 
 The goal of PAINTER is to minimize propagation of any graphics API, GAL or
 otherwise.
 
 Propagation is that what you spread around, like planting seeds all over
 the place. 

Perhaps I've missed something about the PAINTER class. I'll look in the archive.

Well, I've implemented the GAL, that you're able to change the graphics backend 
at runtime. A typical use case would be to use the OpenGL variant for your 
screen and the cairo variant for exporting PDF files.
Subjectively I'd say that the most of the time is not spend by the function 
calls; but rather directly by the graphics backend and it's rasterizer (I have 
to measure the execution time). 
To prevent too much of these function calls I've implemented the group function 
- with it you can draw a batch of graphic objects - I've not yet made a 
benchmark - but I'm sure that we gain some speed with it.

Another goal was to make it to use as easy as possible; basically you call the 
GAL with your objects in world coordinates - the GAL does the rest, the 
transformation to the screen, cursor, grid drawing etc.

--

Compilation time optimation makes sense, if we get really a significant speed 
up; but I'm sure we're less flexible. 

Bye,
Torsten

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  

Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

___
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] Plotting/fabricating in nanometers

[Torsten Hüter]

Hi Jean,

 the first is wxRealPoint, the floating version of wxPoint.
 the second is a new class: DPOINT defined in vector2d.h, very recently
 created by Dick.
 DPOINT is a powerful class.
 
 -- 
 Jean-Pierre CHARRAS

I believe Dick has derived it from my class. I'm using templates, there is also 
a class for a 3x3 matrix, and some kind of operations for these classes - 
because I need them for linear algebra and transformation operations.

http://bazaar.launchpad.net/~kicad-testing-committers/kicad/kicad-gal/files/head:/math/

BTW I'll soon update the GAL, now I'm supporting wxDC as well, have cleaned up 
the code a bit and some other small improvements.

Bye,
Torsten
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

___
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] GAL edit merges

[Torsten Hüter]

Hi Dick,

On 04.11.2011 18:38, Dick Hollenbeck wrote:

Hi Torsten,

Some concerns about GAL:

1) what would be the cost of doing OPENGL_GAL::DrawGrid()
using the GAL API itself?  (This would be better self promotion, than using 
the opengl
API, or cairo API, and would let this function be moved up into GAL itself.)


I believe I've implemented it this way, because I draw the lines in 
screen coordinates and I can use faster drawing methods rather than 
using the universal DrawLine(..) method. But I'll check if that could be 
unified for Cairo/OpenGL.




2) To best capitalize on the hardware acceleration, I wonder if we should not 
separate the
generation of the opengl display lists, from actually repainting them on the 
screen.
This means *two* functions, something like this:

a) The scene has changed, create new opengl display lists.

b) The on screen wxWindow containing a GAL has been resized or uncovered, 
simply use
existing opengl display lists and ask opengl to put them on screen.



This separation is what is being done in the existing 3d-viewer logic.The 
board is
only scanned one time to generate the display lists, and in the 3d-viewer of 
course the
board never changes, so this separation of list generation and screen update 
becomes a big
performance win.

I have yet to find this separation 2) in the GAL.





You can do this already with the group methods.

BeginGroup() starts a new group, EndGroup() finishes the group - and you 
can simply draw the recorded graphics elements with DrawGroup().
For OpenGL basically a display list is created; for Cairo I'm using a 
deque and a simple state machine (later Cairo versions have now already 
a group function, I'll use that in the next versions).


Have a look at the group example in the test folder.

Thanks,
Torsten


___
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] GAL edit merges

[Torsten Hüter]

Hi Dick,

 I just wanted to give you heads up.  Merging code is not fun for me, so I
 assumed it would
 not be fun for you.

Well, we have in our company the same challenges; I just have to make shure 
that it doesn't get too much out of sync. I should check in more often, perhaps 
we should make tags for relative stable versions (if I break something). 

 Hopefully BZR does most of the hard work.  In general I find it is better
 not to diverge
 too far however, since that usually means less manual work.  Of course by
 not diverging
 too far, this means coming back to a common repo with commits and merges
 on a smaller
 changes, frequent commits, basis.

It will be interesting for me if BZR merges better than Subversion.

Bye,
Torsten
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

___
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] Advanced rendering techniques for KiCad

[Torsten Hüter]

Hi Lorenzo,

I believe we have already discussed about this subject :)


Not to ruin your work/enthusiasm but... who cares? :D



At least Dick, Wayne  Jerry seem to care :)
But I think there is a demand for hardware acceleration / high quality 
rendering - this was often posted on the list.



Especially when, in a PCB cad system, the *absolutely most useful*
blending mode for layer is the XOR one (which IIRC was retracted from
OpenGL with color index mode, maybe it can be done with fragment
shaders).


Sorry, I have to disagree. Sure, XOR is the simplest way - but has not 
the advantages of the modern blending methods. With XOR you don't have 
any control of the transparency, you can't implement custom dimming of 
the layers, anti-aliasing is almost impossible. Please check kicadocaml 
- or my personal favorite:


Proteus PCB
http://www.labcenter.com/support/video/demo-movies.cfm?videoType=pcbtab=7

They use also OpenGL for the hardware acceleration. I've tried the demo 
version and the lookfeel is clearly superiour to KiCad.
It's not just eye candy - I think there are many productive 
advantages, like stepless zoom, panning, more control of the contrast 
for layer inspection etc.


OpenGL supports also logical operators. I've not tried it, but I'm sure 
even XOR is possible, if someone really needs this.



I say that because I tried gerbv high-quality mode (i.e. cairo blending,
software slow as hell) and, in fact, antialiasing/blending *detracted*
from the usefulness of visualization!

Well, I don't know if gerbv is the best example. We should rather have a 
look at commercial tools, like the mentioned Proteus PCB, the Altium 
Designer or FAB-3000 (we use that Gerber tool). All have now some kind 
of hardware acceleration. Cairo was recently improved, but I agree it's 
not the best API for drawing speed. For this purpose we have OpenGL. 
Although the antialiasing mode of gerbv is pretty slow, in fact I found 
the quality much better. I've used it also to export layers and have 
even created PNGs for our manufacturer this way.



In any case, the only 'correct' way to render alpha blendings in OpenGL
is to sort by layer, no Z-buffer technique can help you with that: it's
simply the way blending works! 


That's not correct. Perhaps I'm wrong - but I'd assume you have not read 
the latest computer graphics papers or you have not implement such stuff 
yourself. There are many alternative methods to do alpha blending, for 
example NVIDIA has some nice papers about depth peeling / transparency 
etc. With my algorithm you still have to sort the layers by the depth; 
but it doesn't solve the problem. Let's say we have two overlapping 
objects on one layer, how to prevent that the overlapping area doesn't 
get another color when using half-transparency? One answer is to use the 
Z-Buffer; I've got the idea from Tim Henson (author of kicadocaml).



In our case it's fairly easy to separate
stuff, just use a display list for each layer... and, no, FBOs won't be
useful in the general case to 'optimize' redrawings, you *have* to
repaint everything, unless you only change the top layer, to keep
correct blending. You *could* try with a FBO for each layer but it would
gobble heaps of video memory! 
That's exactly one thing that I don't want to do. I need only one FBO. 
When you're panning or zooming usually you have to do a redraw with any 
method. Sure you could put every layer on a separate texture/FBO but I 
don't think that would have any benefit. BTW I don't redraw the full 
scene for the cursor, I just restore the drawing area. Display lists are 
already supported with the Group-method.



A truly optimized way to handle it for
simple modifications (i.e. track drawing) would be an FBO for the layers
under the one being modified and another one for the layers above: so
you could update using an unblended blit, then the blended drawing of
the current stuff (being modified) and finish with a blended blit of the
'upper' layers.
I've considered already this method for rubberbanding. That means I'd 
put the moved object on a textured quad. I'm using a similar method 
already for the cursor.



Also think about all these people with open source drivers and/or low
end graphics :D heck, on my work machine I don't even HAVE opengl 
acceleration:P




My goal is to create something that offers superiour quality/speed to 
any known tool. Sure that means it doesn't work on 10 years computers, 
but even then we can develop a fallback method.
I've choosen a modular architecture, this means of course other APIs 
than OpenGL are possible. Currently I've written the interface for 
OpenGL and Cairo. For another APIs someone has just to implement the 
interface. If you like to contribute, you're welcome.


Thanks,
Torsten

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers

Re: [Kicad-developers] kicad-gal crash

[Torsten Hüter]

Hi Dick,

thanks, I'll try this tomorrow. I had also some trouble with Windows; 
this seems to be a wxWidgets problem - not all attribute variants work 
on every machine.


Bye,
Torsten

On 03.10.2011 06:48, Dick Hollenbeck wrote:

Torsten,

This patch is like what we are using in KiCad for opengl and it seems 
to be needed on one machine I have.


Without it the opengl window does not draw anything and crashes on 
first mouse move over that window when running test_gal.


If I have time I was going to show test_gal at the conference next Sunday.

Dick




___
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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)

[Torsten Hüter]

Hi Dick,

 Thank you *very* much.  I appreciate your time and expertise.
 
 For clarification, Are you saying that the implementation on top of 2.9 is
 different and superior in a significant way?

The implementation is superior because I can manipulate a wxBitmap directly 
with the wxNativePixelData and don't need to allocate memory. So it's surely 
faster. However, when I can figure out a platform independent way to get the 
color order, it should be as fast on wxWidgets 2.8 . I'll try to write a 
workaround.

 Obviously the stuff under
 wxWidgets has not changed, and to a large extent you are simply doing a
 bypass of wxWidgets from GAL to cairo or open gl, no?

OpenGL is no problem with 2.8/2.9, it's just the Cairo interface that has to be 
changed for the native backends or the current image backend.
 
 Is the 2.8 good enough for GAL to make a decent impression on first time
 observers?  Or do you recommend 2.9?  Or can be put a little of 2.9 into
 the
 GAL?

Well, on 2.8 it's slower - but for pure speed you need hardware acceleration, 
that OpenGL provides. I think for a useful impression a complex scene is also 
required. The quality looks of course already with Cairo much better than the 
OR-mode of the current KiCad implementation (OpenGL looks good as well with 
antialiasing forced). Another good thing is that you can define transparency 
for any object or layer.

Cairo is a software rasterizer; I've choosen it for a fallback solution when 
OpenGL doesn't work and it's useful as printing backend (PDF, SVG, PS, etc.) 
With Cairo you have also the option to use Freetype fonts. 

Cairo should be a good candidate for eeschema, for instance GEDA Gschem uses 
Cairo and the schematic quality looks much better than eeschema in my opinion.

Also for the best impression I think Cairo 1.10 should be used; because the 
image backend was much improved.

The drawing speed of Cairo depends on the effective use of the paths. A long 
path is better than drawing a lot of short paths. I'm trying that already, 
ideally many similar objects should be drawn after each other to maximize the 
path length. For example Text with the same stroke width or pads of the same 
diameter.

Bye ..
Torsten
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

___
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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)

[Torsten Hüter]

Thanks Wayne as well,

 Thanks Torsten for your efforts.  I just built kicad-gal on Debian testing
 with
 wxWidgets 2.8.10 and it looks great.  The cairo rendering is really
 smooth.  I
 wonder if it will be fast enough for PCBNew?  

This has to be tested - I think for bigger boards you need hardware 
acceleration and the OpenGL-GAL. For eeschema it should be fast enough - 
because GEDA Gschem runs well. 

 I had to fix CMakeList.txt
 in
 order to make it build properly.  Do you mind if I commit these changes? 

No problem, you can commit your changes.

Bye ..
Torsten

--
(Sorry double posting)
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

___
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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)

[Torsten Hüter]

Hi Dick,

 You have twice as many in a
  std::list,  I will use std::deque.  Its ten minutes to change it.
  Yes, I agree - this was just an initial choice - I've changed some
 types already to std::vector but the std::deque is also a good idea.
 
  std::vector is better than std::list.  std::deque and std::vector are
 both
  OK.  The only difficulty with std::vector is if you hundreds of
 thousands of
  points in a polyline, in which case the backbone array needs to be very
  large.  std::deque uses a segmented backbone, and could be slower than
  std::vector for smaller numbers of points.

Yes, I've read as well, that at certain conditions the std::deque is faster. 
Especially for our cases it should be the best solution; so I changed anything 
to the deque. 

 virtual ~VECTOR2T
 
 Just let anyone deriving from VECTOR2 add in virtual destructors, you
 don't need it at this level.  It causes the virtual function table to be
 copied and constructed, both of which cost time, for large numbers of
 points.

That's right; it was mainly a stub that Eclipse creates automatically. I've 
commented it out; if it should be used later, the comment just needs to be 
removed.

--

I had to apply some different changes for wxWidgets 2.8; now it should be run 
there as well. The problem is that I've changed to the image backend of Cairo 
and the blitting doesn't work like I'd like. So I'm using the code from 
wxCairo; but it's much slower than a direct access with wxNativePixelData that 
2.9 provides. I think it is even there room for impovements.
The rubberbanding demo is still bit stupid; at the moment it displays only a 
QFN footprint (you can zoom with the mouse wheel and pan with the right mouse 
button). I'll implement dragging of some objects later and seperate the classes 
in different files.
There is still much in progress; also I have to add more documentation.

I've changed the branch owner to kicad-testing-committers. You should be able 
now to commit changes.

Bye ..
Torsten 

-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

___
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] Improving usability of KiCad

[Torsten Hüter]

Hi Brian,

 As for putting up a branch, I would, but I don't need a whole PPA thing, I
 don't care to sign any agreement.  If someone can direct me towards some
 quick pointers for setting up a bzr branch somewhere where you all can get
 at it, let me know and I'll see about doing it.

A personal branch is relative easy to set up. At least it wasn't very hard for 
me, just follow these instructions: 

https://help.launchpad.net/Code/UploadingABranch

When using this command:
bzr push lp:~userid/project-name/branch-name

Just replace the project-name with kicad and choose a branch name.

Bye..
Torsten
-- 
GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

___
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] Improving usability of KiCad

[Torsten Hüter]

Hi guys,

Alex:
 I'm find the idea of going QT interesting, but I have to ask the
 question: Isn't QT slower?. It may be just me, but I get the feeling
 that wxGTK apps are the most responsive on my F13 box.

Well I've tried the performance of wxGC vs. QPainter and the QPainter wasn't 
faster (AFAIK a little bit slower). In general I like QT coding style and the 
API - although I think wxWidgets made a good step forward with the new release 
(2.9.1). For instance event binding is much easier now.
 
 I never questioned kicad's decision to use wxWidgets. I do think,
 however, of the 3d-viewer crashing on non-nvidia cards or nvidia cards
 with nouveau. I can reproduce it 100%. 

I don't think that wxWidgets can be blamed for this problem - my OpenGL GAL 
test programs work well with wxWidgets and an ATI HD4650. Have you tried other 
OpenGL applications (driver problem?)
   
 Are these and similar sort of
 issues common with wx? Would it be easier to switch to a different GUI
 system instead of patching up wx? If the answer to the last two
 questions is yes, then count me in on the effort.

Although I think that QT is better, the question for me is if the porting to a 
new widget toolkit is worth the effort. Because KiCad is in my opinion relative 
tight bound to wxWidgets porting requires surely a lot of work.

Bye ..
Torsten
-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

___
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] OpenGL rendering for kicad

[Torsten Hüter]

Hi Alex,

If you like, you can help me testing - I'm writing currently on something 
that's called Graphics Abstraction Layer. There is a branch in the launchpad 
repository (kicad-gal).
However I've to upload a new version (I had trouble with cmake/wxWidgets 
2.9.1). Currently I'm working on frame buffer object support for rubberbanding 
and loading of fragment/vertex shaders.

Bye ..
Torsten


 After getting positive responses about GL rendering in other threads,
 I'd like to put forth some general ideas about implementing it in kicad.
 Also, please name any new ideas; it makes it easier to refer to them. :P
 
 Safe OpenGL;
 Because of the video driver mambo-jumbo, we shouldn't expect to use
 anything but the most basic OpenGL. If we go this route, than any GL
 call made will be implemented and callable. We don't have to worry about
 extensions not being present, and risking to crash the program.
 
 Rocket-boosted OpenGL:
 Once the safe rendering path is in place, there's nothing stopping the
 implementation of a secondary path that uses any exotic OpenGL extension
 imaginable. The truth is, a board is a very dynamic entity; new tracks
 are added, others are deleted, things are moved around. Keeping
 everything in sync without having to resend the entire board data might
 require some handy extensions (I say might as a GL noob would). If a
 user works with complex enough boards, than he might want to take the
 effort to make sure the video driver is properly installed and he can
 use the full muscle of kicad, while casual users will find kicad working
 just as before, or a bit faster.
 
 Error recovery:
 In my experience with OpenGL, there may be uncomfortable moments when
 something goes wrong in the driver, and the GL context is lost. How can
 kicad recover from such an error?
 
 pcbnew first:
 Notice how I talked about boards and tracks when justifying myself. I
 think pcbnew should be the first to get a facelift.
 
 Reuse of existing code:
 The 3d viewer already has code that can draw tracks, a few other layers,
 and turn them on and off. It also uses Safe OpenGL. Other than the
 comment scarcity, it's an excellent starting point in my opinion.
 
 It's in development:
 What would the best way to work this out be:
 a) a separate branch on launchpad
 b) an experimental part of kicad in the main repo
 ?
 With a separate branch anyone interested could get commit acces, but
 keeping things in sync with the main repo might be an issue. Option b on
 the other hand eliminates this problem, but we'll bother the big boys
 very often with patches.
 
 What are your thoughts? I wouldn't even know where to start, but I hope
 after some brainstorming, designing, and plain neuron-burning, we can
 come up with a workable plan; that is, if enough people like the idea.
 
 Alex
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
 
 iQIcBAEBAgAGBQJMseEhAAoJEL0kPHNPXJJK3ZcP/0uHQlxoQ1c8C6dCxmMsNpTn
 vmLHMNqk/pnyJh3zWX+i8dzFvh/G47a7RWTpHMD8kBmQXwPR8zKpQPfKsihu42E8
 /XOuIoQxPiKQ6KECBG8IkQE0IY+AdzDaHXVeggJ0vK08s6Bf+hC0hipTccXe2dJG
 utglRPPauTqQL4/jGaWgyC0CaOQ88Hf3Yo1ojHcu7ZBOAsNz+P3R9UK9jbU7Q1gA
 hIgKV5gmInlOkB41ODD18BHFkHXXWrbqpM4Qs1b1YkXz9NaS60OrxQ9f7ZBmWZMg
 5aPYvmR2O2lvcNe4oJwnnNwoca3/qqB3gL/wttSkyhDSQVEsXhCFaaADGZbNWRMR
 C4KU05I/ZrPvmZgXQh9f6qrdP1iRU6labZnvt1NFpSuxeLO25l/KVWwkKR5Irkdv
 X83ds//cXzkjwrXt4BULehG/fTV/gG8pfj+H5BHg3p0gDpuwM3W5l0b+biITbVYP
 nD9TGMPMJrM+xlVJeJT4zYsZRsmcca87PeIFsNth7nJvV63/8MOjt4iUEnK5vWW7
 txN/E8NApUzcQD5ThX/kYcxSx76znPnzJ/iPzn+dT0U/T9dZKLro7TvCiQlmOiWs
 ttwmM7YF6+GcTu2Y/OyqZWQuFdWNXQThKLiGzTq+gNBccThxnfIJH1Q0ZQxMaA1k
 AfIVv//3UGD61Hcc/4EO
 =AiLX
 -END PGP SIGNATURE-
 
 ___
 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

-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

___
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] Graphics Abstraction Layer for KiCad

[Torsten Hüter]

Hi Dick,

 And we would simply use a redraw technique, but my assumption could be
 wrong.  And I have wondered about how we could do the interactive
 rubber-banding box drawing without XOR, same way Torsten?

XOR drawing is one of the simplest ways for erasing the old drawing; but 
artifacts are the problem (this is rather a bug than a feature). In theory 
OpenGL for instance supports the XOR operator; but only in color index mode.
I'd prefer not to use XOR, instead I'd first try the redrawing of the scene (a 
double buffer is already used) - if that's too slow I'd save the old frame 
buffer to an aux buffer, overdraw the screen with the moved object and then 
restore the old contents via blitting. Blitting is already done for the cursor.
  
 Again, I do think the feature you Lorenzo highlight would be slick, and
 would actually be a little more intentional than some of the artifacts
 we have now.  Those current artifacts are more like litter left behind
 after a picnic :), but seem to have been found useful.

The application should handle that - the old shape would be drawn grey before 
moving.
 
  My newest machine is a dual core with a radeon 200 mobility (about 3yo)
  and the only driver available is the open source one! And it's renowned
  for sucking at opengl :P

AFAIK the Radeon 200 is based on the X300 Mobility; which is older than 5 
years. It's true that there could be a better support for Linux, but the newer 
products have a good OpenGL support - both ATI and NVIDIA offer drivers, which 
have the same code base like their Windows variants.

--

I think the wxGCDC (backend is Cairo on Linux) variant is slow, because for 
every graphics primitive a new path for the pen is created. This is very 
ineffective - ideally when you're drawing something with Cairo the paths should 
be as long as possible. One good example is text drawing, there one path could 
be used.

Bye ..
Torsten

(Sorry Dick for double posting have used the wrong address)
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

___
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

[Kicad-developers] Fwd: Re: Graphics Abstraction Layer for KiCad

[Torsten Hüter]

Hi Lorenzo,

 Well, in opengl you're forced to redraw *everything* at each frame
 (excluding clever FBO usage),

Nope, for example I don't redraw everything for the cursor. At the moment I'm 
copying the pixels to the main memory.

 Yep, the 'clever' FBO usage is exactly what you called an 'aux buffer'
 (which in opengl is another kind of thing:P) Also double buffering is
 mandatory for acceleration these days, anyway. OTOH maybe you could
 simply stuff the 'other' things in a display list and replay it. Just
 because FBO are not a core feature but yet another extension, IIRC.

Yes, I know the FBO extension, but I mean the auxiliary buffers - usually you 
have up to four - I'll try that at the weekend. I don't know if they work with 
any OpenGL implementation, because these are optional.

 I keep wondering what kind of graphic primitive do you need to use
 opengl instead of 2D graphics primitives (which are already being
 accelerated by the X server). 

Depends on the graphics library - Cairo isn't accelerated (there are backends 
in development) - I don't know if wxDC has some hardware acceleration.

Also keep in mind that most consumer cards
 are optimized for full screen opengl only (at least in the times of
 nvidia-8, years ago, I know). 

Perhaps it was in history, today hardware acceleration works in the windowed 
mode well.

 /me is usually working more in software to go on cheaper hardware since
 we produce the hardware too (so, in the end, hardware is *more expensive*
 than development time). And don't forget that kicad is, at the moment,
 an entry level product... while Mentor could ask for a ginormous box
 (since anyway with their licence you can buy about 4-6 top-class PCs,
 these days:D) we would risk to loss some of the eagle-level audience.

Well, almost any entry PC has these days a 3D accelerator. Also OpenGL doesn't 
mean that its suited only 3D drawing, there are a lot of operations for 
manipulating 2D surfaces.
Eagle should be no reference for us - why only entry level? Eagle seems not to 
be much further developed, I've used 10 years ago and it looks still the same. 
I know myself Mentor Expedition - have used it for my diploma thesis. The 
router is the best on the market (fast pushshove), but the schematic entry 
sucks - IMHO its much quicker to draw schematics with KiCad.
 
 At the moment the only thing is a little slow on kicad is zone filling
 (which I usually keep disabled anyway because it distracts from the
 track layout...). I guess it could be a little sluggish on my box with
 an 8-plane in 6 mil technology (well, such a board could use a faster
 box anyway).

I'd assume that you have tried only the Linux version. On Windows7 (and Jerry 
has written on OS X) the drawing is really pretty slow - the OpenGL 3D view is 
much faster. This is a motivation for such a backend. On Windows you have 
usually no problems with an OpenGL driver.

 Cairo is slow by definition until it isn't accelerated some way... gerbv
 with cairo is absolutely not useful! (BTW transparency in a gerber
 viewer is not useful for checking stuff. XOR combining IS useful)

I don't know if that can be said without trying; sure its slower than the 
OpenGL variant - but I've found it for my examples still OK. However, it has to 
be tried with many objects on the screen. I don't know how efficiently it was 
implemented in gerbv.

Another backends are possible if required; wxDC isn't my favorite because it 
has several restictions compared to other graphics APIs - but with some work 
its possible to integrate it too.

Bye..
Torsten
-- 

PS: Sorry, again the wrong reply address :( 
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

___
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