ah yes it needs the 32 bit libs of cairo, yeah good luck with that, cant wait till we finally support 64 bit, but far my most needed feature of pharo. No idea how to find 32 bit lib of cairo, google returns nothing meaningful, download page of cairo website mentions nothing.
On Tue, Jan 19, 2016 at 2:52 PM Dimitris Chloupis <kilon.al...@gmail.com> wrote: > does not work for me on ubuntu it keeps saying that "cannot locate cairo > library" even though its installed via > > sudo apt-get install libcairo2-dev > > By the way just for the fun, I will make a benchmark comparison betweem > PNG loader in pharo and SDL in C to see what is the speed difference and > dust off my C skills. > > On Tue, Jan 19, 2016 at 2:22 PM Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> Yesterday I tested creating PNGs from disk using Athens: >> >> [(AthensCairoSurface >> createFromFile: '/Users/esteban/Dev/Pharo/pharo50/Lenna.png' >> ifFailed: [ ]) >> asForm] bench. >> >> That gave me 46k/s … (455k image) which IMO is pretty reasonable :) >> >> Esteban >> >> > On 19 Jan 2016, at 12:34, Sven Van Caekenberghe <s...@stfx.eu> wrote: >> > >> > >> >> On 19 Jan 2016, at 12:29, PBKResearch <pe...@pbkresearch.co.uk> wrote: >> >> >> >> Denis >> >> >> >> Very interesting. It would be more interesting if you could save your >> test image as a .png file, and then include reading with PNGReadWriter in >> your comparison. This would help to confirm or refute the original point >> made by Dimitris, that reading from .png is particularly slow. >> > >> > Check the original thread/case, it is slow. Not *very* slow, but slower >> than the plugin based JPEG reader. That is what we eventually need, a >> plugin base PNG reader. >> > >> >> Peter Kenny >> >> >> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On >> Behalf Of Denis Kudriashov >> >> Sent: 19 January 2016 10:59 >> >> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> >> >> Subject: Re: [Pharo-users] Creation form from PNG file very slow on >> Pharo 4 and 5 >> >> >> >> >> >> 2016-01-19 11:34 GMT+01:00 Dimitris Chloupis <kilon.al...@gmail.com>: >> >>> most likely fuel, since it stores your live object as is. >> >>> >> >>> I like fuel but the fact that I may be limited by incompatible >> versions is a game stopper for me. I am ok with new version between >> incompatible with old one but there must be some backward compatibility to >> any format I use. Or else I end up worrying about things I should not be >> worrying about. >> >> >> >> You are right. I perform little experiment. Fuel reading is 60% faster >> than BMP: >> >> >> >> Smalltalk garbageCollect; garbageCollect. >> >> r1 := [FileLocator imageDirectory / 'test.bmp' readStreamDo: [ :s | >> >> s binary. >> >> fromBMP := BMPReadWriter formFromStream: s]] benchFor: 2 seconds. >> >> >> >> Smalltalk garbageCollect; garbageCollect. >> >> r2:=[FileLocator imageDirectory / 'test.fuel' readStreamDo: [ :s | >> >> s binary. >> >> fromFuel := (FLMaterializer newDefault materializeFrom: s) root]] >> benchFor: 2 seconds. >> >> >> >> { r1. r2 } "an Array(a BenchmarkResult(2,199 iterations in 2 seconds 2 >> milliseconds. 1,098 per second) a BenchmarkResult(5,728 iterations in 2 >> seconds 3 milliseconds. 2,860 per second))" >> > >> > >> >> >>
