rowett wrote:Things to check: ...
- What's the performance of the current LifeViewer? Press hotkey 'T' to turn on timing display in the top right of the Viewer window. The important figures are "work" followed by "menu".
- In order for smooth update the total needs to be less than 16ms per frame[./list]
My laptop is several years old, and can only manage work=12-15ms while running that animation. So in Build 146 I'm seeing frame rates hovering around 57-59fps, occasionally dropping down to 49 for a moment.
That's not the problem, though -- everything looks perfectly smooth as long as I just let the animation run, even if it's slightly slow. Here's how to make weird things happen:
- Let the animation run for a short time (doesn't seem to matter).
- Hit Pause.
- Drag the pattern about one screen width with the mouse. Optionally mousewheel zoom a bit.
- Hit Play again to continue the animation.
One thing that happens is maybe by design, but it's not what I expect: hitting Pause and then Play seems to cancel the LOOP setting but not the waypoint animation. Is there a way to tie those together, so that it's possible to pause and explore a pattern and then return to the normal animation behavior?
The other problem is that there are often several seconds as the viewpoint moves back to where it's supposed to be, where the work number goes steadily up: 32, then 276, then 1443 -- and then back suddenly to work=15ms again when the viewpoint gets back to normal. I know the viewer is capable of doing this zoom smoothly without breaking a sweat, but some big inefficiency seems to be creeping into the interpolation in this case.
Oddly enough, if you Pause, hit "F" to fit the whole pattern, and the Play, you don't see the problem. You also don't get a smooth zoom back to where the animation left off -- it just jumps instantly back to the correct point and continues from there. If you wait until the construction is almost done and then hit "F", you do see the choppiness.
Another issue:
I tried adding STEP 8 in -- not in the forum posting, since Build 144 doesn't handle steps mixed with waypoints very well, but with Build 146. Without waypoints the pattern runs very smoothly at STEP 8, but when an animation is running I get numbers like work=1907.
----------------------------
Here's a mostly unrelated item. The way the math works out, a linear interpolation between zoom levels tends to go through suboptimal intermediate views. For example:
Code:
Select all
x = 826, y = 829, rule = B3/S23
2o2b3o$2o2bo$5bo14$30b3o$30bo$31bo34$32b3o$32bo$33bo14$70b3o$70bo$71bo
14$54b3o$54bo$55bo14$105b3o$105bo$106bo14$89b3o$89bo$90bo14$137b3o$
137bo$138bo14$118b3o$118bo$119bo14$177b3o$177bo$178bo14$142b3o$142bo$
143bo14$206b3o$206bo$207bo14$187b2o$186b2o$188bo14$235b2o$234b2o$236bo
19$207b3o$207bo$208bo9$268b3o$268bo$269bo9$256b3o$256bo$257bo19$298b3o
$298bo$299bo30$330b3o$330bo$331bo6$308b3o$308bo$309bo18$331b3o$331bo$
332bo2$363b2o$362b2o$364bo14$358b3o$358bo$359bo14$407b3o$407bo$408bo
14$391b3o$391bo$392bo14$424b2o$423b2o$425bo14$415b2o$414b2o$416bo14$
468b3o$468bo$469bo14$454b3o$454bo$455bo14$489b3o$489bo$490bo14$474b2o$
473b2o$475bo14$514b3o$514bo$515bo14$499b3o$499bo$500bo14$544b3o$544bo$
545bo14$543b3o$543bo$544bo14$593b3o$593bo$594bo26$598b3o$598bo$599bo2$
625b3o$625bo$626bo14$616b3o$616bo$617bo14$667b3o$667bo$668bo14$637b3o$
637bo$638bo14$669b3o$669bo$670bo14$669b3o$669bo$670bo14$704b3o$704bo$
705bo14$698b3o$698bo$699bo14$744b3o$744bo$745bo14$723b3o$723bo$724bo
14$764b3o$764bo$765bo14$763b3o$763bo$764bo36$823b3o$823bo$824bo!
[[ AUTOSTART X 0 Y 0 ZOOM .5 THEME 9 LOOP 3400 ]]
[[ PAUSE 5 "Zooming in starting at T=200..." ]]
[[ T 200 ]]
[[ T 3200 X -410 Y -410 ZOOM 12 ]]
In general, let's say we're zooming from Waypoint 1 (X1, Y1 @ Z1) to Waypoint 2 (X2, Y2 @ Z2). If (X2,Y2) is visible in the Waypoint 1 view, and obviously it will be in view at Waypoint 2, then is there a way to set up the interpolation so as not to lose sight of it so thoroughly in the middle? Is there a plausible formula that will keep the zoom level lower until right near the end?
Seems to me that a good default interpolation for the above case might be something closer to a continuous autofit. Maybe that could just be a script option? (I think I've mentioned something like this before, but maybe not very clearly.) It's surprisingly difficult to do a continuous autofit with the current system -- you'd need a
lot of waypoints to smooth it out enough.
For this pattern, ten waypoints still make me a little queasy... not counting the sudden angle change at the end, which is maybe not such a good idea. As the animation runs you can see the construction area moving in different directions at different times. Gets worse toward the end, especially at T=2900:
Code:
Select all
x = 826, y = 829, rule = B3/S23
2o2b3o$2o2bo$5bo14$30b3o$30bo$31bo34$32b3o$32bo$33bo14$70b3o$70bo$71bo
14$54b3o$54bo$55bo14$105b3o$105bo$106bo14$89b3o$89bo$90bo14$137b3o$
137bo$138bo14$118b3o$118bo$119bo14$177b3o$177bo$178bo14$142b3o$142bo$
143bo14$206b3o$206bo$207bo14$187b2o$186b2o$188bo14$235b2o$234b2o$236bo
19$207b3o$207bo$208bo9$268b3o$268bo$269bo9$256b3o$256bo$257bo19$298b3o
$298bo$299bo30$330b3o$330bo$331bo6$308b3o$308bo$309bo18$331b3o$331bo$
332bo2$363b2o$362b2o$364bo14$358b3o$358bo$359bo14$407b3o$407bo$408bo
14$391b3o$391bo$392bo14$424b2o$423b2o$425bo14$415b2o$414b2o$416bo14$
468b3o$468bo$469bo14$454b3o$454bo$455bo14$489b3o$489bo$490bo14$474b2o$
473b2o$475bo14$514b3o$514bo$515bo14$499b3o$499bo$500bo14$544b3o$544bo$
545bo14$543b3o$543bo$544bo14$593b3o$593bo$594bo26$598b3o$598bo$599bo2$
625b3o$625bo$626bo14$616b3o$616bo$617bo14$667b3o$667bo$668bo14$637b3o$
637bo$638bo14$669b3o$669bo$670bo14$669b3o$669bo$670bo14$704b3o$704bo$
705bo14$698b3o$698bo$699bo14$744b3o$744bo$745bo14$723b3o$723bo$724bo
14$764b3o$764bo$765bo14$763b3o$763bo$764bo36$823b3o$823bo$824bo!
[[ THUMBNAIL X 0 Y 0 ZOOM .5 THEME 9 LOOP 3500 ]]
[[ T 200 X -24 Y -24 ZOOM .5 ]]
[[ T 500 X -65 Y -65 ZOOM .52 ]]
[[ T 800 X -105 Y -105 ZOOM .54 ]]
[[ T 1100 X -145 Y -145 ZOOM .56 ]]
[[ T 1400 X -180 Y -180 ZOOM .66 ]]
[[ T 1700 X -220 Y -220 ZOOM .77 ]]
[[ T 2000 X -255 Y -255 ZOOM .92 ]]
[[ T 2300 X -300 Y -300 ZOOM 1.13 ]]
[[ T 2600 X -340 Y -340 ZOOM 1.55 ]]
[[ T 2900 X -375 Y -375 ZOOM 2.44 ]]
[[ T 3200 X -410 Y -410 ZOOM 5.5 ]]
[[ T 3400 ANGLE 270 ]]
The script numbers were picked by autofitting every 300 ticks. They're rounded off a little, and I might have made a copying error I suppose, but I think the effect is mainly due to the zoom interpolation.
There appears to be a hiccup in the HTML on your current test page, by the way -- the first pattern has eaten one of the following tests, which now show up as comments at the end of the too-big RLE due to a missing </textarea> tag.
