Le 20/07/2011 01:10, Igor Stasenko a écrit :
> On 19 July 2011 23:28, Hilaire Fernandes <hilaire.fernandes at 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?

Hilaire


-- 
Education 0.2 -- http://blog.ofset.org/hilaire