<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-15"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 6/15/2020 6:01 PM, Hilaire Fernandes via Cuis-dev wrote:
    <blockquote cite="mid:41d171cf-ebf0-118d-b6d9-42997c840374@drgeo.eu"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-15">
      <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 class="moz-cite-prefix">Le 12/06/2020 à 17:15, Juan Vuletich
        a écrit :<br>
      </div>
      <blockquote type="cite" cite="mid:5EE39C25.8060407@jvuletich.org">I
        updated many packages due to this change. Please pull all your
        packages, and tell if you experience any problems.<br>
      </blockquote>
      <pre class="moz-signature" cols="72">-- 
GNU Dr. Geo
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://drgeo.eu">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 class="moz-signature" cols="72">-- 
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis-smalltalk.org">www.cuis-smalltalk.org</a>
<a class="moz-txt-link-freetext" href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a class="moz-txt-link-freetext" href="https://github.com/jvuletich">https://github.com/jvuletich</a>
<a class="moz-txt-link-freetext" href="https://www.linkedin.com/in/juan-vuletich-75611b3">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
  </body>
</html>