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

[WarGrey Gyoudmon Ju]

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 the typed / untyped boundary can be severe.
>

No, I didn't run the Contract Profiler tool.

I just wanted to optimize it, the weirdest thing I found is, the total time
is much larger then the sum of the in-function `time`s, I guess all bitmaps
are checked one by one by the contract system, they are all objects.

Last time I mentioned the flomap, I said "You need to convert the flomap
struct into a bitmap% instance when drawing", the main reason is that
nobody seems to maintain the images-lib, and it's Bitmap% is not the
standard one since it exists before typed class is available, therefore the
`flomap->bitmap` will simply fail due to the contract error. There is a
pull request for it, but still has not been merged since 2015. [
https://github.com/racket/images/pull/2]



> BTW: At the back of my mind is the thought that the performance one could
> achieve on these kinds of benchmarks would go up ridiculously by pushing
> the work to a GPU.
>

Yeah, some games shipped with the main distribution are written in
racket-wrapped OpenGL. Despite the totally different APIs, you can try real
time rendering algorithms without worrying about the performance. In fact,
I am hesitating too, I have already finished the computational model of the
CSS engine, but not sure whether the GUI part should be implemented with
OpenGL or not. Designing application as a Game UI developer is fun, but
meanwhile I do not have much time to do that.

-- 
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.

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

[Daniel Prager]

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 the performance one could
achieve on these kinds of benchmarks would go up ridiculously by pushing
the work to a GPU.

Dan


On Tue, May 2, 2017 at 8:06 PM, WarGrey Gyoudmon Ju 
wrote:

> 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!
>
>

-- 
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.

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

[WarGrey Gyoudmon Ju]

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  wrote:

>
>
> 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 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.

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

[Daniel Prager]

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 because "the draw is called during the dynamic
> >> extent of the call to dc as part of the contract checking."
> >
> >
> >  That explains it!
> >
> > I think I can take the performance hit — it would be nice to have
> > fine-grained control of contract-checking for these expensive checks,
> > though.
>
> I've added unsafe-dc that skips the pre-condition check.
>
> Robby
>

Thanks!

Dan

-- 
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.

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

[Robby Findler]

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 checking."
>
>
>  That explains it!
>
> I think I can take the performance hit — it would be nice to have
> fine-grained control of contract-checking for these expensive checks,
> though.

I've added unsafe-dc that skips the pre-condition check.

Robby

-- 
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.

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

[Daniel Prager]

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 checking."
>

 That explains it!

I think I can take the performance hit — it would be nice to have
fine-grained control of contract-checking for these expensive checks,
though.

Dan

-- 
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.

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

[Philip McGrath]

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 Prager 
wrote:

> 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 get-pen))
> (dc:draw dc block dx dy)
> (send dc set-brush old-brush)
> (send dc set-pen old-pen))
> (* *size* *n*) (* *size* *n*)))
>
>
> My only remaining question is why pict calls the custom code on
> construction, as well as on rendering.
>
> (displayln "Render, then convert to bitmap%...")
> (define pict:c1 (time (pict:render b1)))
> (define p1 (time (pict->bitmap% pict:c1)))
>
>
> Dan
>
>
> Revised timings ...
>
>
> SQUARES
> ===
>
> 2htdp/image
> ---
> Render, then convert to bitmap%...
> cpu time: 134 real time: 136 gc time: 46
> cpu time: 344 real time: 355 gc time: 60
>
> pict
> 
> Render, then convert to bitmap%...
> cpu time: 80 real time: 87 gc time: 0
> cpu time: 83 real time: 84 gc time: 13
>
> direct to dc
> 
> Render direct to bitmap%...
> cpu time: 67 real time: 68 gc time: 0
>
>
> TRIANGLES
> =
>
> 2htdp/image
> ---
> Method 1 - Render, then convert to bitmap%...
> cpu time: 542 real time: 559 gc time: 76
> cpu time: 606 real time: 622 gc time: 63
>
> Method 2 - Render, then convert to bitmap%...
> cpu time: 332 real time: 337 gc time: 51
> cpu time: 539 real time: 550 gc time: 62
>
> Method 3 - Render, then convert to bitmap%...
> cpu time: 223 real time: 230 gc time: 37
> cpu time: 276 real time: 279 gc time: 25
>
>
> pict
> 
> Render, then convert to bitmap%...
> cpu time: 176 real time: 173 gc time: 22
> cpu time: 188 real time: 188 gc time: 9
>
> direct to dc
> 
> Render direct to bitmap%...
> cpu time: 193 real time: 194 gc time: 16
>
> --
> 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.

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

