<div dir="ltr">I don't have a retina display anymore (and I didn't pull the recent changes in a while), but the difference is quite noticeable on my 14' full hd screen.<br>Thanks for all this hard work Juan! I humbly think that cuis is honoring the Smalltalk spirit!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 16 jun. 2020 a las 12:42, Phil B via Cuis-dev (<<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Juan,</div><div><br></div><div>It's been a while since I looked at the VectorEngine code but did you look into pipes / kernel chaining to see if that would help? The issue of not enough compute work to make it worth it is pretty well understood on GPUs and there are various mechanisms to maximize work that can be done on the GPU before the CPU needs to get involved again. Not sure if the latency issues you were running into were per-frame or per-pixel so this might or might not help.</div><div><br></div><div>While it's great to have the option to run on the CPU, getting something that can at least optionally run on the GPU would seem to be rather important given where computing power is these days. Having an image running single-threaded on a multi-core CPU and not at least taking advantage of the GPU where possible doesn't seem very future proof.</div><div><br></div><div>Thanks,</div><div>Phil</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 11:15 AM Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div bgcolor="#ffffff">
On 6/15/2020 6:01 PM, Hilaire Fernandes via Cuis-dev wrote:
<blockquote type="cite">
<p><font size="+1">Hi Juan, <br>
</font></p>
<p><font size="+1">I noted (not measured I may be biased) an
important speed up in the vector graphics rendering when I
resize the circular toolbar. Do you made some optimization?</font></p>
<p><font size="+1">Hilaire</font><br>
</p>
<div>Le 12/06/2020 à 17:15, Juan Vuletich
a écrit :<br>
</div>
<blockquote type="cite">I
updated many packages due to this change. Please pull all your
packages, and tell if you experience any problems.<br>
</blockquote>
<pre cols="72">--
GNU Dr. Geo
<a href="http://drgeo.eu" target="_blank">http://drgeo.eu</a></pre>
</blockquote>
<br>
Yes. It seems I forgot to tell, I'm sorry for that.<br>
<br>
After some weeks, I got a prototype OpenCL version of the
VectorEngine working correctly. But performance was surprisingly
bad, especially when comparing to my previous experience with OpenCL
in heavy Image Processing @ Satellogic. I learnt that the task
scheduling and kernel startup overhead for OpenCL can be rather
high, and only payed off if the OpenCL kernel has enough work to do
to compensate for that. VectorGraphics routines run very quick, but
there are a lot of calls. So the OpenCL overhead dominates, even if
running on CPU. This means essentially that OpenCL is not suitable
for this task. The VectorEngine hierarchy included
VectorEngineParallelizable, that was a rewrite of the algoritms to
best match OpenCL parallelization. Given that I will need to rewrite
that part in C with SIMD intrinsics, these new algorithms I spent
months on, are useless. The simpler algorithm, with assistance from
CPU caches, sould be ok. So I just removed them.<br>
<br>
When I originally wrote VectorGraphics, the "default" PC display was
24" HD. MacBook Retina didn't exist yet. So, VectorGraphics treats
each R, G, B subpixel as a different pixel, with a unique position
in the screen. This allows for maximum image quality on that class
of displays. The difference in a 24" HD display is quite noticeable.
But today, displays with higher pixel density are common. On these,
subpixel rasterization is no longer needed, and, the expense of
additional data structures is not worth it.<br>
<br>
So, I reorganized the VectorEngine hierarchy. Now there are just two
classes: One does SubPixel rasterization and the other does
WholePixel rasterization, both with the simpler algorithm. When
using a VM plugin for real time Morphic updates, the choice will
depend on display resolution or user preference. Right now, for
TrueType rasterization the SubPixel one is used, but for default
VectorCanvas, the WholePixel is used. WholePixel is about twice as
fast, and quality is still quite good for general graphics. This is
the difference you are seeing. I hope all this is good news for you!<br>
<br>
Thanks,<br>
<pre cols="72">--
Juan Vuletich
<a href="http://www.cuis-smalltalk.org" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" target="_blank">https://github.com/jvuletich</a>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
</div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>