[squeak-dev] Re: How Morohs are rendered

Igor Stasenko siguctua at gmail.com
Wed Jul 20 15:37:50 UTC 2011


On 20 July 2011 17:08, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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.

Yes. And it will be one of the backends :)

>
>> 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.
>
Hmm.. but why you need to compile every time before use?
Of course there's a lot of combinations for blitting ops
(src depth)*(dst depth)*raster op etc..

but once compiled, you can use it many times.
And actually, Morphic not using all possible combinations, so once you
compile enough operation set its using, then it should run at maximum
throttle,
without compilation interference.
Or maybe we're talking about different approaches?



> Cheers,
>  - Andreas
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list