Re: GSoC 2022: Alternative Rendering Engines
On Thu, Apr 14, 2022 at 4:23 AM Alexei Podtelezhnikov wrote: > > On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George 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
Re: GSoC 2022: Alternative Rendering Engines
On Tue, Apr 12, 2022 at 9:57 AM Matsumura, George 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. Alexei
Re: GSoC 2022: Alternative Rendering Engines
Hello George, > I am an individual who would be interested in the project "Integrate > FreeType with alternative rendering engines" listed on FreeType's > GSoC page. Great to hear! > There were multiple things in the blog post that the entry linked to > that I found interesting/had questions about. > > 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. I think less than 256 levels of gray are a bad idea. Regardless of that, you have to compute the intersection of the glyph outline with pixels. Maybe there is a misunderstanding on my side, so please elaborate. > I would assume the parsing efficiency improvements mentioned in the > blog post wouldn't really be applicable to FreeType, as parsing in > such a way would inhibit more complex intermediate processes such as > hinting that font-rs doesn't seem to do. Please correct me if I am > wrong here. Fortunately, you are wrong :-) Hinting is always applied to the outline before it gets rasterized. In other words, font rendering is not affected by hinting. > Would use of SIMD entail an approach like that used by pixman, where > hand-coded assembly is made for each SIMD instruction set > extenstion? If so, which extentions would be pursued. I personally > would love to try and learn to write optimized routines in assembly > with less-used extensions like MMX or PowerPC AltiVec, but I was > curious as to how relevant these platforms are viewed as. Mhmm. Having assembly code in FreeType doesn't enthuse me. This would be a last resort for hotspots if low-level C programming doesn't give enough speed. The more generic the code, the less hassle we have to maintain it. > I apologize for how behind I am in the proposal process. [...] No problem :-) Werner
GSoC 2022: Alternative Rendering Engines
Greetings, I am an individual who would be interested in the project "Integrate FreeType with alternative rendering engines" listed on FreeType's GSoC page. There were multiple things in the blog post that the entry linked to that I found interesting/had questions about. 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. I would assume the parsing efficiency improvements mentioned in the blog post wouldn't really be applicable to FreeType, as parsing in such a way would inhibit more complex intermediate processes such as hinting that font-rs doesn't seem to do. Please correct me if I am wrong here. Would use of SIMD entail an approach like that used by pixman, where hand-coded assembly is made for each SIMD instruction set extenstion? If so, which extentions would be pursued. I personally would love to try and learn to write optimized routines in assembly with less-used extensions like MMX or PowerPC AltiVec, but I was curious as to how relevant these platforms are viewed as. About me, I am an undergraduate physics/engineering student at a mid-size university in the United States. I have made contributions to the Cairo vector graphics library before, although the part I contributed to is not widely used. I am hoping that at least some of this knowledge will be applicable to the task at hand. I apologize for how behind I am in the proposal process. If it is still workable for me to submit a proposal this late, I very much look forward to learning more about and working with FreeType and its community. In any case, I am grateful for the effort taken to present this wonderful opportunity. Regards, George