[Daniel Prager]

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 get-pen))
(dc:draw dc block dx dy)
(send dc set-brush old-brush)
(send dc set-pen old-pen))
(* *size* *n*) (* *size* *n*)))


My only remaining question is why pict calls the custom code on
construction, as well as on rendering.

(displayln "Render, then convert to bitmap%...")
(define pict:c1 (time (pict:render b1)))
(define p1 (time (pict->bitmap% pict:c1)))


Dan


Revised timings ...


SQUARES
===

2htdp/image
---
Render, then convert to bitmap%...
cpu time: 134 real time: 136 gc time: 46
cpu time: 344 real time: 355 gc time: 60

pict

Render, then convert to bitmap%...
cpu time: 80 real time: 87 gc time: 0
cpu time: 83 real time: 84 gc time: 13

direct to dc

Render direct to bitmap%...
cpu time: 67 real time: 68 gc time: 0


TRIANGLES
=

2htdp/image
---
Method 1 - Render, then convert to bitmap%...
cpu time: 542 real time: 559 gc time: 76
cpu time: 606 real time: 622 gc time: 63

Method 2 - Render, then convert to bitmap%...
cpu time: 332 real time: 337 gc time: 51
cpu time: 539 real time: 550 gc time: 62

Method 3 - Render, then convert to bitmap%...
cpu time: 223 real time: 230 gc time: 37
cpu time: 276 real time: 279 gc time: 25


pict

Render, then convert to bitmap%...
cpu time: 176 real time: 173 gc time: 22
cpu time: 188 real time: 188 gc time: 9

direct to dc

Render direct to bitmap%...
cpu time: 193 real time: 194 gc time: 16

-- 
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.

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

[WarGrey Gyoudmon Ju]

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 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.

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

[Daniel Prager]

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 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.


> 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.
>

My thinking has been to strip back to simpler strategies initially to see
how much speed is possible, then apply freezing and caching strategies
later, if applicable. (Something, something "premature optimization ...
evil" ;-)


>
> 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.
>

Before resorting to writing my own combiner / layout I think I'll see what
performance I can get from a custom "block" pict. From the pict library's
POV this would reduce the number of picts in my examples from 1000s to 1.

Thanks

Dan

-- 
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.

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

[WarGrey Gyoudmon Ju]

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 
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 
> 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.

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

[Daniel Prager]

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 
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.

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

[Alex Harsanyi]

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.

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

[Hendrik Boom]

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 make life a lot easier.

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?

You do have a functional language to work with.  You can use it as 
such.

-- hendrik

-- 
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.

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

[Daniel Prager]

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 it
> with Racket, and there is definitively scope for improvement. Let us know
> how porting goes.
>

Thanks: it's on my list.

I may try to do some reduced-case benchmarks for a few approaches in
Racket, and for RacketScript.

Dan

-- 
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.

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

[Vishesh Yadav]

>
>
> 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 porting goes.

--Vishesh


> Dan
>
> On 26 Apr. 2017 15:30, "Vishesh Yadav"  wrote:
>
> 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] http://rapture.twistedplane.com:8080/#example/default
>
> --Vishesh
>
> On Tue, Apr 25, 2017 at 9:09 PM, Daniel Prager 
> wrote:
>
>> Much as I enjoy making images using 2htdp/image it does get a tad slow as
>> complexity increases.
>>
>> I currently have a program in which I generate images in 2htdp/image and
>> translate them into bitmap%s per racket/gui and render on canvas%'s via a
>> dc.
>>
>> Speed has become sluggish and I'm going to need to move away from
>> 2htdp/image to address this.
>>
>> A typical image is built up out of lots of above, beside, overlay,
>> square, and triangle calls.
>>
>> Does anyone have a "clever" way to do this programatically (rather than a
>> manual re-write with lots of absolute calculations replacing heights and
>> widths)?
>>
>> Many thanks
>>
>> Dan
>>
>>
>> --
>> 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.
>
>
>

