On Thu, Apr 14, 2022 at 4:23 AM Alexei Podtelezhnikov <[email protected]> wrote: > > On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George <[email protected]> wrote: > > The blog post mentions "a large constant factor because it’s doing > > complicated exact-area calculations for each pixel" as a performance > > impediment when drawing into the accumulation buffer. If one were > > willing to settle for fewer gray levels in the resulting image, could > > something like multisampling be used to eliminate the need for these > > area calculations entirely, especially given that SIMD is already being > > used to exploit parallelism? I'm sure there's a reason why this isn't > > done, but if someone could enlighten me as to exactly why I would highly > > appreciate it. > > There are basically two approaches to rendering: Windows does > multisampling, the rest of the world integrates. I do not want to make > any claims about the speed of the either approach. There are claims > out there that other renderers beat FreeType using parallelism by the > expected factor equal to the number of CPUs, maybe more, maybe less.So > we want to see if we can borrow some of those approaches. The main > reason why FreeType is very careful about adopting alternative > approaches is ultra-portability of FreeType to pretty much anything > under the Sun because of pure C89 or C99. The performance non-parallel > rendering is not bad. Also, you can do parallelism on levels above > FreeType and outside of its control.
A note about threads on Window: even if the mingw-w64 project provides a pthread implementation (called winpthread) which could be useful for multiplatform code, it is known that winpthread is a bit slower than native Win32 threads. So I would avoid winpthread on Windows. Vincent Torri
