> El 26 ago 2019, a las 14:08, ducasse <steph...@netcourrier.com> escribió:
> 
> Hi guille
> 
>> Procastination 1: Render the world fully in athens (instead of a middling 
>> bitmap) to have an idea of the effort to get fast to hdpi
>> <PastedGraphic-5.png>
>>   What you see here is a world drawn completely in athens in minheadless, 
>> where in red are the invalidated rectangles in the screen (I’m using to 
>> debug a bit).
>>   Icons are broken because I broke them while playing, not because they do 
>> not work in athens :P.
>>   There is still work to do if we want to explore this direction. Mainly 
>> performance issues to make it at least usable, so it can be iterated easily.
>>   We have seen with Pablo that a lot of time is taken in the transformation 
>> of morphic/pharo form/bitmaps to athens ones, since they do not have the 
>> same format and right now it is done with a bit-per-bit copy.
> 
> I do not get it. You are saying that it is slow while I have the impression 
> that if we remove the bit-per-bit copy we should get faster. 

There are two different things in here :).

First, in morphic we have bitmaps and forms representing for example icons and 
images.
Those forms/bitmaps are stored in a format that is not cairo compatible, so 
every time we need to render an icon a super expensive transformation takes 
place.
The other day we worked with Pablo in some caching of those transformations and 
it improves indeed a lot.
Still we have to see if it makes sense to add those caches (where to put them 
how to invalidate them, are they shared or not…), or if we change the internal 
representation of forms, or what :).

Second, right now minheadless is drawing the morphic world into a form and then 
the form is copied (literally blitted usin bitblt) into the cairo context/sdl 
texture.
What this first experiment is about is to render directly on the sdl texture 
without the extra copy.
I don’t think is will be necessary faster as this is just avoiding a couple of 
copies (blits) but the athens morphic renderer is far less optimized than the 
historical one…
The question to me is: can this be **as fast as the bitblt one** yet render 
better in hdpi?

Reply via email to