-- 
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.

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

[Daniel Prager]

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 RacketScript. How does the performance of
the image library equivalent compare with regular Racket?

Dan

On 26 Apr. 2017 15:30, "Vishesh Yadav"  wrote:

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] http://rapture.twistedplane.com:8080/#example/default

--Vishesh

On Tue, Apr 25, 2017 at 9:09 PM, Daniel Prager 
wrote:

> Much as I enjoy making images using 2htdp/image it does get a tad slow as
> complexity increases.
>
> I currently have a program in which I generate images in 2htdp/image and
> translate them into bitmap%s per racket/gui and render on canvas%'s via a
> dc.
>
> Speed has become sluggish and I'm going to need to move away from
> 2htdp/image to address this.
>
> A typical image is built up out of lots of above, beside, overlay, square,
> and triangle calls.
>
> Does anyone have a "clever" way to do this programatically (rather than a
> manual re-write with lots of absolute calculations replacing heights and
> widths)?
>
> Many thanks
>
> Dan
>
>
> --
> 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.

-- 
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.

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

[Vishesh Yadav]

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] http://rapture.twistedplane.com:8080/#example/default

--Vishesh

On Tue, Apr 25, 2017 at 9:09 PM, Daniel Prager 
wrote:

> Much as I enjoy making images using 2htdp/image it does get a tad slow as
> complexity increases.
>
> I currently have a program in which I generate images in 2htdp/image and
> translate them into bitmap%s per racket/gui and render on canvas%'s via a
> dc.
>
> Speed has become sluggish and I'm going to need to move away from
> 2htdp/image to address this.
>
> A typical image is built up out of lots of above, beside, overlay, square,
> and triangle calls.
>
> Does anyone have a "clever" way to do this programatically (rather than a
> manual re-write with lots of absolute calculations replacing heights and
> widths)?
>
> Many thanks
>
> Dan
>
>
> --
> 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.

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

[WarGrey Gyoudmon Ju]

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 to take a look at the flomap, it is written in typed
racket and represents high precision
bitmap objects with flvector, composition and transformation should
therefore efficient. You just need to convert
the flomap struct into a bitmap% instance when drawing(you might need to
take care of the backing scale).

The basic composition is simple, you can write your own version within a
day, but the performance ceiling may
relate to Racket instead of algorithms you picked(since algorithms are
already simple enough). If performance
is really a problem, you may want to write your own library with Racket
Futures.

[1]https://github.com/wargrey/css/tree/master/bitmap

On Wed, Apr 26, 2017 at 12:09 PM, Daniel Prager 
wrote:

> Much as I enjoy making images using 2htdp/image it does get a tad slow as
> complexity increases.
>
> I currently have a program in which I generate images in 2htdp/image and
> translate them into bitmap%s per racket/gui and render on canvas%'s via a
> dc.
>
> Speed has become sluggish and I'm going to need to move away from
> 2htdp/image to address this.
>
> A typical image is built up out of lots of above, beside, overlay, square,
> and triangle calls.
>
> Does anyone have a "clever" way to do this programatically (rather than a
> manual re-write with lots of absolute calculations replacing heights and
> widths)?
>
> Many thanks
>
> Dan
>
>
> --
> 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.