Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Tue, May 2, 2017 at 8:02 PM, Daniel Prager wrote: > Hi Ju > > Interesting results. Did you run the Contract Profiler tool? [ > http://docs.racket-lang.org/contract-profile/] > > I think it's fairly well understood that the contract-induced performance > costs across

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Hi Ju Interesting results. Did you run the Contract Profiler tool? [ http://docs.racket-lang.org/contract-profile/] I think it's fairly well understood that the contract-induced performance costs across the typed / untyped boundary can be severe. BTW: At the back of my mind is the thought that

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Hello, I found an interesting thing. My conclusion was totally wrong since your example are written in Untyped Racket, the generated contracts eat all the seconds unconsciously. Timing your example in Typed Racket with my functional bitmap combiners: no optimizing, generating all 2500 bitmaps

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Sat, Apr 29, 2017 at 11:44 PM, Robby Findler wrote: > On Sat, Apr 29, 2017 at 3:18 AM, Daniel Prager > wrote: > > On Sat, Apr 29, 2017 at 6:04 PM, Philip McGrath < > phi...@philipmcgrath.com> > > wrote: > >> > >> I think that would be

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Sat, Apr 29, 2017 at 3:18 AM, Daniel Prager wrote: > On Sat, Apr 29, 2017 at 6:04 PM, Philip McGrath > wrote: >> >> I think that would be because "the draw is called during the dynamic >> extent of the call to dc as part of the contract

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Sat, Apr 29, 2017 at 6:04 PM, Philip McGrath wrote: > I think that would be because "the *draw* is called during the dynamic > extent of the call to dc >

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

I think that would be because "the *draw* is called during the dynamic extent of the call to dc as part of the contract checking." -Philip On Sat, Apr 29, 2017 at 2:58 AM, Daniel

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Thanks for all the suggestions. I was able to get pict down to "direct to dc"-like performance by making a custom pict that calls my direct-to-dc code ... (define (pict:render block) (pict:dc (λ (dc dx dy) (define old-brush (send dc get-brush)) (define old-pen (send dc

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Sat, Apr 29, 2017 at 5:21 AM, Daniel Prager wrote: > On Sat, Apr 29, 2017 at 2:10 AM, WarGrey Gyoudmon Ju < > juzhenli...@gmail.com> wrote: > >> Hello, I think the main reason that pict is faster than 2htdp/image is, >> the pict is implemented with struct while the

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Sat, Apr 29, 2017 at 2:10 AM, WarGrey Gyoudmon Ju wrote: > Hello, I think the main reason that pict is faster than 2htdp/image is, > the pict is implemented with struct while the 2htdp/image is implemented > with class, the speed of rendering is just as fast/slow as

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Hello, I think the main reason that pict is faster than 2htdp/image is, the pict is implemented with struct while the 2htdp/image is implemented with class, the speed of rendering is just as fast/slow as each other, but manipulation on class is much heavier than on struct when combining large

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Thanks Hendrik & Alex Hendrik: What you're suggesting sounds to me a lot like what the pict library already does. Switching to pict would seem to give a good speed-up, but perhaps it's possible to do better. Hence the benchmarking exercise. Perhaps make a closure that, when called, does the

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Friday, April 28, 2017 at 6:40:06 PM UTC+8, Daniel Prager wrote: > The reason is that what I really want to do is more complex layouts, for > which 2htdp/image or pict combiners make life a lot easier. The code to convert to bitmap allocates the bitmap and draws to the bitmap. In the

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Fri, Apr 28, 2017 at 08:39:33PM +1000, Daniel Prager wrote: > > Now, you may be wondering why I want to keep using 2htdp/image if I already > have code to directly draw to dc > > The reason is that what I really want to do is more complex layouts, for > which 2htdp/image or pict combiners

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

On Thu, Apr 27, 2017 at 12:34 PM, Vishesh Yadav wrote: > >> BTW: I'm interested in porting to RacketScript. How does the performance >> of the image library equivalent compare with regular Racket? >> >> > It is slower than regular Racket. I did not spend much time comparing

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

> > > BTW: I'm interested in porting to RacketScript. How does the performance > of the image library equivalent compare with regular Racket? > > It is slower than regular Racket. I did not spend much time comparing it with Racket, and there is definitively scope for improvement. Let us know how

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Thank-you all for the suggestions. I'll check them out and report back. Vishesh: There is some repetition (not animation), but I removed all caching to simplify and rework the interactive flow. It would be with trying freeze in conjunction with updated caching. BTW: I'm interested in porting to

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Are you repeatedly generating image for an animation inside an event loop? Depending on the kind of program `freeze` from 2htdp/image may help if you haven't tried already. For example this[1] program renders faster with freeze both in RacketScript and 2htdp/image. [1]

Re: [racket-users] Speeding up graphics / moving away from 2htdp/image

Hi Daniel, I have a functional bitmap library[1] as a part of my CSS engine. This library is inspired by the official pict-lib and flomap(images-lib), and handles bitmap% directly. I don't think it is efficient enough since every functional operation creates another bitmap%. Here I recommend you