Re: [webkit-dev] Implement threaded model of Coordinated Graphics
Hi, webkit folks. As we've already notified, we are currently working on implementing Threaded Coordinated Graphics in WebKit2 Gtk+. https://bugs.webkit.org/show_bug.cgi?id=100341 But, to reuse existing Coordinated Graphics code, we have decided to implement Threaded Coordinated Graphics in WebKit1 Qt first. https://bugs.webkit.org/show_bug.cgi?id=102994 Then, we will apply Threaded Coordinated Graphics to WebKit1 Gtk+ and WebKit2 Gtk+. Our design document for implementing Threaded Coordinated Graphics in WebKit1 Qt is in the link below. https://docs.google.com/document/pub?id=1u1Oif9lDmVt_MkJLxaEYbTlOuZWVJcKrM1vAxAvFrZk Any comments/concerns are appreciated. Best regards, Jae Hyun Park On Sat, Nov 17, 2012 at 3:29 AM, noam.rosent...@nokia.com wrote: Slava, I think the new proposal is about threading in the web process, not in the UI process like we do in Qt. I've posted some comments on the meta bug, thank you for the heads up on the mailing list! No'am From: ext Vyacheslav Ostapenko osta...@gmail.com Date: Friday, November 16, 2012 10:12 AM To: Jae Hyun Park jae.p...@company100.net Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Implement threaded model of Coordinated Graphics Qt WK2 port already runs layer tree painting on separate thread. Layer tree renderer is created on main thread, but rendering is performed only on paint thread. Qt5 creates paint nodes for painting and QQuickWebPage paint node keeps threaded reference on LayerTreeRenderer. Messages to LayerTreeRenderer are delivered through dispatchUpdate/bind/renderQueue . All updates from renderQueue to renderer are applied in QQuickWebPage::updatePaintNode call. QQuickItem::updatePaintNode is very special call. During this call main thread is locked and it is safe to access main thread objects from paint thread. http://doc-snapshot.qt-project.org/5.0/qquickitem.html#updatePaintNode So, the only thing that needs to be implemented for GTK is replacement for Qt paint node and sync point similar to QQuickItem::updatePaintNode . Slava On Fri, Nov 16, 2012 at 12:44 AM, Jae Hyun Park jae.p...@company100.netwrote: Hi, webkit folks. Our team is currently implementing threaded model of Coordinated Graphics in GTK+ port. https://bugs.webkit.org/show_bug.cgi?id=100341 The purpose of sharing is to report our progress and make reviewers easier to understand the overview picture. We have updated the design document in the link below: https://docs.google.com/document/pub?id=1UoI1zk-6nTUFtz8i4evURM8aQIjkDRC8boO1zPdMMBg Our prototype for this implementation is shared in the GitHub. https://github.com/ryumiel/webkit-experimental The prototype is still in development, and only implemented up to step 1 in our design document. Any comments/concerns are appreciated. Best regards, Jae Hyun Park ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Possible device scale factor emulation approaches?
Hello, WebKit folks, I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch ( https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without instrumenting lots of page-deviceScaleFactor() call sites. Comments, ideas, suggestions, please? -- Regards, Alexander ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unresolved external on ews-win even after the symbol added in WebKit2.def.in
Hi Xianzhu, I think you are correct. I'll look at this now. Thanks for the report. -Brent On Tue, Dec 4, 2012 at 8:55 PM, Xianzhu Wang wangxian...@chromium.orgwrote: Hi, I just tested with a temporary patch that removed most of the contents of WebKit2.def.in (https://bugs.webkit.org/attachment.cgi?id=177603). ews-win still reported one unresolved external just as for the previous patches (http://queues.webkit.org/results/15153238). So I suspect that WebKit2.def was not updated from the changed WebKit2.def.in (I think otherwise there should be many other unresolved external errors). However I don't know much of Windows build and might be incorrect. @bfulgham, could you confirm? Thanks, Xianzhu On Tue, Dec 4, 2012 at 3:00 PM, Xianzhu Wang wangxian...@chromium.orgwrote: Hi, In https://bugs.webkit.org/attachment.cgi?id=177534, I added the symbol into Source/WebKit2/WebKit2.def.in trying to resolve the unresolved external error of the previous patch ( https://bugs.webkit.org/attachment.cgi?id=177506), but the error still occurred. I have read https://trac.webkit.org/wiki/ExportingSymbols (the WebKit2.def part should be updated). The only file I haven't changed is WebKit2.order (which I guess doesn't matter). Should there be sth like generating ...\WebKit2ExportGenerator\WebKit2.def in the log if WebKit2.def.in is changed in the patch? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue offline for the rest of the day
I believe the CQs are back up and running. Adam moved them to git.webkit.org for the time-being (they were using git.chromium.org as a mirror). Stefan is investigating our mirror to understand what went wrong. Sorry for the troubles. http://queues.webkit.org/queue-status/commit-queue On Tue, Dec 4, 2012 at 3:15 PM, Adam Barth aba...@webkit.org wrote: Both the commit hashes mentioned in the log appear to be real hashes from today, about ten revisions apart. I'm not enough of a git expert to understand what's going on. Adam On Tue, Dec 4, 2012 at 2:49 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, Is it possible if http://git.chromium.org/external/Webkit is broken? Or somebody pushed non fast forward commits? Maybe a manual kick can help: git reset --hard HEAD~1000 git clean -dxf git pull These lines always helped me if something went wrong on my git repository. Ossy Eric Seidel írta: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiprocess networking in WebKit
On Dec 4, 2012, at 12:36 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Tuesday 04 December 2012, Adam Barth wrote: There's been a somewhat fragmented discussion across webkit-dev and various bugs about how we ought to approach multiprocess networking in WebKit. In an attempt to organize my thoughts, I wrote up a short design document that compares various approaches: https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD 4fQY/edit ... About the network process, I would just like to suggest not limiting it to one, not even to begin with. There is not much simplicity or efficiency to be gained by keeping all network request in the same process, and extra processes could be used for faster responses and increased security. I haven't had the chance to read Adam's document yet. I disagree with your notion that a single Network Process doesn't much efficiency to be gained. In a world with multiple web content processes it is important to have a single coordinator for network i/o so the systems connection and any given host isn't hammered. That said, the work we've already done on the WebKit2 Network Process assumes support for multiple Network Processes at some stage. Actually making use of them can be rolled in once the fundamentals in place. ~Brady Regards `Allan Sandfeld ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Changes to DOM related exceptions
The specs for DOM related exceptions has changed a bit over the last few years. These changes have been made to simplify things, both for end users and implementers. Fortunately for the spec writers no two browsers agreed on the behavior, so end users could not depend on the details of the old specs. Unfortunately for us, we implemented things according to the old spec. So what changed? A lot of the new specs just throw DOMExceptions (instead of more specialized exceptions like RangeException). Also, new error types have a code property of 0. What might break? Code that does instanceof checks or accesses removed exception constructors. This should be a low risk since, like previously mentioned this never worked cross browser. For Apple dashboard widgets, this should still be a safe change since checking the type of an exception is hardly ever done (we don't even have tests covering this). -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to DOM related exceptions
To clarify. I intend to make changes to WebKit to align our code with the latest specs where possible. On Wed, Dec 5, 2012 at 3:29 PM, Erik Arvidsson a...@chromium.org wrote: The specs for DOM related exceptions has changed a bit over the last few years. These changes have been made to simplify things, both for end users and implementers. Fortunately for the spec writers no two browsers agreed on the behavior, so end users could not depend on the details of the old specs. Unfortunately for us, we implemented things according to the old spec. So what changed? A lot of the new specs just throw DOMExceptions (instead of more specialized exceptions like RangeException). Also, new error types have a code property of 0. What might break? Code that does instanceof checks or accesses removed exception constructors. This should be a low risk since, like previously mentioned this never worked cross browser. For Apple dashboard widgets, this should still be a safe change since checking the type of an exception is hardly ever done (we don't even have tests covering this). -- erik -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without instrumenting lots of page-deviceScaleFactor() call sites. Comments, ideas, suggestions, please? If you want to see how this is done in Chromium, you might want to study the --device-pixel-ratio command line flag. In general, I don't think you want to try to implementing this feature by hacking WebCore as it requires coordination beyond WebCore to do correctly. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without instrumenting lots of page-deviceScaleFactor() call sites. Comments, ideas, suggestions, please? If you want to see how this is done in Chromium, you might want to study the --device-pixel-ratio command line flag. In general, I don't think you want to try to implementing this feature by hacking WebCore as it requires coordination beyond WebCore to do correctly. I think Adam is refering to the --force-device-scale-factor=2 flag for chromium. To try it out, you may need to build with the use_ash=1 flag. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possible device scale factor emulation approaches?
On Thu, Dec 6, 2012 at 5:36 AM, Dana Jansens dan...@chromium.org wrote: On Wed, Dec 5, 2012 at 8:28 PM, Adam Barth aba...@webkit.org wrote: On Wed, Dec 5, 2012 at 7:16 AM, Alexander Pavlov apav...@chromium.org wrote: I'm working on emulating the device scale factor with Web Inspector. My goal is to let web developers see their pages on normal (device pixel ratio == 1) monitors the way they would look on e.g. retina screens. Page::setDeviceScaleFactor() is not something we can use, since it will have the reverse effect when used by platform-specific compositor code (which I saw on Chromium, and its compositor is far from being ready for such abnormal treatment.) I'm not sure I fully understand what you're trying to accomplish. Is the developer using a high density screen or a low density screen? A low density screen is used (that's what I meant by normal (device pixel ratio == 1) monitors). Imagine two 24 monitors, one high-density (H) and one low-density (L), standing next to each other. I want any page to be rendered exactly the same both on H and L monitor. So, @media and image set elements should be chosen as if L monitor were H, but then the respective images/glyphs/whatever downscaled to match the visible size of the same items in the H monitor. Chromium has a command line option for setting a fake device pixel ratio. For example, if you're using a low density screen, you can pass something like --device-pixel-ratio 2 to ask Chromium to render as if your device has a high density display. The net effect is that the glyphs get really big (since they use 2x the pixels in each dimension). Alternatively, I can imagine that the developer is using a high density screen but wants to develop a web site that looks good on a low density screen. In that case, they want to set a --device-pixel-ratio 1 but then render the web page pixel doubled (i.e., rasterizing each pixel as a 2x2 quad). I don't think there's a command line option for that in Chromium, but it's something you might reasonably do in the compositor. Naturally, but I would prefer not to touch the compositor code, as it is currently converging to the hardware-accelerated Ash implementation, and it's going to take a while until the dust settles down. In general, though, trying to shim this feature into WebCore isn't likely the right approach. For WebKit2, for example, both the UI process and the web process need to agree about the device pixel ratio or else the system gets confused about how big various regions of memory ought to be. If you look at how we test high density rendering That's one reason why I do not want to fiddle with ACTUAL device pixel ratios (the same holds for the WebCore and compositor code in Chromium; the compositor code in desktop Chromium (non-Ash) is not ready to see anything other than 1 as device pixel ratio (WebViewImpl::setPageScaleFactor() has the following comment, Don't allow page scaling when compositor scaling is being used, as they are currently incompatible.)). on low density machines, you'll see that we override the device's actual pixel density via the WebKit/WebKit2 API. That's to avoid this confusion. Yes, this is exactly my scenario - render pages on low-density (DPR==1) monitors as if they were high-density (DPR==2 or something else.) So, if the device's actual pixel density is overridden in WebKit/WebKit2, will glyphs and images get 2x bigger than those without the override? My goal is to have them visually remain the same size (because 1 CSS pixel should still correspond to 1 device pixel, as DPR==1 for low-density screens) along with the @media rules and -webkit-image-set elements (and perhaps some other things) appropriate for DPR==2 taking effect (downscaling larger 2x DPR images where applicable, so that they will look as if they were rendered on a high-density screen.) Do you think this can be emulated through the page settings, same was as the touch emulation (WebCore::Settings::setTouchEventEmulationEnabled()) instead? I took the approach of instrumenting the WebCore/css and WebCore/page code relying on the page-deviceScaleFactor() value. This worked pretty well, and you can see the respective patch at https://bugs.webkit.org/attachment.cgi?id=172046action=prettypatch (https://bugs.webkit.org/show_bug.cgi?id=100762), but now I'm wondering if there are better ways to implement this without instrumenting lots of page-deviceScaleFactor() call sites. Comments, ideas, suggestions, please? If you want to see how this is done in Chromium, you might want to study the --device-pixel-ratio command line flag. In general, I don't think you want to try to implementing this feature by hacking WebCore as it requires coordination beyond WebCore to do correctly. What if I try implementing this in a way that does not require any coordination beyond WebCore? I mean, overriding everything
