With an identical geometric sketch I found the interaction to be much
slower with a bigger playfield (paste up morph).
To be ablsolutely sure, I changed DrGeo code so it only updates the
changed views (morphs), but still it does not improve the speed
rendering (interaction with the user dragging an item), at least on slow
device like the iPad. Funnily I appears to be faster on PC workstation.

Hilaire

Le 20/07/2011 17:08, Andreas Raab a écrit :
> On 7/20/2011 14:44, Igor Stasenko wrote:
>> 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.
> 
> I'm sure you're aware of Rome (http://www.squeaksource.com/Rome.html).
> It does everything you describe; my original intent was to enable
> platform graphics to be used interchangeably with BitBlt.
> 
>> Another approach with raster operations which bitblt does is to make a
>> compiler which generating a highly optimized code on the fly,
>> using jitter.
> 
> Been there, done that. Makes very little difference. The problem is that
> the time it takes to load and compile BitBlt dominates the time to
> actually draw stuff. In my experiments I could see 4-8x improvements for
> large area blits but no real world benchmark ever showed any significant
> improvements. By the end of the day most time isn't spent filling large
> areas; most time is spent in drawing text and other small regions.
> 
> Cheers,
>   - Andreas
> 
> 
> 


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