When filled shapes are drawn in the schematic editor, it appears that all of their fills are drawn first in the order in which the shapes were place, and then their borders are drawn after all of the fills have been drawn. This means that the first shape’s fill is covered by the second shape’s fill, but then the first shape’s outline is drawn over top of both shapes’ fills, followed by the second shape’s fill over top of everything else.
This means that overlapping shapes’ fills and outlines are interleaved in a strange and (to me at least) unuseful way. I’ve shown an example below. The magenta rectangle was drawn first and the cyan one second. You can see that the fill of the cyan shape covers the fill of the magenta one, but the border of the magenta one is drawn over the fill of both, followed by the border of the cyan one.
I suspect that this is because whatever renders the various shapes on the screen calls the “draw fill” method of each object on the screen and then calls the “draw border” method of each object.
It would be a lot more useful if all of the render functions of a particular object were called before moving on to the next. This is the standard in pretty much all drawing/drafting programs. Object have a draw order, and you can place them on top or behind each other simply by changing the draw order (the familiar “bring to front”, “send to back”, “move forward”, and “move back” methods found in every other drawing software)
Is there a reason that KiCad draws this way? It makes a lot of otherwise simple operations either very difficult or impossible. It would be nice if KiCad had this feature, even if it was an optional drawing mode.
“KiCad is no program for creating art” is a terrible excuse, especially when pretty much every other schematic editor supports draw order and overlapping shapes. I’m glad to see that it is on the radar.
I must have a very limited imagination because I can’t imagine a single useful use for the third dimension (“move forward”, and “move back”) in the schematic.
For being “a lot more useful” I would expect a lot of such examples.
Its a problem, but typical in the CAD realm where lines have prority. So this is typical for some, especially older, mechanical CAD applications. The reason for this is that IF you do not allow the user to adjust drawing order then your drawing becomes more efficient because you can sort your data for efficiency. Which can make orders of magnitude more complex drawings possible.
So its a tradeof, between performance and comparability.
In this case though its a bit in optimal choice. Why? Well, if kicad would have composable order. Than suddenly you could successfully do more intelligent merges in version control systems. But apparently there has been some huge problems regarding this and interoperability between the schematic and pcb designer at some point so they are unlikely to do anything for this in the immediate future.
This is the standard in pretty much all drawing/drafting programs.
No its not, its standard in vector drawing but not in general CAD applications. Some do some don’t. Lines have priority, fills may not even exist. But a schematic editor is close enough to a vector drawing app so it should implement this. But like i said not just for drawing reasons.
For some schematic symbols where more detail in the symbol (in particular connectors) conveys more information to the reader, being able to layer up filled shapes makes drawing them more straightforward.
Being able to highlight parts of a schematic by placing a filled shape (usually a rectangle) behind all of the parts being highlighted is very useful in a) documenting the blocks of a schematic on a single page, and b) calling a colleague’s attention to that part of the schematic (e.g., “work on this section” or “the problem is somewhere in here”).
If I can put a shape over top of a portion of a schematic I can redact it in so that what is behind the shape is hidden. This can be useful where there are proprietary parts of a schematic that need to be hidden when I show the rest of the page to someone else.
I’m sure that I could come up with more if pressed on the matter. 1 & 2 are of particular interest to me. Does the lack of any of these features prevent me from capturing a schematic and generating a PCB from it? No. However, they make it easier to communicate with others and that is valuable.
Blockquote
This is the standard in pretty much all drawing/drafting programs.
Blockquote
No its not, its standard in vector drawing but not in general CAD applications. Some do some don’t. Lines have priority, fills may not even exist. But a schematic editor is close enough to a vector drawing app so it should implement this. But like i said not just for drawing reasons.
The defacto standard in 2D CAD formats is DXF/DWG, which supports draw order. Altium, which seems to be the industry standard for commercial PCB CAD software supports draw order. Those are good enough examples imho to justify including in KiCad, even if it were just an option (e.g. optimized rendering vs draw-order-based rendering).
That said, there seems already to have been enough demand from others for this feature that a ticket has been generated, and that’s good enough for me.
