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