RESOLVED FIXED 84558
REGRESSION(109981): Twitter map buddy icon drawn in the wrong place
https://bugs.webkit.org/show_bug.cgi?id=84558
Summary REGRESSION(109981): Twitter map buddy icon drawn in the wrong place
Tim Horton
Reported 2012-04-22 20:15:06 PDT
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
Attachments
example (509.19 KB, image/tiff)
2012-04-22 20:15 PDT, Tim Horton
no flags
Screenshot (64.38 KB, image/png)
2012-04-23 15:08 PDT, Simon Fraser (smfr)
no flags
Tim Horton
Comment 1 2012-04-22 20:15:27 PDT
Radar WebKit Bug Importer
Comment 2 2012-04-23 10:51:45 PDT
Adrienne Walker
Comment 3 2012-04-23 14:00:05 PDT
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.
Simon Fraser (smfr)
Comment 4 2012-04-23 14:02:17 PDT
> Why is Safari turning on accelerated compositing for this page? Google maps forces compositing via 3d transforms.
Tim Horton
Comment 5 2012-04-23 15:00:33 PDT
Adrienne Walker
Comment 6 2012-04-23 15:00:53 PDT
(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?
Simon Fraser (smfr)
Comment 7 2012-04-23 15:08:24 PDT
<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); ">
Simon Fraser (smfr)
Comment 8 2012-04-23 15:08:38 PDT
Created attachment 138431 [details] Screenshot
Tim Horton
Comment 9 2012-04-23 15:18:16 PDT
(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.
Adrienne Walker
Comment 10 2012-04-23 17:29:58 PDT
(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?
Note You need to log in before you can comment on or make changes to this bug.