prawn-fast-png

[Wojtek Piekutowski]

Hi,

I've 'solved' the issue with embedding large PNGs with alpha channel
with RMagick.

You can find the code here:
http://github.com/amberbit/prawn-fast-png/tree/master

It passes all specs.

I see 2 ways to proceed:
- creating a new gem, so that main lib doesn't have RMagick dependency
(RMagick had memory leaks in the past, I'm not sure what's the current
status)
- merging this to core and using this solution only when RMagick is
installed, otherwise falling back to the current code

Which one is preferred?

Greetings,
Wojciech

[Gregory Brown]

I actually don't know. It depends on what users want. I am okay
with the optional dependency, but if people really hate RMagick (and I
know many do), it'd be better as its own gem.

What does everyone think? I'm a bit hesitant to include this in core
because I don't plan to test / maintain it because I have no desire to
install RMagick.

-greg

[Gregory Brown]

On Sat, Apr 4, 2009 at 8:12 PM, Gregory Brown <gregory...@gmail.com> wrote:
> On Sat, Apr 4, 2009 at 8:07 PM, Wojtek Piekutowski
> <w.piek...@gmail.com> wrote:
>>
>> Hi,
>>
>> I've 'solved' the issue with embedding large PNGs with alpha channel
>> with RMagick.

And btw, thanks for this. I'm sure it's going to make some of our
users pretty happy.

-greg

[Wojciech Piekutowski]

On Sun, Apr 5, 2009 at 02:13, Gregory Brown <gregory...@gmail.com> wrote:
> And btw, thanks for this.  I'm sure it's going to make some of our
> users pretty happy.

I'm happy to help. :) Thanks for creating Prawn for you and all
contributors in the first place.

Greetings,
Wojciech

[otaviofcs]

I'm happy you did it Wojciech! A faster PNG and add the ability to
incorporate ps files are, definitely, big thing to prawn.

I think it should be added in a different gem, not in prawn-core.
Mainly because of it's (RMagick) memory consumption (and leaks also)
that won't please everyone. I'll definitely take a look at your code.

Thanks.

[otaviofcs]

You really made a simple hack :)

A roughly benchmark:

Without prawn-fast-png:

real 0m0.945s
user 0m0.864s
sys 0m0.080s

With prawn-fast-png:

real 0m0.333s
user 0m0.288s
sys 0m0.044s

Looks nice....

[Wojciech Piekutowski]

On Mon, Apr 6, 2009 at 15:53, otaviofcs <osam...@riopro.com.br> wrote:
>
> You really made a simple hack :)

I'm a big fan of the KISS principle. :)

Profiling of my test script showed that it was spending most of its
time in PNG#unfilter_image_data. I've decided to speed up this method
first and see if the performance I get would be enough. Optimizing
Ruby code gave only minor speedups, so I've looked at RMagick.

There are many more possibilities for using RMagick in Prawn, but the
benefits may not be worth the hassle.

> A roughly benchmark:
>
> Without prawn-fast-png:
>
> real    0m0.945s
> user    0m0.864s
> sys     0m0.080s
>
> With prawn-fast-png:
>
> real    0m0.333s
> user    0m0.288s
> sys     0m0.044s
>
> Looks nice....

Your benchmark shows some speed up, but I wouldn't have messed with
RMagick for such a small improvement. You either have a speedy machine
there or you are embedding a small image. I needed to insert
~1000x4000 sized PNGs with alpha channel and that was simply not
possible with clean Ruby.

My non-scientific benchmark (dice.png):
without prawn-fast-png
real 0m5.102s
user 0m3.784s
sys 0m0.364s

with prawn-fast-png
real 0m0.482s
user 0m0.324s
sys 0m0.048s

So around 10x difference.

From my tests the size of the image increases, execution time grows
pretty fast. Now imagine how long it would take to insert 1000x4000
PNG? :)

Greetings,
Wojciech

[Gregory Brown]

On Mon, Apr 6, 2009 at 11:01 AM, Wojciech Piekutowski
<w.piek...@gmail.com> wrote:

> Your benchmark shows some speed up, but I wouldn't have messed with
> RMagick for such a small improvement. You either have a speedy machine
> there or you are embedding a small image.

Or a PNG without alpha layers. Prawn is only slow when it needs to
split out the alpha channel.
Something like 1s seems 'fine' to me.

> I needed to insert
> ~1000x4000 sized PNGs with alpha channel and that was simply not
> possible with clean Ruby.
>
> My non-scientific benchmark (dice.png):
> without prawn-fast-png
> real    0m5.102s
> user    0m3.784s
> sys     0m0.364s
>
> with prawn-fast-png
> real    0m0.482s
> user    0m0.324s
> sys     0m0.048s
>
> So around 10x difference.

Yep, there's the bottleneck, and a very nice result with your patch Wojciech.
Why don't we have you run this as a third party extension for now
(like Prawnto) and see how it goes?
I'll add a link in the README and image API docs once you have something up.

Feel free to use the Prawn mailing list if you wish to discuss this
extension with its users. Even if it's an "unofficial" project for
now, it's something I'd be happy to support.

-greg

[otaviofcs]

Yes, the way prawn "officially" deals with png images progressively
looses performance when the image increases size and uses
alphachannel. So, the bigger the image the more useful is your new gem.

[Wojciech Piekutowski]

On Mon, Apr 6, 2009 at 17:06, Gregory Brown <gregory...@gmail.com> wrote:
> Why don't we have you run this as a third party extension for now
> (like Prawnto) and see how it goes?
> I'll add a link in the README and image API docs once you have something up.
>
> Feel free to use the Prawn mailing list if you wish to discuss this
> extension with its users.  Even if it's an "unofficial" project for
> now, it's something I'd be happy to support.

Sounds good! At this point I was thinking about releasing it as a gem
through GitHub. Any thoughts on this?

Greetings,
Wojciech

[Gregory Brown]

Though I think any serious gem deserve distribution through RubyForge,
that's fine by me, go for it.

-greg

[Wojciech Piekutowski]

On Tue, Apr 7, 2009 at 00:26, Gregory Brown <gregory...@gmail.com> wrote:
>
> Though I think any serious gem deserve distribution through RubyForge,
> that's fine by me, go for it.
>

Gem is available now on GitHub as amberbit-prawn-fast-png.

Ok, let's distribute it through RubyForge too. I'm waiting for the new
project approval from RF admins.

Greetings,
Wojtek