kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

On 11/01/2013 09:24 PM, Lorenzo Marcantonio wrote:
> On Fri, Nov 01, 2013 at 05:35:10PM +0100, Maciej Sumiński wrote:
> > Groups are handled by rendering backends and are identified only by their
> > number (think of it as a handle) and there is a 1-to-1 relation between
> > group id and VIEW_ITEM/layer combination.
>
> That makes suspiciously easy to use display lists or VBOs:P

Indeed, that was the reason to use the above solutions. Cairo uses 
something similar to display lists (they call it groups too).

> Another thing I've seen mentioned around: targets?

Targets are used for compositing. Right now, there are 3 targets available:
- CACHED - For items that are expected not to change for at least a few 
frames (eg. pads, tracks, and so on). These are kept in GPU memory and 
are the fastest to be rendered.
- NONCACHED - It is for items that are likely to disappear/appear every 
now and then. An example of that are pad & tracks labels - they appear 
at a certain zoom. They are gathered in a single batch and sent to GPU 
for rendering.
- OVERLAY - This is for additional items, that may change even if the 
viewport stays the same. Here goes for example selection area box or 
changes introduced by push & shove router.

> Also I can't see a thing when I switch to cairo (my fault probably).

Maybe, but I have just discovered another bug - you will not see 
anything until you load a board. Check if it is your case.

> > VIEW_GROUPs are particularly useful when drawing on the overlay layer
> > (destined for drawing temporary objects) and in that case you may need to
> > draw a single item layer by layer rather than drawing layer by layer, but
> > using all items.
> > For usual drawing of items, you should have a look at draw():607 - this is
> > where caching VIEW_ITEMs/redrawing groups happen.
>
> MMmmm more or less is clear. Could you check that loop anyway? otherwise
> I can't find a way to match types.

In the loop (view.cpp:646-650):
for( int i = 0; i < layers_count; ++i )
{
    m_gal->SetLayerDepth( m_layers.at( i ).renderingOrder );
    draw( aItem, layers[i], aImmediate );
}
'i' is the index to the LAYER_MAP. You can safely use LAYER_NUM here (or 
rather GAL_LAYER_NUM). I finally got what you have meant - yes, there 
should be:
m_gal->SetLayerDepth( m_layers.at( layers[i] ).renderingOrder );
as you suggested. It is fixed in the attached patch.

> Now at least it compiles and links, and that's a major step...
> however it... well... doesn't work exactly fine:D it seems that somehow
> the layer mapping got messed up so I can always see pads, for example,
> but never traces. Other things are correctly shown hidden... Some
> tracing required
>
> And now, for something completely different: there is a 'should not
> occur' condition which actually happens. In D_PAD::ViewGetLayers only
> the copper side of the pad is considered, and I'm not sure it's entirely
> correct: for example the first case considers pads on both front and
> back pushing in the requested layers both mask and paste (but I suppose
> that's only a slight inefficiency). Often however dummy pads are used
> for paste reduction or mask controlled openings. These are pads which
> resides in no copper layer. I think the best way to handle this function
> would be to loop over the pad layer mask and simply add the flagged
> layers. Of course the ITEM_GAL_LAYER entities would still need special
> treatment.

I have never seen such case before in the boards that I have for 
testing. But if you say so, I think it could be changed. I just hope it 
will not drop performance significantly. Maybe the solution you have 
mentioned should be applied as a last resort?

Regards,
Orson

=== modified file 'common/view/view.cpp'
--- common/view/view.cpp	2013-10-14 18:40:36 +0000
+++ common/view/view.cpp	2013-11-03 21:44:43 +0000
@@ -645,7 +645,7 @@
 
     for( int i = 0; i < layers_count; ++i )
     {
-        m_gal->SetLayerDepth( m_layers.at( i ).renderingOrder );
+        m_gal->SetLayerDepth( m_layers.at( layers[i] ).renderingOrder );
         draw( aItem, layers[i], aImmediate );
     }
 }