On 20 July 2011 10:13, Hilaire Fernandes <hilaire.fernandes at edu.ge.ch> wrote:
> 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?
>

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
>

-- 
Best regards,
Igor Stasenko AKA sig.