Re: [webkit-dev] Is the wxWidgets port maintained?
On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain benja...@webkit.org wrote: I am sorry, I should have given more context. There is visibly a growing discontent in the community about the cost imposed from small ports. Just two weeks ago, there were 2 threads discussing the cost of peripheral ports. I am convinced a part of this is technical. The project has not changed its policies while the number of ports was growing. While duplicated code and interfaces was okay when there were only 3 ports, it has become a pain when we have 7+ ports to updates ... In his email WebKit Wishes, Eric said It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. I think it was an entirely reasonable question to ask if the wx port was being maintained, but I'm surprised by how this thread has evolved. There is a lot of discussion going on about the cost of so many ports, but not much about the benefits. Speaking personally, even before I joined Google, I was drawn to WebKit partially because it was used on such a wide variety of projects and in so many different ways. I was fortunate to be able to get a job that allows me to contribute to it, and I have found the work that I've done to help maintain the peripheral ports, while not pain free, quite rewarding (although I would be quite happy if it was less costly, of course). My point is that I think that lots of ports are part of what makes WebKit the goodness it is. Maybe I'm alone here, or at best part of a minority, but I wanted us to not lose sight of this idea. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
My point is that I think that lots of ports are part of what makes WebKit the goodness it is. Maybe I'm alone here, or at best part of a minority, but I wanted us to not lose sight of this idea. I totally agree. But I also agree with those, who thinks the different ports should not overburden the project. I would not mind to set up conditions for being part of the trunk. That could be useful for both adding and removing ports. There was also an unanswered question: is there anyone here who had difficulties because of the wxWidgets port? Or the only reason is that it has only one active maintainer, who has not committed anything for 6 months? Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On 02/12/2013 04:51 PM, Zeno Albisser wrote: Hi, I have been looking into the NetworkProcess code that has recently been added to WebKit2. For Qt we are considering moving all the networking into a separate thread within the UIProcess. Do you guys think that the NetworkProcess code could be designed in a way to allow running in a separate thread of the UIProcess instead of in a separate process? We are convinced that this design would be a very good fit for our needs. Also in the light of the currently ongoing effort of cleaning up our Qt-bits and pieces in WebKit2. After a quick look it seems to me that this could be achieved with fairly minor modifications: * Instead of relying on RunLoop::main() within NetworkProcess, a different function would need to be introduced to retrieve a networking RunLoop. This would allow to process networking related events in the network thread. Depending on the platform, this could of course return a pointer to the main-RunLoop, for the cases where networking is indeed executed in a separate process. * Splitting the NetworkProcess class in two pieces. The child process and IPC setup remaining in NetworkProcess, and the actual networking code in a separate class (e.g. called NetworkThread). Provided the IPC (between threads in our case) would be setup upfront this would allow running the code provided by NetworkThread in a separate thread. You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote: You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. - Zeno ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] css: rotateY(90) with perspective()
Dear WebKit-Dev, I found an interesting difference between implementation of css 3d transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the following css rule: tranform: perspective(500px) rotateY(90) rotates an element (let say an image) so that it is perpendicular to the viewer, i.e. it shows the side of the element - hence nothing is printed to the screen, since html elements have no depth. While in WebKit based browsers (I have tested this in both Chromium and surf from suckles.org) the elements is shown at an angle: both rotations (Gecko WebKit) have the same axis (the vertical screen directions). Testing different angles I have found that I need to use rotateY(107deg), but this might depend on the perspective. The reason for this is that WebKit and Gecko are computing 3d view in a different way. The additional minor difference is that rotateY(30deg) in Gecko turns an element 30deg to the right while in WebKit it rotates to the left (with a different 3d view). The reason I found it is because I try to make an animation which turns a picture around 180deg showing a new picture on the other side, and I wanted to change the picture in the middle (90deg). This works for Gecko but for WebKit I need to know how to compute the angle at which the element (image) is perpendicular to the view source (showing its side to the viewer). Can somebody point me how the 3d rotationY with a given perspective is calculated so I can make the necessary converstion. Best regards, Marcin Szamotulski ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 11:44 PM, Eric Seidel wrote: This entire email thread makes me sad. I'm sad because we did this to ourselves (our porting systems/policies are lacking), we did this very abruptly (the last port we kicked out of webkit.org took a year?), and we don't have any clear policy for this sort of thing (adding/removing ports in webkit.org). I think this, and many recent threads on the subject, are symptoms of the same problem: We are at a point in WebKit (and have been for a long time) where we are focused less on the Web Platform (via WebKit) being everywhere, and more on that Web Platform being awesome. Maybe it's time we clarified this in our goals doc? Our (my!) previous platform-abstraction mistakes have also left us in an awkward position where it is difficult for us to support 7+ ports with separate build systems, and separate sets of constraints (however minor) on WebCore. I think it is the right decision to de-couple all ports from the core code, but doing that is going to take us a very long time. I think that moving closer to one build system will help, but won't help those trying to advance WebCore from having to deal with 8 different port APIs, 5 different networking libraries, 2 different XML parser, 4 different GraphicsContext implementations, and countless other configuration options! As a port maintainer, I totally agree. I've been talking about how I switched to waf for the benefits it offered the wx port, but it is also true that part of my reason for going that route was to see if I could find a way to get out of the business of needing others to update my port's build system and code. It's a very gracious policy, but I don't like the feeling that just by being in trunk, I'm putting a fair amount of the burden on others to update my build system, etc. for me. The build system choice was my decision, and accordingly, it should also be my responsibility to maintain. I guess the point of this all is that I'm sorry. I'm sorry to Kevin, and all the other ports that I've helped integrate with WebKit, that I and others didn't sit down years ago and design better, more maintainable porting systems for WebKit. As someone whose worked on cross-platform software for over a decade now, I can say that WebKit has, by and large, done a very good job of managing the complexity inherent in supporting multiple ports. You do it far better than wx does in some respects, to be honest. It is not perfect, but no one can get everything right from day one, and overall you did get a lot of important things right. The problems the project faces right now are largely a result of its successes, and those are the sorts of problems that aren't so bad to have. :) I think if we as a community are actively interested in maintaining as many ports as we have (and welcoming new ones) we need to come up with better ways to do so. And clearer policies for what it means to be a port in WebKit. In the specific case of Wx, I am reluctantly agreed that code with only one(?) maintainer is pretty close to dead and thus per WebKit's long-standing dead/commented-out code policies should be removed. :( Kevin has been with us a long time, and asking him to leave in this manner is saddening. I actually do agree with most of the points raised, and agree wx being removed is probably the most sensible approach. I think, as you said, it was more the manner in which things were done that was disheartening. Of course saying Wx is dead code, begs the question as to what is needed for a port to be considered live in WebKit.org? With our current porting architecture, I would argue that at least 3 full time people are probably needed, and that this should be considered before accepting new ports. Yes, I think the rules can probably change these days. Back in the days when there was only SVN, not being on trunk was a very painful experience because branch merging on such a large tree was so problematic, so it really was necessary for the threshold for inclusion to be lower. Today though, with git, it is a lot more feasible for ports to be a layer 'above' the core code. If I were starting the project today, that is probably how I would do it. I'm not in any rush to see Wx removed, and I agree it makes sense to let Kevin write the patches as much as he's willing. I think certainly having to wake up one day to see that one of your Open Source projects is kicking you out, is pretty jaring. :( I hope we can do this better next time, and maybe we should have a separate discussion about what it means to be a supported port in WebKit.org and what new/existing ports need to do to meet that bar. As for the future of WebKit on Wx: I don't know enough about WebKit2 to know if it has a more easily portable/maintainable architecture. For the port I work on (chromium), others haven't really ported in WebKit.org, but rather port at a higher
Re: [webkit-dev] css: rotateY(90) with perspective()
+shawnsingh On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski msza...@gmail.comwrote: Dear WebKit-Dev, I found an interesting difference between implementation of css 3d transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the following css rule: tranform: perspective(500px) rotateY(90) rotates an element (let say an image) so that it is perpendicular to the viewer, i.e. it shows the side of the element - hence nothing is printed to the screen, since html elements have no depth. While in WebKit based browsers (I have tested this in both Chromium and surf from suckles.org) the elements is shown at an angle: both rotations (Gecko WebKit) have the same axis (the vertical screen directions). Testing different angles I have found that I need to use rotateY(107deg), but this might depend on the perspective. The reason for this is that WebKit and Gecko are computing 3d view in a different way. The additional minor difference is that rotateY(30deg) in Gecko turns an element 30deg to the right while in WebKit it rotates to the left (with a different 3d view). The reason I found it is because I try to make an animation which turns a picture around 180deg showing a new picture on the other side, and I wanted to change the picture in the middle (90deg). This works for Gecko but for WebKit I need to know how to compute the angle at which the element (image) is perpendicular to the view source (showing its side to the viewer). Can somebody point me how the 3d rotationY with a given perspective is calculated so I can make the necessary converstion. Best regards, Marcin Szamotulski ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the New XMLParser dead?
He's dead, Jim: https://bugs.webkit.org/show_bug.cgi?id=107522 On Thu, Jan 17, 2013 at 5:54 PM, Maciej Stachowiak m...@apple.com wrote: I think it's fine to shoot it in the head now. We do still want to come back to it eventually, but it's now apparent that we won't in the next 1.5 months. - Maciej On Jan 17, 2013, at 4:15 PM, Adam Barth aba...@webkit.org wrote: Maciej has asked that we keep it around until the end of February: https://bugs.webkit.org/show_bug.cgi?id=100710 Adam On Thu, Jan 17, 2013 at 4:10 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, It has been 11 months since Eric initially raised the concern. Can we go ahead and remove the parser now? - R. Niwa ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
Hi, On Mon, Feb 11, 2013 at 11:44 PM, Eric Seidel e...@webkit.org wrote: This entire email thread makes me sad. I'm sad because we did this to ourselves (our porting systems/policies are lacking), we did this very abruptly (the last port we kicked out of webkit.org took a year?), and we don't have any clear policy for this sort of thing (adding/removing ports in webkit.org). I agree that this is sad. Wouldn't it be better to first agree on policies for adding/removing ports from WebKit BEFORE giving Kevin his walking papers? Why don't we first decide that aspect of things, before giving small teams the bum's rush? I think that moving closer to one build system will help, but won't help those trying to advance WebCore from having to deal with 8 different port APIs, 5 different networking libraries, 2 different XML parser, 4 different GraphicsContext implementations, and countless other configuration options! Not to mention two JavaScript engines! Of course saying Wx is dead code, begs the question as to what is needed for a port to be considered live in WebKit.org? With our current porting architecture, I would argue that at least 3 full time people are probably needed, and that this should be considered before accepting new ports. This is tantamount to saying that the only ports allowed in WebKit are corporate-sponsored efforts. Is that what we want this project to be? -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] css: rotateY(90) with perspective()
Hi Marcin, I wonder if you might accidentally have a perspective-origin set differently? Or maybe there is something in your code where window size that affects how the transforms appear? Maybe you can attach a reduced simple example of the difference you're seeing? I just whipped up the following example, which renders almost exactly the same geometry on both Firefox and tip-of-tree Chromium. body div style=-moz-transform: perspective(500px) rotateY(80deg); -webkit-transform: perspective(500px) rotateY(80deg); background-color: lime; width: 300px; height: 300px; HELLO WORLD /div /body Changing the rotateY to use 90deg makes the layer disappear for both Firefox and Chromium, too. ~Shawn On Tue, Feb 12, 2013 at 9:53 AM, Dana Jansens dan...@chromium.org wrote: +shawnsingh On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski msza...@gmail.comwrote: Dear WebKit-Dev, I found an interesting difference between implementation of css 3d transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the following css rule: tranform: perspective(500px) rotateY(90) rotates an element (let say an image) so that it is perpendicular to the viewer, i.e. it shows the side of the element - hence nothing is printed to the screen, since html elements have no depth. While in WebKit based browsers (I have tested this in both Chromium and surf from suckles.org) the elements is shown at an angle: both rotations (Gecko WebKit) have the same axis (the vertical screen directions). Testing different angles I have found that I need to use rotateY(107deg), but this might depend on the perspective. The reason for this is that WebKit and Gecko are computing 3d view in a different way. The additional minor difference is that rotateY(30deg) in Gecko turns an element 30deg to the right while in WebKit it rotates to the left (with a different 3d view). The reason I found it is because I try to make an animation which turns a picture around 180deg showing a new picture on the other side, and I wanted to change the picture in the middle (90deg). This works for Gecko but for WebKit I need to know how to compute the angle at which the element (image) is perpendicular to the view source (showing its side to the viewer). Can somebody point me how the 3d rotationY with a given perspective is calculated so I can make the necessary converstion. Best regards, Marcin Szamotulski ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Feb 12, 2013, at 8:28 AM, Zeno Albisser z...@webkit.org wrote: On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote: You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. Is this just for the qrc URL scheme specifically? If so, why not just teach the NetworkProcess how to handle qrc:? Using a thread instead of a process sounds like overkill just to solve that one problem. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] css: rotateY(90) with perspective()
Either way, I'd suggest you take this conversation to a specific bug report :) On Tue, Feb 12, 2013 at 11:49 AM, Shawn Singh shawnsi...@chromium.orgwrote: Hi Marcin, I wonder if you might accidentally have a perspective-origin set differently? Or maybe there is something in your code where window size that affects how the transforms appear? Maybe you can attach a reduced simple example of the difference you're seeing? I just whipped up the following example, which renders almost exactly the same geometry on both Firefox and tip-of-tree Chromium. body div style=-moz-transform: perspective(500px) rotateY(80deg); -webkit-transform: perspective(500px) rotateY(80deg); background-color: lime; width: 300px; height: 300px; HELLO WORLD /div /body Changing the rotateY to use 90deg makes the layer disappear for both Firefox and Chromium, too. ~Shawn On Tue, Feb 12, 2013 at 9:53 AM, Dana Jansens dan...@chromium.org wrote: +shawnsingh On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski msza...@gmail.comwrote: Dear WebKit-Dev, I found an interesting difference between implementation of css 3d transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the following css rule: tranform: perspective(500px) rotateY(90) rotates an element (let say an image) so that it is perpendicular to the viewer, i.e. it shows the side of the element - hence nothing is printed to the screen, since html elements have no depth. While in WebKit based browsers (I have tested this in both Chromium and surf from suckles.org) the elements is shown at an angle: both rotations (Gecko WebKit) have the same axis (the vertical screen directions). Testing different angles I have found that I need to use rotateY(107deg), but this might depend on the perspective. The reason for this is that WebKit and Gecko are computing 3d view in a different way. The additional minor difference is that rotateY(30deg) in Gecko turns an element 30deg to the right while in WebKit it rotates to the left (with a different 3d view). The reason I found it is because I try to make an animation which turns a picture around 180deg showing a new picture on the other side, and I wanted to change the picture in the middle (90deg). This works for Gecko but for WebKit I need to know how to compute the angle at which the element (image) is perpendicular to the view source (showing its side to the viewer). Can somebody point me how the 3d rotationY with a given perspective is calculated so I can make the necessary converstion. Best regards, Marcin Szamotulski ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Feb 12, 2013, at 12:00 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 12, 2013, at 8:28 AM, Zeno Albisser z...@webkit.org wrote: On Tue, Feb 12, 2013 at 5:01 PM, Balazs Kelemen kbal...@webkit.org wrote: You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? Yes, that was slightly ambiguous. Let me rephrase that. Currently the IPC for the NetworkProcess is setup by ChildProcess::initialize(). Since we would not need to create a whole new process in our case, we would just spin of a thread and create the appropriate IPC connections ourselves. That could be an implementation detail of our NetworkThread implementation. For prototyping i even reused the whole ChildProcess code with a few minor changes. But it would feel wrong to have instances of ChildProcess in something that is a thread of the same process. One of the main advantages of having networking in the UIProcess for our port is, that we could support some features such as Application URL Schemes without going through the WebKit2 API. This is a very Qt specific use case, that IMHO does not fit very nicely into the rest of the WebKit2 API. It is Qt specific because Qt makes heavy use of qrc files to embed content. And Application URL Schemes was the solution to allow for qrc content in a QQuickWebView. Is this just for the qrc URL scheme specifically? If so, why not just teach the NetworkProcess how to handle qrc:? Using a thread instead of a process sounds like overkill just to solve that one problem. We already support custom schemes on Mac by proxying the loading from the networking process to the UI process. For the Mac this is done in terms of NSURLProtocol. You could provide your own implementation of the port-specific bits of CustomProtocolManager and CustomProtocolManagerProxy. Thanks, ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Tue, Feb 12, 2013 at 9:29 AM, Kevin Ollivier kev...@theolliviers.comwrote: On Feb 11, 2013, at 11:44 PM, Eric Seidel wrote: I think if we as a community are actively interested in maintaining as many ports as we have (and welcoming new ones) we need to come up with better ways to do so. And clearer policies for what it means to be a port in WebKit. In the specific case of Wx, I am reluctantly agreed that code with only one(?) maintainer is pretty close to dead and thus per WebKit's long-standing dead/commented-out code policies should be removed. :( Kevin has been with us a long time, and asking him to leave in this manner is saddening. I actually do agree with most of the points raised, and agree wx being removed is probably the most sensible approach. I think, as you said, it was more the manner in which things were done that was disheartening. Sorry, I didn't mean to rush or harass you in any way. Of course saying Wx is dead code, begs the question as to what is needed for a port to be considered live in WebKit.org? With our current porting architecture, I would argue that at least 3 full time people are probably needed, and that this should be considered before accepting new ports. Yes, I think the rules can probably change these days. Back in the days when there was only SVN, not being on trunk was a very painful experience because branch merging on such a large tree was so problematic, so it really was necessary for the threshold for inclusion to be lower. Today though, with git, it is a lot more feasible for ports to be a layer 'above' the core code. If I were starting the project today, that is probably how I would do it. Right. The way I see it, as arrogantly as it sounds, we're not really kicking Wx port out. It's just that it won't be on svn.webkit.org anymore. There is no reason why github repository should be a second-class citizen to the community. We can make a wiki page or other form of documentation on how to maintain a port on github, and let all perpetual ports live there instead. Port maintainers can merge sync up to trunk on their own pace then. I agree with you that we should include a port on svn.webkit.org when and only when that it gets popular enough to have EWS and build.webkit.org bots since setting up a buildbot via github will be extremely tricky. (Also see https://lists.webkit.org/pipermail/webkit-dev/2011-September/018075.html) In other words, I'm suggesting to create a two-tier system where popular ports with lots of contributors live on svn.webkit.org with build slaves and EWS bots, and those ports that do not have luxury of keeping up with trunk changes will live on github. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] NetworkProcess / NetworkThread in the UIProcess
On Tue, Feb 12, 2013 at 12:09 PM, Brady Eidson beid...@apple.com wrote: We already support custom schemes on Mac by proxying the loading from the networking process to the UI process. I believe we do something like this for the libsoup port as well, though network process support is still young. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] css: rotateY(90) with perspective()
I opened a new bug report: https://bugs.webkit.org/show_bug.cgi?id=109613 Best, Marcin On 12:07 Tue 12 Feb , Levi Weintraub wrote: Either way, I'd suggest you take this conversation to a specific bug report :) On Tue, Feb 12, 2013 at 11:49 AM, Shawn Singh shawnsi...@chromium.orgwrote: Hi Marcin, I wonder if you might accidentally have a perspective-origin set differently? Or maybe there is something in your code where window size that affects how the transforms appear? Maybe you can attach a reduced simple example of the difference you're seeing? I just whipped up the following example, which renders almost exactly the same geometry on both Firefox and tip-of-tree Chromium. body div style=-moz-transform: perspective(500px) rotateY(80deg); -webkit-transform: perspective(500px) rotateY(80deg); background-color: lime; width: 300px; height: 300px; HELLO WORLD /div /body Changing the rotateY to use 90deg makes the layer disappear for both Firefox and Chromium, too. ~Shawn On Tue, Feb 12, 2013 at 9:53 AM, Dana Jansens dan...@chromium.org wrote: +shawnsingh On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski msza...@gmail.comwrote: Dear WebKit-Dev, I found an interesting difference between implementation of css 3d transforms in Gecko (FireFox) and Chromium (WebKit). In Gecko, the following css rule: tranform: perspective(500px) rotateY(90) rotates an element (let say an image) so that it is perpendicular to the viewer, i.e. it shows the side of the element - hence nothing is printed to the screen, since html elements have no depth. While in WebKit based browsers (I have tested this in both Chromium and surf from suckles.org) the elements is shown at an angle: both rotations (Gecko WebKit) have the same axis (the vertical screen directions). Testing different angles I have found that I need to use rotateY(107deg), but this might depend on the perspective. The reason for this is that WebKit and Gecko are computing 3d view in a different way. The additional minor difference is that rotateY(30deg) in Gecko turns an element 30deg to the right while in WebKit it rotates to the left (with a different 3d view). The reason I found it is because I try to make an animation which turns a picture around 180deg showing a new picture on the other side, and I wanted to change the picture in the middle (90deg). This works for Gecko but for WebKit I need to know how to compute the angle at which the element (image) is perpendicular to the view source (showing its side to the viewer). Can somebody point me how the 3d rotationY with a given perspective is calculated so I can make the necessary converstion. Best regards, Marcin Szamotulski ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
