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.
I tested your example with my functional bitmap APIs (with arguments memorized, and it only creates one bitmap% when combining a list of shapes), as expected it is too slow(<3s, without memorizing it's <6s) to stand with, but it also indicates that half or less time used is not creating or drawing single primitive shapes, but every primitive shape is rendered duplicately whenever its combining shape is rendering. So the issue is, to find a strategy to call `freeze` at a reasonable level of combined shapes. One reason that you may have to write your own combiner(here the term should be "layout") is, `freeze` can make a big shape, but it cannot avoid the duplicate rendering since it actually do the drawing. So your combiner would focus on providing the position and size information for dc to `draw` or `copy` and/or `rotate/flip`. Sounds hard to do it with fewer bugs. On Fri, Apr 28, 2017 at 9:32 PM, Daniel Prager <daniel.a.pra...@gmail.com> wrote: > 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 rendering to dc, >> and treat the closure as a representation for the image? Then let the >> image and pict combiners operate on the closures to produce more >> closures? > > > > Alex: > > I'm using rendering to a bitmap% in the case of the pict library as a > proxy for direct rendering to a dc. I would certainly render directly if I > were to switch to pict. > > Timings vary on the actual layout in Quilt Explorer, depending on block > complexity. The 18 blocks at the bottom of the page are choices in block > layout / shading or color that the user can click on — that's the > "exploring" part. > > A "next level" improvement might be something similar to the "virtual dom" > pioneered (or at least popularised) by the react-js folk, to simplify and > reduce the cost of re-rendering. > > Dan > > > > > On Fri, Apr 28, 2017 at 11:05 PM, Alex Harsanyi <alexharsa...@gmail.com> > wrote: > >> 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 actual application you can draw directly to the canvas DC >> in the on-paint method, which would save a bitmap allocation and an >> intermediate draw step. >> >> > >> > Some work-in-progress ... >> > >> > The idea of Quilt Explorer is to use symmetry and randomness, combined >> with some user selection to create original quilt designs. >> >> looking at these designs, I think by the time you're done writing code >> that draws directly to a dc, the code will be just as slow as the pict >> code, and probably with more bugs. >> >> Also, it seems you are rendering about 20 designs on the page. >> >> How long does it take to render an actual quilt design? >> >> Best Regards, >> Alex. > > -- > 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. > -- 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.
