> I think we're OK. I shut down a lot of apps, including SF, started SF
and
> the cube again, and let it run for hours without incident. However, the
> cube's window was opened almost to full screen during the time that this
> happened. I have seen painting stop in regular GDI windows when the
window
> is large and I'm moving it around the screen and off the screen,
> occasionally. When the window is clipped at the edge of the screen, the
> WM_PAINTs seem to stop flowing. Has anyone seen this? Is it just an
> incompletely coded winproc, a bug in Windows, or a bug in SF's interface
to
> Windows? I just thought the two events might have a common root.
>
>
> Shaping

Possibly your computer is tired ! this small example draw

  8 x 8 x 12 (tube) + 16 x 16 x 4 (spheres) = 1792 polygons

Also possibly your graphic card don't have good support for OpenGL ?

Notice that the used memory is very relative to the window-size: in 24 bit
true color mode, the used memory can be estimated:

1 pixel =
        3 bytes for the color buffer,
        4 bytes for the depth buffer
        and 3 bytes again for the swap buffer.
total = 10 bytes.

In 1024x768 full screen: 1024x768 x 10 = ~ 8 MByte !

This big memory is to manage, paint and display. The slow result is not
caused by SwiftForth but by OpenGL. Faster animation are possible with few
colors (256 colors with palette mode) but not used here.

Charles

.
Received on Mon Sep 27 1999 - 14:53:17 PDT