Bug 48550 - Accelerated transitions behave differently from non-accelerated ones sometimes
Summary: Accelerated transitions behave differently from non-accelerated ones sometimes
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.6
: P2 Normal
Assignee: Simon Fraser (smfr)
URL: http://www.leosciencelab.com/hi.html
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2010-10-28 12:23 PDT by Joel
Modified: 2022-07-12 19:22 PDT (History)
7 users (show)

See Also:

Attachments
Testcase (run from local file) (3.34 KB, text/html)
2010-11-30 10:24 PST, Simon Fraser (smfr) 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Joel 2010-10-28 12:23:05 PDT 
view this in chrome and the tiles will behave correctly.
in safari the tile seems to sit at it's default position for the transition duration and then displays correctly
Comment 1 Alexey Proskuryakov 2010-10-28 21:19:28 PDT 
Somewhat surprisingly, the behavior is identical between Safari/WebKit 5 and ToT.
Comment 2 Chris Marrin 2010-10-29 07:31:19 PDT 
Assuming the tiles animate up, revealing the word hello (with the before and after tile sheared up), this works fine for me on both TOT and 5.0.2. And it works identically to Chrome 7.
Comment 3 Joel 2010-10-29 08:05:07 PDT 
Here's a video example of what i'm talking about

http://gallery.me.com/glovacki#100005

what does TOT mean by the way?
Comment 4 Simon Fraser (smfr) 2010-10-29 09:02:38 PDT 
Chris: sometimes when you move your pointer from one block to the next, the yellow ribbon "breaks"; on tile animates incorrectly. This doesn't happen if accel. comp. is off.
Comment 5 Simon Fraser (smfr) 2010-10-29 09:03:08 PDT 
TOT = top of tree, i.e. most recent development bits.
Comment 6 Chris Marrin 2010-10-29 09:38:30 PDT 
OK, I see it now. Interestingly, for me it does not happen if you roll over the boxes from below. It only happens when you roll from one box to the next. That would indicate it has something to do with removing one transition and adding another in the same cycle. 

The reason this doesn't happen in Chrome is that they are not doing compositing (at least not in Chrome 7).
Comment 7 Simon Fraser (smfr) 2010-10-29 10:46:14 PDT 
I wonder if http://trac.webkit.org/changeset/70657 fixed this?
Comment 8 Alexey Proskuryakov 2010-10-29 10:54:58 PDT 
I'm seeing this with r70888, so I guess not.
Comment 9 Chris Marrin 2010-10-29 13:07:03 PDT 
(In reply to comment #7)
> I wonder if http://trac.webkit.org/changeset/70657 fixed this?

This example uses transitions, not animations. Seems like it would have to do with the fact that your changing from one active transition to another rather than from no transition to a transition. The logic in CompositeAnimation::updateTransitions might be getting confused when it both removes an old transition and adds a new one?
Comment 10 Simon Fraser (smfr) 2010-11-30 10:12:55 PST 
The testcase seems to have changed. Joel, can you attach a version to this bug please?
Comment 11 Joel 2010-11-30 10:22:09 PST Comment hidden (obsolete)
Comment 12 Simon Fraser (smfr) 2010-11-30 10:24:06 PST 
Created attachment 75164 [details]
Testcase (run from local file)
Comment 13 Simon Fraser (smfr) 2011-01-17 19:24:59 PST 
It seems that CA interpolates between a skew and translate matrix differently from how we do it in software.
Comment 14 Radar WebKit Bug Importer 2022-07-12 15:38:21 PDT 
<rdar://problem/96914465>