[Cuis-dev] VectorEngine performance. Re: Please pull all repos! Re: StrikeFont cleanup

[Luciano Notarfrancesco]

So Cuis is now much closer to real-time vector graphics, and will work on
CPU without dependencies on OpenCL, this sounds wonderful, Juan! Thanks for
all this work!

On Tue, 16 Jun 2020 at 10:15 PM, Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> On 6/15/2020 6:01 PM, Hilaire Fernandes via Cuis-dev wrote:
>
> Hi Juan,
>
> 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?
>
> Hilaire
> Le 12/06/2020 à 17:15, Juan Vuletich a écrit :
>
> I updated many packages due to this change. Please pull all your packages,
> and tell if you experience any problems.
>
> --
> GNU Dr. Geohttp://drgeo.eu
>
>
> Yes. It seems I forgot to tell, I'm sorry for that.
>
> 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.
>
> 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.
>
> 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!
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200616/dfd44b87/attachment.htm>