ADAM7InterpolatingFilter is a perfect candidate for SIMD. Let's use it on architectures that support it.

How complex is this work, would you say? Something we could get an intern to do?

(In reply to Milan Sreckovic [:milan] from comment #1) > How complex is this work, would you say? Something we could get an intern > to do? Definitely something an intern could do. Lee would be a good person to advise them, I'd say, although I hate to volunteer him for the job without his permission. But worth asking him.

CC'ing Lee.

(In reply to Seth Fowler [:seth] [:s2h] from comment #3) > CC'ing Lee. I could either work on this or advise someone who has enough experience with using SSE intrinsics. I guess it depends on how badly/soon you want it done. So, questions - how much of a bottleneck is the interpolation? Do we have any tests, talos or otherwise, that would be expected to move measurably on numbers based on reworking this bit of code?

(In reply to Lee Salzman [:lsalzman] from comment #4) > I could either work on this or advise someone who has enough experience with > using SSE intrinsics. I guess it depends on how badly/soon you want it done. It isn't urgent. We've been using a non-SIMD implementation for ADAM7 interpolation for a long time now, so it's the status quo. > So, questions - how much of a bottleneck is the interpolation? Do we have > any tests, talos or otherwise, that would be expected to move measurably on > numbers based on reworking this bit of code? I doubt we have performance tests for this. However, it wouldn't be hard to write one. I believe gfx/ is using GTest-based performance tests, and if so we could probably reuse whatever approach is used there for this, since an entire browser is not necessary to test this - just the PNG decoder. It's unclear to me how much of a bottleneck interpolation is to decoding of interlaced PNG images. That's something else that'd be worth checking. There's reason to believe it may be significant. On the first pass, for example, 7 out of every 8 rows are interpolated rather than decoded, and even though decoding a row is undoubtedly much more expensive than interpolating it I wouldn't be surprised to learn that interpolation becomes pretty visible on the profile once the image (and hence the rows that need to be interpolated) get larger. It'd definitely be worth verifying this assumption, though.

If this is still open to work on, I would like to grab this opportunity and improve my SIMD coding skills. I have looked at the relevant code (I think the entire implementation is in SurfaceFilters.h, and InterpolateByte is where the real action goes down) and I think I can push out a (very basic) patch soon enough. I would still need a few pointers though (sorry, I am still new to this area of the codebase :( ), so if that's going to be a problem feel free to turn me down.

Yes, this is available to be worked on, no one else is working on it that I am aware. I assigned the bug to you. You can contact me or Lee by email or irc (or in this bug) for pointers. Don't hesitate to ask if you have any questions.