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 _______________________________________________ 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