<div class="gmail_quote">2011/4/11 Siarhei Siamashka <span dir="ltr"><<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>></span><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Mon, Apr 4, 2011 at 7:12 PM, Taekyun Kim <<a href="mailto:podain77@gmail.com">podain77@gmail.com</a>> wrote:<br>> I've done some additional work on overlapped blit functions and bilinear<br>
> filter with A8 mask for operator OVER and ADD.<br>> (tight scheduled work here...)<br><br></div>About these things. I would really appreciate if you could send the<br>latest variants of your patches if you don't mind to contribute them<br>
to pixman,<br><br>I understand that you need this functionality right now and any<br>improvement over the slow general C code is a great help for many<br>pixman users. I'm just approaching the problem in a bit different way<br>
- first try to tweak the code to make it as fast as possible, and only<br>then extend and generalize it to support more operations. For example,<br>it would really suck to implement a few dozens of optimized NEON fast<br>
path functions for various operations, and only then realize that<br>doing it in a completely different way would have provided maybe<br>something like 10% more performance. Anyway, here we have some<br>conflict of interests between us, which would be really nice to<br>
resolve somehow.<br><br>I wonder if the best solution for everyone would be to just add the<br>first generation of NEON fast paths for these OVER and ADD operations<br>developed by you if they don't cause any regressions. Maybe in such a<br>
way that they use their own set of helper macros. And at the same time<br>continue tweaking one more experimental implementation, trying to get<br>a 'perfect' bilinear scaling code (with another set of helper macros<br>
in order to avoid any clash). That would help us to get a reasonable<br>performance for many scaled compositing operations right now, just in<br>time for pixman 0.22.0 release. A drawback is that there will be some<br>extra code duplication, but eventually we would be able clean it up<br>
and ensure that only the fastest code remains in the future.<br><br>What do you think? And surely also the opinion of Soeren is important here.<br></blockquote></div>
<div>I like this approach.</div>
<div>Users can benefit from reasonably optimized functions for various operators, while we are struggling with extreme optimization work.</div>
<div>But currently there are some minor bugs with my patches.</div>
<div>I can send the patches with these bugs fixed.<br clear="all"><br>-- <br>Best Regards, </div>
<div>Taekyun Kim</div><br>