visual effects on objects

[monte]

I'm looking at the iOS code at the moment... not sure how different it is for the different platforms but here goes with what I think we need to do based on iOS

buffer an image of the stack without the object
get an image of the object with transparency etc
animate the image of the object

thoughts?

[LCMark]

I guess it depends on what you want to achieve - 'visual effects on objects' isn't that well defined... Perhaps some rough pseudo-code examples and their intended affects would help lead the discussion?

The current visual effect code is very specific to transitioning between two images of equal size (and without alpha channel), and the iOS code is a special-case so that it can leverage the flip and curl transitions (it uses UIImage objects on top of everything else). Indeed, essentially it just transitions between the a snapshot taken before a lock screen, and one taken after the unlock screen.

[monte]

Right... sorry... some psuedocodeish examples

In this one the delete button is shown with an animation... anything under the button (which might be transparent with an icon etc) just stays static.

Code: Select all

on Swipe
   lock screen for visual effect on btn "delete"
   show btn "delete"
   unlock screen with visual effect scroll left fast
end Swipe

In this one the group is moved on screen from the left

Code: Select all

on Touch
   lock screen for visual effect on me
   set the right of me to the right of me+200
   unlock screen with visual effect scroll right
end Touch

PS I might have my effects messed up (I'm not Scott Rossi) but hopefully you get what I mean. The general idea is the effects in rect have issues with non-square things.... I'm thinking if we can take a snapshot of the object and a snapshot of the card without it we can animate the snapshot of the object over the card...

Another way to look at this is (and possible syntax is):

Code: Select all

show objectRef [at loc tPoint] with visual effect scroll left
hide objectRef with visual effect scroll right

[LCMark]

Get precisely what you mean now - this would be quite neat

I think the syntax is also cool - it's an elegant extension of the 'local screen for visual effect in rect ...' syntax we added a while back. (Although, show/hide already have this clause I think - however, in this instance, it working on layers rather than snapshot is probably what most people would expect it to do anyway - so the current behavior could be considered 'unexpected').

PS I might have my effects messed up (I'm not Scott Rossi) but hopefully you get what I mean. The general idea is the effects in rect have issues with non-square things.... I'm thinking if we can take a snapshot of the object and a snapshot of the card without it we can animate the snapshot of the object over the card...

That would potentially be a good implementation strategy - you take a snapshot of the objects under the target, a snapshot of the objects above the target, and then a before/after snapshot of the target. In particular, it would mean we could use a similar implementation technique on iOS that is currently used (which means they would still be nice and smooth).

I can work up a few suggestions on how to go about it as a baseline for discussion if you like (and run them past Ian to make sure the graphics refactoring isn't going to clobber them!)

[monte]

OK, sure... I wasn't considering objects above the target object but that would be neat if the object could slide out between objects etc...

[LCMark]

So I chatted to Ian and the non-iOS visual effects need to be sorted out to work with the new graphics library, which would make doing this easier as the current ones know nothing of alpha-channels. Thus, probably best to start thinking about iOS now, and then the other platforms later (after the refactor-graphics branch has been integrated - which will hopefully be 'quite' soon).

There are a few wrinkles that need to be ironed out conceptually, however.

The first (A) is what should happen in this case:

Code: Select all

lock screen for visual effect on button "delete"
show button "delete"
set the backColor of this card to red
unlock screen with visual effect scroll left fast

Here, a visual change is being made to another object (the card in this case) in the lock screen. When should this be visible?

The next (B) is what should happen in this case:

Code: Select all

lock screen for visual effect on button "delete"
set the width of button "delete" to 2 * the width of button "delete"
unlock screen with visual effect scroll left fast

Here the size of the button undergoing the visual effect is changing.

The last (C) I've thought of so far is this:

Code: Select all

lock screen for visual effect on button "delete" of group "container"
set the right of button "delete" of group "container" to the right of button "delete" of group "container" +200
unlock screen with visual effect scroll left fast

Here the button is in a group and its location is changing, this might cause extra things to be revealed in the group due to it being resized.

[jacque]

Would nested locks help here? If I just "lock screen" then nothing should redraw until it's unlocked. But if I lock screen on an object, then the next unlock would affect only that object, and the final unlock would show everything again. Or maybe add an "unlock screen on object" option to control what gets drawn?

Just thinking out loud here.

[mwieder]

"lock screen" is nested everywhere else... is there a reason *not* to apply it to locking object effects?

[LCMark]

There is more future direction here beyond what @monte proposed - and I think that is perhaps where @jacque's thinking is coming from.

Really what would be great would be an animation concept like iOS has - i.e. one where you specify a list of changes to objects then have things interpolate between the old and new set of properties appropriately over a specified period of time.

The lock/unlock/visual effect mechanism we have at the moment is quite specific - and the beauty of @monte's suggestion is that it's a direct and elegant extension of it that gives us quite a bit more than we currently have without (relatively speaking) a substantial amount of design and implementation effort (the fact that the current visual effect operations are 'stop-the-world' simplifies this a lot).

The cases I listed above are not that important in the grand scheme of things, but working out a reasonable way for them to be handled helps guide implementation on top of what we have.

Talking possible implementation now, we can break down the steps into the following:

1. The 'lock screen for visual effect on <object>' command.
2. The period the lock screen is in effect.
3. The 'unlock screen for visual effect' command.
4. The period over which the visual effect runs.

The simplest implementation would be this:

• At point (1):
  • The area of effect is set to be the rect of the target object clipped by all parent groups.
  • A snapshot of (just) that object (clipped to the area of effect) is taken and cached.
• During point (2), the screen is locked so no screen updates occur anywhere.
• At point (3):
  • A snapshot of all objects below the target object (clipped to the area of effect) is taken and cached. (This would incorporate all changes to those objects that occurred in the lock screen).
  • A snapshot of all objects above the target object (clipped to the area of effect) is taken and cached. (This would incorporate all changes to those object that occurred in the lock screen).
  • A snapshot of the target object as it is now (clipped to the area of effect) is taken and cached. (This would incorporate all changes to the target object that occurred in the lock screen).
• At point (4):
  • The card is redrawn, but with the image of the target object being that snapshot taken at point (1).
  • The effect then runs, not touching anything outside the area of effect and using the target object snapshot at (1) and (3) as from and to images. (The effect area would be a stack of snapshot of objects below, the image created by the visual effect from the from and to images at that point in time, the snapshot of objects above).
  • The card is redrawn completely - including the area outside that of the effect area (and thus incorporating any 'new' parts of the target object that were outside of the effect area).

This approach would mean that...

In case (A) above, the card color would change before the effect started.
In case (B) above, you'd be transitioning between the whole of the object at start, and the corresponding rect in the middle of the object at end.
In case (C) above, you'd be transitioning between the whole of the object (as clipped by the group) at start and whatever is still visible of the object (as clipped by the group) within the area of effect.

Now, (B)'s effect might be a little strange in some cases, but (A) and (C) seem entirely reasonable. Indeed, (B) is a bit of a lofty goal to have do something 'nice' as it stands since none of the visual effects we have are designed to work with different sizes of area (indeed (C) suffers this a bit too, they aren't designed to have the effect area move either) - both these things probably means that to improve those cases in the future its the visual effects we have, rather than the mechanism, that would need work.

[monte]

Hmm... could the effect rect somehow include the rect of the object at lock screen and the rect of the object at unlock screen? Ideally you could move an object with this command... I'm thinking specifically of a group of controls on a phone that just has a tab/handle on screen normally but when you touch the tab it animates on screen.