kicad-developers team mailing list archive

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

On 04/14/2016 11:48 AM, Lorenzo Marcantonio wrote:
> On Thu, Apr 14, 2016 at 11:33:18AM +0200, Maciej Sumiński wrote:
>> Hi,
>>
>> As recently Jean-Pierre has reported he had been running out of memory
>> with complex boards, I decided to take another step to reduce memory
>> footprint of OpenGL canvas.
>>
>> Currently, the most expensive thing to draw is stroked text, as there
>> are lots of labels on tracks and pads. To reduce the drawing cost (and
>> memory requirements), texts that are not targeted to Gerber files (i.e.
>> pad & track labels) might be displayed using bitmap fonts. This way, a
>> single letter cost is reduced from tens of triangles to just two.
> 
> This will lose accuracy on the board view... if I zoom in on the board
> near a character the character is correctly displayed (big), to have
> such resolution on a bitmap font you'll need a huge texture map. OTOH
> antialiased bitmap would be actually more readable than the current
> unconsistent-stroke-width one. Also you need quite a bit of a texture to
> contain the current repository (IIRC it's most of the latin space plus
> some greek plus some cyrillic).

I would argue if an enormous texture is a requirement. Currently the
code uses 2048 x 2048 @ 8-bit atlas [1], and I hope it can be supported
by the majority of popular GPUs. If you check, the atlas contains also
cyrillic, greek and what-not characters. You have to really zoom in to
see distortions resulting from using bitmap fonts.

Alternatively, there is 1024 x 1024 version too, but I would rather
switch to it, if I am wrong about my GPU capabilities prediction.

> Surely it is a good solution for non-design text, like net names and pin
> numbers; I'd make it optional for design text like silk and copper text.
> 
> The performance issue is expected since 'modern' GPUs are biased versus
> texture pulling rather than geometry computation (the old FireGLs had an
> extremely idiotic texture unit but a blazing fast geometry coprocessor
> --- for the time, of course; and an hardware overlay bitplane :D)
> 
> Could be worth a try; otherwise some more refined kind of view/LoD
> culling would be needed (changing during pan/zoom the visible geometry);
> definitely a lot more complex.

There is already a level-of-detail culling implemented. It was really
necessary to render net/pad names on complex board. Otherwise
performance was really poor.

> Another simple thing I suggested a while ago but didn't actually try:
> why don't use line strips for non-design text? That would be reasonable
> (2 point for segment), completely zoomable; you lose control of the line
> width (since for some reason many GPU have arbitrary limits on line
> width... 5px on the Intels IIRC) but it would be a lot better than
> textured text.

5 px is quite a limitation, do not you think? I would rather increase
the atlas texture resolution or split it into a few textures.

Regards,
Orson

1.
https://raw.githubusercontent.com/orsonmmz/kicad-source-mirror/97d20a1f279f6f3f051b440bbd8aaab7e38fcde9/helpers/gal_bitmap_font/bitmap_font_2048_0.png
2.
https://github.com/orsonmmz/kicad-source-mirror/blob/97d20a1f279f6f3f051b440bbd8aaab7e38fcde9/helpers/gal_bitmap_font/bitmap_font_0.png

Attachment: signature.asc
Description: OpenPGP digital signature