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

[Gastón Caruso]

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.
Thanks for all this hard work Juan! I humbly think that cuis is honoring
the Smalltalk spirit!

El mar., 16 jun. 2020 a las 12:42, Phil B via Cuis-dev (<
cuis-dev at lists.cuis.st>) escribió:

> Juan,
>
> 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.
>
> 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.
>
> Thanks,
> Phil
>
> On Tue, Jun 16, 2020 at 11:15 AM 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
>>
> --
> 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/9db42838/attachment.htm>