[Cuis-dev] Clipping operation

Thierry Goubier thierry.goubier at gmail.com
Thu Apr 30 02:03:39 PDT 2020


Le jeu. 30 avr. 2020 à 10:45, Hilaire Fernandes via Cuis-dev
<cuis-dev at lists.cuis.st> a écrit :
>
> Hi Thierry,
>
> Yes, it was looking odd to me. Thanks to confirm what I understood.

Then you didn't need me much :)

I hit that when starting to port from Pharo to Cuis.

> I guess the rationnal behind this paradigm is to optimize drawing operation?!

Maybe. But I wonder how much you gain (unless you are on a device
where setting up clipping is expensive). The way it is done also means
that you can't customize morph tree traversal for drawing (i.e. have a
morph that for example cache its submorphs for faster drawing) unless
you subclass the canvas . And even if you do that, is there a point
where, on a draw operation, you can catch the canvas and replace it
with your variant? I don't know.

In truth, I'd be interested to see drawing optimisations by
manipulating the morph tree.

Thierry

> Hilaire
>
> Le 30/04/2020 à 10:28, Thierry Goubier via Cuis-dev a écrit :
>
> in Cuis, Submorph clipping only happens for one submorph, and only if aMorph>>#clippedSubmorph is true (and that clips to the parent morph, so, if your wheel morphs are submorphs of your overall frame, then incorrect clipping for the clipped submorph).
>
> In a case like yours, you will probably need to add a morph that do nothing but clipping, to ensure that the morph you are drawing in has the exact same bounds as its parents.
>
> The code in charge of that is MorphicCanvas>>#fullDraw:
> The code selecting the clipped submorph is Morph>>#clippedMorph. By default, it is the last one.
>
> --
> GNU Dr. Geo
> http://drgeo.eu
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev


More information about the Cuis-dev mailing list