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 on the fly: bitmap-*-append... cpu time: 386 real time: 387 gc time: 20 bitmap-table... cpu time: 381 real time: 381 gc time: 10 with memorizing (only 2 distinguishable bitmaps are generated): bitmap-*-append... cpu time: 85 real time: 85 gc time: 0 bitmap-table... cpu time: 93 real time: 94 gc time: 23 Still slower than pict, but as a raster graphics API, it does a great job! On Sat, Apr 29, 2017 at 11:19 AM, WarGrey Gyoudmon Ju <juzhenli...@gmail.com > wrote: > > > On Sat, Apr 29, 2017 at 5:21 AM, Daniel Prager <daniel.a.pra...@gmail.com> > 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 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 >>> numbers of shapes. Maybe you want to check the code of `table` in pict-lib, >>> it is a good example to place shapes into grids in a functional way. >>> >> >> Interesting. I'd also note that unlike pict 2htdp/image doesn't provide a >> way to draw direct to dc, necessitating going via bitmaps when using it in >> conjunction with racket/gui. >> > > Actually, this is not the case, every 2htdp/image shape is a subclass of > snip%(see the `draw` method of snip%), though you have to compute another 9 > arguments... > > I remembered some points that old conversations had suggested: > 1. 2htdp/image is not efficient enough for building real world gui > application, racket/draw should be used instead. > 2. When drawing large amount of shapes, the cost of getting into and out > the drawing context is critical. > 3. typed racket is helpful even for real time rendering, say, perlin > noise, almost as fast as java, (but I did not see the direct link between > your work and real time rendering.) > > Good luck for you. > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
