| ID: | 6281 |
| From: | rn...@igor2.repo.hu |
| Date: | Wed, 10 Jan 2024 12:06:06 +0100 (CET) |
| Subject: | [pcb-rnd] test request: librnd opengl rendering fix |
Hi all, while working on osm-rnd I've found a huge bug in the opengl rendering code. If you can, please test librnd from svn with opengl rendering with any of our apps. Please look out for: - any rendering distortion - whether the crosshair always renders from side-to-side - whether a non-local grid always renders to side-to-side I'd be especially happy if someone could test this on gtk4 for me. Bug details: This bug caused losing coordinate precision within the GPU in case coordintes were big. I think the first 1 bit error came in if: - in pcb-rnd you drew anything farther then about 1 meter from 0;0 - in sch-rnd anything further than about 1000k from 0;0 (e.g. gschem import because gschem sheets start at real high coords; you really need 64 bit coords librnd to load gschem drawings without translating them back to 0;0 on load) - pretty much anywhere a 1000km away from 0;0 Of course spotting an 1 nanometer rendering error is not easy. However this error went on growing as coordinte values grew. I believe this bug made 64 bit coordinates with opengl rendering useless: you need 64 bit coords because you have large coords, but if you go to the far end and zoom in and we render things with an increasing number of bits error, that's no good. The problem was that the original code sent librnd coordinates (32 bit integer or 64 bit integer) to the GPU and used the GPU to do the translation to screen coordinates. However, most GPUs only support GLfloat for coordinates, which is 32 bit float, so we can't use 64 bit floats. So effectively the code degraded our 32 bit or 64 bit coordinates into 32 bit float which caused inaccuracy within the GPU with large base coords. The solution is to do the translate part of the librnd->screen translation on CPU, using 32 or 64 bit integer coords and then pass it on to the GPU. This eliminates the problem by moving large coordinates back to around 0;0 for the GPU. I believe we inherited this bug from gEDA/PCB which probably still has it. I'll send a separate email on how I found this bug. Best regards, Igor2
Reply subtree:
6281 [pcb-rnd] test request: librnd opengl rendering fix from rn...@igor2.repo.hu