| Thread Previous • Date Previous • Date Next • Thread Next |
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.
| Thread Previous • Date Previous • Date Next • Thread Next |
