On Wed, May 30, 2012 at 10:00 PM, Adam Barth <[email protected]> wrote: > On Wed, May 30, 2012 at 12:08 AM, Kenneth Rohde Christiansen > <[email protected]> wrote: >> I don't think we are doing that much differently. >> >> Desktop Safari is scaling directly in WebCore using the >> pageScaleFactor whereas Qt like iOS scales outside of WebCore (using a >> tiled backing store), resulting in the FrameView not being in UI >> pixels. > > This doesn't match what Simon Fraser wrote. He said that all > FrameView sizes on iOS are in "UI" pixels.
OK then I got it wrong :-) I thought that was only the case for Desktop Safari. Anyway, the difference shouldn't be that big and I guess we could migrate Qt to do the same (I actually had a proof of concept of that working at some point). Currently we are applying a scale to our GraphicsContext (QPainter), so that everything is drawn with a scale, where as Safari actually adds the scale inside WebCore using the pageScaleFactor. Of course that means that our FrameView has the size as it was at scale 1.0 and we have to do adjustments to innerHeight etc. What are the advantages of the Safari approach? I guess you could make the drawing better in some cases and you avoid external mapping of event positions, but are there additional advantages? Any disadvantages? Kenneth > Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
