Re: [Kicad-developers] Text in opengl
On 02/24/2014 11:43 AM, Lorenzo Marcantonio wrote: a) Why do you think so? It is just one black & white texture containing all characters (e.g. http://i.stack.imgur.com/VFKM2.gif) and then it is simply referred to when drawing characters. Textures can also be colorized, so the bitmap black & white is perfectly fine. How many characters? The full BMP, maybe (since we have unicode...); It's not *so* easy. Need thinking. Here it comes: http://unifoundry.com/unifont.html It takes ~2MB of memory and has size of 4128x4160 px, so there is a chance that it could fit to 4096x4096 if the frame is cropped. The bad thing is that it may look really ugly if characters are too much stretched. On the other hand, I suppose that naming nets using non-ascii characters is a rare case (however it has to be supported if that is the policy). Regards, Orson ___ 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
Re: [Kicad-developers] Text in opengl
On Mon, Feb 24, 2014 at 11:13:27AM +0100, Maciej Sumiński wrote: > line, so you need a way to tell GPU that there should be a break. It is > better explained here (for triangles), chapter "Use Triangle Strips to Batch > Vertex Data": GL_LINES, then. However endpoints would be drawn twice; if fragment testing is done correctly (and IIRC it is) shouldn't be a problem. > a) Why do you think so? It is just one black & white texture containing all > characters (e.g. http://i.stack.imgur.com/VFKM2.gif) and then it is simply > referred to when drawing characters. Textures can also be colorized, so the > bitmap black & white is perfectly fine. How many characters? The full BMP, maybe (since we have unicode...); It's not *so* easy. Need thinking. > b) Maybe there are some ways to sharpen textures, but I am not very familiar > with the topic. Grid fitting after rasterization AFAIK can't be done... but maybe there is a fragment shader trick to pick the 'right' pixel. > But for lines made from triangles it works > http://oi58.tinypic.com/21n2s1j.jpg (yup, it is buggy, there is something > wrong and currently I do not know how to fix it). Yes, but you pump triangles, not lines :P the current trend for GPUs seems to be that. -- 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
Re: [Kicad-developers] Text in opengl
On 02/24/2014 08:45 AM, Lorenzo Marcantonio wrote: - Handling a VBO for line strips (and probably a shader or some other way of controlling line width per line, not for the whole batch). I am not sure if degenerated vertices (i.e. two consecutives vertices with the same coordinates to indicate beginning of a new line) work in GL_LINE_STRIP mode, otherwise you have to use GL_LINE instead. Text should never generate identical vertices, otherwise font data is misoptimized :P anyway I don't remember seeing something forbidding them (but also nothing guaranteeing... so maybe they are implementation dependant - as usual!) It is not that text should generate identical vertices, the purpose is to separate lines stored in a single VBO. If you have a VBO drawn as GL_LINE_STRIP, then you will have *all* vertices drawn as a single continous line, so you need a way to tell GPU that there should be a break. It is better explained here (for triangles), chapter "Use Triangle Strips to Batch Vertex Data": https://developer.apple.com/library/ios/DOCUMENTATION/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html Using a shader to fix line width should work, but doesn't reduce vertex count. I hoped to do that. Also I have no idea on how shaders work :P - Drawing using direct mode, but in this case all lines should be drawn at the same time. Also I wonder how does it compete with current VBO batch in terms of performance. If I had to choose, I would go for bitmap fonts. It makes every character one quad or two triangles. Or maybe antialiasing could solve the problem? Texturing the font would need a) a huge amount of texture memory (and Intels are sharing the system memory) and b) losing crispness due to resampling; I'd prefer the current situation in that case :D a) Why do you think so? It is just one black & white texture containing all characters (e.g. http://i.stack.imgur.com/VFKM2.gif) and then it is simply referred to when drawing characters. Textures can also be colorized, so the bitmap black & white is perfectly fine. b) Maybe there are some ways to sharpen textures, but I am not very familiar with the topic. Antialiasing on lines is historically never been implemented on consumer cards (it was one of the 'differences' of the Quadros), but maybe now the situation is different. In fact the FireGL we used (still the IBM design, not the overpowered Radeon) had the 'line' primitives (evaluators included) completely done in HW, antialiasing and stuff. But only one texture stage :D But for lines made from triangles it works http://oi58.tinypic.com/21n2s1j.jpg (yup, it is buggy, there is something wrong and currently I do not know how to fix it). Regards, Orson ___ 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
Re: [Kicad-developers] Text in opengl
On Sun, Feb 23, 2014 at 10:01:59PM +0100, Maciej Sumiński wrote: > Truly they are. Vertex shaders are said to be supported since OpenGL 2.0, so > fortunately most of current GPUs are compatible. Oh well even on a TNT2 they are supported... in software :D AFAIK they're accelerated only from the GMA-X series; not a big issue since vertex shader are called way less often... > Assuming that *every* card supports lines wider than 1 pixel, you are still > limited to available line width range. In my case (integrated Intel GPU), > http://pastebin.com/86jqj2bV outputs: > line width range: 1.00 - 5.00 > line granularity: 0.50 > I am afraid you will not get much more on better video cards. As > transformations do not apply to line width, you can have up to 5 pixel wide > lines (at least in my case). This may be a problem for copper texts (as you > rather expect them to apply to WYSIWYG), but should not be a limitation for > netnames (depends on sight quality). Ouch. Very *very* ouch. It seems that these days cards are made only to pump out textured triangles. It wouldn't surprise then if these thick lines were slow as hell :((( More research is needed. > - Handling a VBO for line strips (and probably a shader or some other way of > controlling line width per line, not for the whole batch). I am not sure if > degenerated vertices (i.e. two consecutives vertices with the same > coordinates to indicate beginning of a new line) work in GL_LINE_STRIP mode, > otherwise you have to use GL_LINE instead. Text should never generate identical vertices, otherwise font data is misoptimized :P anyway I don't remember seeing something forbidding them (but also nothing guaranteeing... so maybe they are implementation dependant - as usual!) Using a shader to fix line width should work, but doesn't reduce vertex count. I hoped to do that. Also I have no idea on how shaders work :P > - Drawing using direct mode, but in this case all lines should be drawn at > the same time. Also I wonder how does it compete with current VBO batch in > terms of performance. > If I had to choose, I would go for bitmap fonts. It makes every character > one quad or two triangles. Or maybe antialiasing could solve the problem? Texturing the font would need a) a huge amount of texture memory (and Intels are sharing the system memory) and b) losing crispness due to resampling; I'd prefer the current situation in that case :D Antialiasing on lines is historically never been implemented on consumer cards (it was one of the 'differences' of the Quadros), but maybe now the situation is different. In fact the FireGL we used (still the IBM design, not the overpowered Radeon) had the 'line' primitives (evaluators included) completely done in HW, antialiasing and stuff. But only one texture stage :D -- 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
Re: [Kicad-developers] Text in opengl
On 02/23/2014 05:19 PM, Lorenzo Marcantonio wrote: On Sun, Feb 23, 2014 at 01:30:47PM +0200, Vesa Solonen wrote: Just check blending and transparency works well enough. The specs explicitly says that a fragment is generated for each rasterized 'pixel' (quoted since pixel is not a concept in opengl:P) so there shouldn't be problems with that. I find strange that the text engine was reimplemented from scratch since the drawtxt can happily works with a callback; whatever... I'm more concerned about the complications from state tracking in the GAL (i.e. having to pass and set everything correctly). It needs more study. I am here to help, do not hesitate to ask any questions. If you try to add new features to GAL and it does not work - let me know. Tidiness and legibility apart, the performance is worrying me since for a not-so-busy four layer board the time exceeds often 5 seconds; I guess that time is only CPU dependant (the GPU is probably only running 'after' that and even on Tungstens performance seems quite good). Unfortunately, recaching is done by CPU, that is the reason. To be able to simply pass vertex indices to render, those have to be precomputed earlier. All the transformations that used to happen in the fixed OpenGL pipeline are calculated by CPU now. Too bad this recaching thing is impacting even the standard view (it rebuilds when you toggle zone visibility so it isn't 'snappy' as before). Still quite acceptable, anyway. I guess it could be solved by just informing VIEW that items need to be recached and then do it when it becomes active. I will probably add it to the next merge request. Regards, Orson Given that's in it's infancy I'd assume there is still a huge gain for further (subsequent) optimization, I'm not too worried. ___ 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
Re: [Kicad-developers] Text in opengl
On 02/23/2014 09:59 AM, Lorenzo Marcantonio wrote: 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...) Truly they are. Vertex shaders are said to be supported since OpenGL 2.0, so fortunately most of current GPUs are compatible. 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). You are right. 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... I do not want to discourage you, but I am somehow sure that after deploying the code, you will find at least a few combinations of GPU/driver (most likely open)/OS that support only 1 pixel wide lines. 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? Assuming that *every* card supports lines wider than 1 pixel, you are still limited to available line width range. In my case (integrated Intel GPU), http://pastebin.com/86jqj2bV outputs: line width range: 1.00 - 5.00 line granularity: 0.50 I am afraid you will not get much more on better video cards. As transformations do not apply to line width, you can have up to 5 pixel wide lines (at least in my case). This may be a problem for copper texts (as you rather expect them to apply to WYSIWYG), but should not be a limitation for netnames (depends on sight quality). Currently, OpenGL GAL makes use of VBOs. Most of "static" data (e.g. tracks, vias) are cached in GPU memory and to draw them you only send vertex indices. "Dynamic" data (e.g. preview, selection box, other temporary drawings) is collected and sent in one batch. Only grid and compositing (draw a few textured quads) are done using direct mode. It leads to 2 options: - Handling a VBO for line strips (and probably a shader or some other way of controlling line width per line, not for the whole batch). I am not sure if degenerated vertices (i.e. two consecutives vertices with the same coordinates to indicate beginning of a new line) work in GL_LINE_STRIP mode, otherwise you have to use GL_LINE instead. - Drawing using direct mode, but in this case all lines should be drawn at the same time. Also I wonder how does it compete with current VBO batch in terms of performance. If I had to choose, I would go for bitmap fonts. It makes every character one quad or two triangles. Or maybe antialiasing could solve the problem? Regards, Orson 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. ___ 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
Re: [Kicad-developers] Text in opengl
On Sun, Feb 23, 2014 at 01:30:47PM +0200, Vesa Solonen wrote: > Just check blending and transparency works well enough. The specs explicitly says that a fragment is generated for each rasterized 'pixel' (quoted since pixel is not a concept in opengl:P) so there shouldn't be problems with that. I find strange that the text engine was reimplemented from scratch since the drawtxt can happily works with a callback; whatever... I'm more concerned about the complications from state tracking in the GAL (i.e. having to pass and set everything correctly). It needs more study. Tidiness and legibility apart, the performance is worrying me since for a not-so-busy four layer board the time exceeds often 5 seconds; I guess that time is only CPU dependant (the GPU is probably only running 'after' that and even on Tungstens performance seems quite good). Too bad this recaching thing is impacting even the standard view (it rebuilds when you toggle zone visibility so it isn't 'snappy' as before). Still quite acceptable, anyway. Given that's in it's infancy I'd assume there is still a huge gain for further (subsequent) optimization, I'm not too worried. -- 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
Re: [Kicad-developers] Text in opengl
23/02/14 10:59, Lorenzo Marcantonio kirjoitti: > I really find ugly/distracting the messy line width in text in the > opengl view, so investigated the thing... :) I noticed it too, but thought it's still in the "make it work" phase. Make it pretty may follow... The same line width jumping happens in all primitives on the board. Anyway I remember similar problem for gEDA some time ago, but Peter Clifton solved it for both gschem and pcb. IIRC it included grid fitting the primitives on the rasteriser and rounding the position, not line width. The result is still wrong, but less noticeable. The implementation is for both OpenGL and cairo. I think this was around 2008. Also truetype font rendering had some smartness regarding positioning and scaling, but details have vanished from my memory. > What do you think of that? Have I missed something crucially important? Just check blending and transparency works well enough. -Vesa ___ 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
[Kicad-developers] Text in opengl
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
