question about how fades work

[shadoof]

hi Daniel, I am trying to fine tune and remove artifacts from the VBs. I need to know:

• If a fade is coded with the signature colorTo(<color>, <fadeInTime>, <delayBeforeFade>) is the fade management 'start time' of the fade (1) the time when this code is executed or (2) the time when the fading actually starts (after the delay)?
• If (2) then I think this is wrong. It means that a delayed fade could cancel a fade that has greater priority, for example: a non-delayed fade colorTo(<color>, <fadeInTime>) that was fired after execution of the delayed fade and before the end of the delay (and this might explain certain artifacts that I am seeing).

[dhowe]

Yes, I mentioned this issue a while back. Currently it works according to, I believe, (2) above. The fade does not 'exist' at all until the delay time expires. So if another fade is running when that happens, it will be cancelled, even though it may have been initially called after the delayed fade.

[shadoof]

Right. And I'm sorry I missed this. (Hard to think through.) Can we switch to (1)? It will I think be the only way to handle more complex VBs. The existing problem now, I believe, is that 'peripheral' (haloing fades) may cancel the 'fade in' of even a current cell. Why? Peripheral fade-out code is properly delayed but then its actual, delay-expired fade may fire on the current word cancelling the current word's fade-in, whereas this fade-in was initiated more recently and should be the VB's top priority.

[shadoof]

And, to be clear, later fades (of any kind) should cancel any other fade including delayed fades that have not yet started to run and are in their 'delay state'.

[dhowe]

To clarify then, if we have 2 fades like this:

1. rt.fadeToColor(col1, 5);  // fade over 5 seconds
2. rt.fadeToColor(col2, 2, 6) // wait 5 seconds, then fade over 2 seconds

The first fade is immediately cancelled and nothing happens for 6 seconds, even though there would be no conflict here?

[shadoof]

I believe so, but I will devise a test, to be sure. (Not as easy as I thought because the old test rig is currently broken.)

[shadoof]

Actually oneword.html does work and demonstrate the problem (on my 'cayley' branch, which I've pushed). (test.html is broken.) But the case above is not the problem. This is:

  rt.colorTo({r:0,g:255,b:0,a:255}, 5, 5);
  rt.colorTo({r:255,g:0,b:0,a:255}, 10);

Desired behavior: second fade cancels the first fade and rt fades to (full-on) red over 10 secs. Actual behavior: rt fades (half-way) to red for 5 secs, then fades to green over 5.

Note that if the lines above were reversed:

  rt.colorTo({r:255,g:0,b:0,a:255}, 10);
  rt.colorTo({r:0,g:255,b:0,a:255}, 5, 5);

then both Desired and currently existing Actual behavior would be the same: rt fades (half-way) to red for 5 secs, then fades to green over 5 (the more recently invoked fade cancels an earlier invoked fade at the time that the more recently invoked fade starts its delayed operation).

[shadoof]

But, in the case of:

1. rt.fadeToColor(col1, 10);  // fade over 10 seconds
2. rt.fadeToColor(col2, 5, 5) // wait 5 seconds, then fade over 5 seconds

... the correct behavior (including as above) would need to be preserved. i.e. (2) would not cancel (1) immediately; it would cancel it after 5 seconds. (gets half way to col1 and the all the way to col2).

[dhowe]

I think I'm confused about the spec you are asking for. Does a subsequent call cancel previous calls immediately (1), or after their delay (2), or some mix of the two, perhaps depending on whether the prior fade has finished its delay period (3) ?

[shadoof]

Yeah. It's hard to think through.

colorTo(<col>, <fadeTime>) is equivalent to colorTo(<col>, <fadeTime>, 0)

... and so it should interrupts any fade on the the same rt, right away after 0. But if a delay is set, then it should only interrupt after the delay. The problem is simply that if a delayed fade does not (yet) exist, it can't be interrupted. Delayed fades should exist and should be interruptable from the moment their code is executed, even if they haven't started to do anything that is visible, as in the oneword case above.

[dhowe]

Ok, so we want the current behavior, except that previously invoked fades, which are still in their delay, should also be cancelled whenever a fade starts. Is that correct?

[shadoof]

Yes, that is correct (with the obvious qualification that a cancelation only happens when a more recently invoked fade starts its fade on the same rt object as a previously invoked fade).

[shadoof]

Closing this, but feel free to reopen if you think it necessary.