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

[Juan Vuletich]

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. Geo
> http://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 Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200616/c5e19244/attachment-0001.htm>