See the attached screenshot; the buddy icon should be on top of the map pin, not the wrong size and off to the right. I've confirmed that reverting 109981 locally does fix this. Link to sample tweet: http://twitter.com/#!/rgov/status/193865347286310912
Created attachment 138286 [details] example
<rdar://problem/11300978>
That's really strange. Why is Safari turning on accelerated compositing for this page? This works fine in Chromium with and without accelerated compositing turned on.
> Why is Safari turning on accelerated compositing for this page? Google maps forces compositing via 3d transforms.
Rolled out in http://trac.webkit.org/changeset/114950
(In reply to comment #4) > > Why is Safari turning on accelerated compositing for this page? > > Google maps forces compositing via 3d transforms. I just see an affine transform attached to the map in Chromium's inspector. In Safari it is true that many elements get translateZ(0), but I don't see any layer borders (even though I do on poster circle). So, it doesn't look like it's actually going through accelerated compositing, unless it's all going into the root graphics layer. However, in both ToT Chrome (Linux Desktop) and ToT Safari (10.6 Desktop) the page looks fine to me. thorton, smfr: Can you provide another repro case or more details about how to repro with that twitter page?
<div class="map_canvas notransform" data-tweet-id="193865347286310912" data-place-id="d0fc0f618c1eb790" data-place-name="Half Moon Bay, CA" style="position: relative; background-color: rgb(229, 227, 223); overflow: hidden; -webkit-transform: translateZ(0px); ">
Created attachment 138431 [details] Screenshot
(In reply to comment #6) > However, in both ToT Chrome (Linux Desktop) and ToT Safari (10.6 Desktop) the page looks fine to me. I can reliably reproduce the problem on Lion with any Safari/WebKit build between your change and my rollout.
(In reply to comment #9) > (In reply to comment #6) > > However, in both ToT Chrome (Linux Desktop) and ToT Safari (10.6 Desktop) the page looks fine to me. > > I can reliably reproduce the problem on Lion with any Safari/WebKit build between your change and my rollout. I can see this repro in Safari on Lion, but it seems like this doesn't reproduce on 10.6 because of accelerated canvas differences. Is there a way to force that on for non-Lion builds of Safari? Even if I force accelerated canvas on for Chromium on Linux or 10.6, this bug doesn't repro, even though I get a similar layer structure as smfr's screenshot. From playing with this on Lion, this bug looks like a repaint issue that just happens to be tickled by these changes and not at all related to layer creation correctness. The buddy icon and the skewed icon appear to be drawn into the same layer (judging by the repaint counter on the layer formed by the clip). It briefly appears correctly and then during a second paint operation gets repainted incorrectly. Anything that causes an invalidation cleans it up, so it appears only intermittently. It's really unfortunate to roll that patch out, since the previous code was causing performance problems by creating too many unnecessary layers and the code that patch was removing wasn't correct. Working around this repaint issue that repros for one port on one platform by rolling out an unrelated patch that just happens to tickle a bug doesn't seem like a real solution. Can you create a smaller repro case or a layout test that demonstrates this?