<div dir="ltr">And forgot to mention: depending on the update rates (of the other process and of morphic), it might be more efficient for the other process to draw horizontal lines instead, and then draw it rotated on the drawOn:.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Nov 29, 2025 at 2:57 PM Luciano Notarfrancesco <<a href="mailto:luchiano@gmail.com">luchiano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Works great, thanks!<div>I guess no one was using this, and I'd like to share how I'm using it because it might be useful for other people programming with Morphic.</div><div>I use it in morphs that scroll continuously. This is sometimes called rolling, or waterfall effect. For example, I have a SpectrogramMorph that has an 'image' (a Form) and a 'position' (the current horizontal position in the image) that starts at 0. Another process periodically draws a new vertical line at the current position, and updates position := position + 1 \\ image width. Then, in the drawOn:, I just make two calls to image:at:sourceRect: like this:</div><div><br></div><div>drawOn: aCanvas<br> | w h p |<br> w := image width - 1.<br> h := image height - 1.<br> p := position.<br> "from left to right, draw from the next column position+1 to the last column:"<br> aCanvas image: image at: 0 @ 0 sourceRect: ((p + 1) @ 0 corner: w @ h).<br> "and then wrap and continue drawing from the first column to the current column position:"<br> aCanvas image: image at: (w - p - 1) @ 0 sourceRect: (0 @ 0 corner: p @ h)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 28, 2025 at 11:20 PM Juan Vuletich <<a href="mailto:juan@cuis.st" target="_blank">juan@cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Luciano,<br>
<br>
On 2025-11-27 2:24 PM, Luciano Notarfrancesco via Cuis-dev wrote:<br>
> This fixes a little problem. I thought we fixed it before, but there <br>
> was still an inconsistency that showed up when starting unzoomed and <br>
> then zooming in or out.<br>
><br>
This method has had many iterations. The real reason is that WarpBlt has <br>
integer arguments. The geometrically correct result requires Float <br>
arguments. Besides, a better image resampling algorithm would help too. <br>
Some day...<br>
<br>
I just pushed a slightly different version of your fix, that should give <br>
identical results. I also updated two other related methods for consistency.<br>
<br>
Thanks!<br>
<br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis.st" rel="noreferrer" target="_blank">www.cuis.st</a><br>
<a href="http://github.com/jvuletich" rel="noreferrer" target="_blank">github.com/jvuletich</a><br>
<a href="http://researchgate.net/profile/Juan-Vuletich" rel="noreferrer" target="_blank">researchgate.net/profile/Juan-Vuletich</a><br>
<a href="http://independent.academia.edu/JuanVuletich" rel="noreferrer" target="_blank">independent.academia.edu/JuanVuletich</a><br>
<a href="http://patents.justia.com/inventor/juan-manuel-vuletich" rel="noreferrer" target="_blank">patents.justia.com/inventor/juan-manuel-vuletich</a><br>
<br>
</blockquote></div>
</blockquote></div>