Hi Doug,
Thanks for the response! I had indeed read about and tried you package,
even before I made my post. However, installing the animated-canvas package
with the package manager yields a bunch of warnings and errors. The lines
example in your documentation works, but the animated plot is extremely
laggy and doesn't seem to work. Also, installing the package created a lot
of problems with DrRacket, where uncloseable command line windows popped up
with errors and other instabilities (for example, DrRacket just crashing as
soon as it opened). I had to uninstall it, even when not using it. The
planet form also doesn't seem to work well to install the package
interactively.
I am not usually one to optimize early but have been concerned and hesitant
with getting too far into my project, knowing it will be heavy on graphics,
with some of the performance issues I've seen in Racket. The catch is that
Racket's pasteboard editor and draw library combined into a cross-platform
package is too attractive. At least it seems I'm not misunderstanding
something huge at this stage.
I'll forge on for the moment.
Thanks!
On Monday, January 11, 2021 at 11:02:39 AM UTC-6 m.douglas.williams wrote:
> While you may not be able to get high frame rates, there are some very
> nice animations that are easy to produce, particularly in conjunction with
> the plot package. Here is a short sample that animates a 3D plot.
>
> #lang racket/gui
>
> ;;; 3D animated plot example.
>
> (require plot
> (planet williams/animated-canvas/animated-canvas))
>
> (define (main delta t-last)
> (parameterize ((plot3d-samples 21))
> (let loop ((t 0.0))
> (define (f x y) (* (sin (* 2.0 x)) (sin (* 2.0 y)) (cos t)))
> (when (<= t t-last)
> (let* ((dc (send canvas get-dc))
> (width (send canvas get-width))
> (height (send canvas get-height)))
> (plot3d/dc (contour-intervals3d f 0 pi 0 pi)
> dc 0 0 width height
> #:z-min -1 #:z-max 1)
> (send canvas swap-bitmaps)
> (yield)
> (loop (+ t delta)))))))
>
> (define frame
> (instantiate frame% ("Test Plot Animation")))
>
> (define canvas
> (instantiate animated-canvas%
> (frame)
> (style '(border))
> (min-width 400)
> (min-height 300)))
>
> (send frame show #t)
>
> (main (* 0.05 pi) 20.0)
>
> Doug
>
> On Mon, Jan 11, 2021 at 9:45 AM Doug Williams <m.douglas...@gmail.com>
> wrote:
>
>> I use Racket regularly for animations and wrote an animated-canvas
>> package that does double buffering to smooth the animations for complex
>> animations. I think you are running into some fundamental issues with frame
>> rates possible with the drawing package in Racket. I have attached a
>> version of your code using the animated-canvas package. It isn't any
>> faster, but can (at least on my machine) handle 50,000 (or even 100,000)
>> lines, although slowly. If you need speed, you can try using the OpenGL
>> package.
>>
>> Doug
>>
>> On Sun, Jan 10, 2021 at 11:50 PM making-a-racket <bmitc...@gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> I am embarking upon a project to doing 2D graphics in Racket, so I am
>>> starting off with various experiments, some of which include testing out
>>> performance and replicating Processing examples.
>>>
>>> I definitely need to do some more reading, but I am wanting to post this
>>> to get some leads into ensuring I'm utilizing the best performance of the
>>> racket/draw library and for pointers to portions (or elaborations) of the
>>> documentation.
>>>
>>> In trying to reproducing the LineRendering example that ships with
>>> Processing, I'm seeing a big performance difference. The Processing sketch
>>> is:
>>>
>>> public void setup() {
>>> size(800, 600, P2D);
>>> }
>>>
>>> public void draw() {
>>> background(255);
>>> stroke(0, 10);
>>> for (int i = 0; i < 50000; i++) {
>>> float x0 = random(width);
>>> float y0 = random(height);
>>> float z0 = random(-100, 100);
>>> float x1 = random(width);
>>> float y1 = random(height);
>>> float z1 = random(-100, 100);
>>>
>>> // purely 2D lines will trigger the GLU
>>> // tessellator to add accurate line caps,
>>> // but performance will be substantially
>>> // lower.
>>> line(x0, y0, x1, y1);
>>> }
>>> }
>>>
>>> My Racket code which attempts to reproduce this example is this:
>>>
>>> #lang racket/gui
>>>
>>> (require racket/draw)
>>>
>>> (define WIDTH 800)
>>> (define HEIGHT 600)
>>>
>>> (define frame (new frame%
>>> [label "Lines"]
>>> [width WIDTH]
>>> [height HEIGHT]))
>>>
>>> (define pen (new pen%
>>> [color (make-object color% 0 0 0 0.1)]
>>> [width 1]
>>> [style 'solid]))
>>>
>>> (define (paint canvas dc)
>>> (send dc set-pen pen)
>>> (for ([i (in-range 10000)])
>>> (send dc draw-line
>>> (random 0 WIDTH)
>>> (random 0 HEIGHT)
>>> (random 0 WIDTH)
>>> (random 0 HEIGHT))))
>>>
>>> (define canvas (new canvas%
>>> [parent frame]
>>> [paint-callback paint]))
>>>
>>> (send frame show #t)
>>>
>>> (define (loop)
>>> (send canvas refresh-now #:flush? #t)
>>> (sleep/yield 0.033)
>>> (loop))
>>>
>>> (loop)
>>>
>>> However, I am not able to obtain anywhere near the performance of the
>>> Processing sketch, which can draw 50,000 lines at about 12-13fps. It can do
>>> 10,000 at about 40fps. My Racket example can barely do 10,000 lines and is
>>> definitely below 10fps. I am using Racket CS 7.9 on Windows 10 on an XPS 15
>>> i7 with dedicated GPU. Even p5.js' performance is well above the Racket
>>> sample but below the Processing sketch. Another thing that I have noticed
>>> is that the Processing sketch uses about 90% of the integrated GPU (not the
>>> dedicated) while Racket only uses about 6% of the integrated GPU. If I try
>>> to draw 50,000 lines, then Racket (usually) freezes up.
>>>
>>> Any thoughts or pointers? If I understood the documentation correctly,
>>> refresh-now seemed to be the way to get the best frame-by-frame
>>> performance, but I am certainly still learning. Am I simply hitting the
>>> performance limit of the racket/draw library or is there something I can do
>>> to improve things?
>>>
>>> I'm still in the programming language/environment selection phase of my
>>> project, but I would really like to use Racket here.
>>>
>>> Thanks for any help!
>>>
>>> --
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/racket-users/535064cd-bc10-42fe-a20a-30623d5b4ca3n%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/racket-users/535064cd-bc10-42fe-a20a-30623d5b4ca3n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/0734e963-1e64-4ff2-941f-91e37aeb9f30n%40googlegroups.com.
