kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

I really find ugly/distracting the messy line width in text in the
opengl view, so investigated the thing...

At the moment it generates the endpoint list and draw it thru the GAL
DrawPolyline function. This substantially convert the line to a polygon
to rasterize it with round endcaps, getting bluntly rounded by the
transformation/projection matrices. I agree that's the right way to draw
tracks and similar things. It also seems to me that the line is drawn
with a fragment shader using a technique like that used for the circle
(I never used shaders and I'm a bit confused... the comments talk about
a *vertex* shader? AFAIK they aren't even supported on the
Intel-Tungsten...)

In the process it pumps quite a bit of vertices (I'd say about 12 for
a single line segment, but maybe I'm wrong).

I think text could be better drawn using the classic GL_LINE_STRIP
primitive and glLineWidth for setting the width. In aliased mode these
are guaranteed to produce uniform line widths, since simply generate
parallel fragments. Truly, line width >1 are not guaranteed but I never
seen a GPU not doing these... 

Also this would pump only 1-2 vertices for line and, given how much text
there is on a board with netlist name shown, should be quite
a performance improvement. On a medium sized board I see:

09:50:25: Debug: RecacheAllItems::immediately: 1 1605,7 ms
09:50:25: Debug: Uploading 2097152 vertices to GPU / 62,8 ms

When showing netnames and pad numbers. Disabling them I have:

09:51:02: Debug: RecacheAllItems::immediately: 1 1091,1 ms
09:51:02: Debug: Uploading 1048576 vertices to GPU / 35,3 ms

That would need adding a DrawSimplePolyline member to the GAL layer
doing the different draw processing. The bad side would be that this
would apply even to copper text; I don't think the difference will be
significant (since it's visual only, anyway)... if really wanted to
maintain the 'precision' off copper text a flag could be added to the
text function.

What do you think of that? Have I missed something crucially important?

PS: for the XXX todo comments in the following bezier curves I'd
recommend the de Casteljau algorithm (which seems to be the current
standard for drawing them). Too bad they deprecated evaluators in newer
OpenGL, if hw accelerated like in the old FireGL they would be *the*
solution, here.

-- 
Lorenzo Marcantonio
Logos Srl