On 20 July 2011 10:13, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
Le 20/07/2011 01:10, Igor Stasenko a écrit :
On 19 July 2011 23:28, Hilaire Fernandes hilaire.fernandes@edu.ge.ch wrote:
No such thing. If you're interested in the details you'll have to be more specific about what aspect you're interested in. Are you trying to make your graphics faster? In that case enable the preference
Yes, I try to make graphics faster on iPad. I am tempted to think the bottleneck are the bitblt operations of the damaged area, also the larger the whole canvas, the slower the rendering with the same sketch. I can try to reduce the number of damaged area.
Yes. The fillrate of bitblt engine is quite slow, because all operations are in memory and CPU bound. Comparing to fillrate of modern graphics cards. And even to fillrate of other CPU-driven implementations like, because they using highly optimized code for that.
This is my felling as well, especially when I compare to GTK+ DrGeo, 10 years ago, the bitblt copy operation of the double-buffering was faster on computer of that time (800Mhz cpu I guess). So if optimization should be done, it is on the bitblt plugin, right?
We want to create a vector graphics framework, which eventually replace the old Canvas and bitblt. Currently its in initial stage of development. But the idea is to be able to support different rendering backends, like Cairo, OpenGL or OpenVG. While application interface will be abstracted from low-level implementation.
Another approach with raster operations which bitblt does is to make a compiler which generating a highly optimized code on the fly, using jitter.
Hilaire
-- Education 0.2 -- http://blog.ofset.org/hilaire