[webkit-dev] Removing ACCELERATED_2D_CANVAS
Hi all, ACCELERATED_2D_CANVAS feature right now is only implemented for ports using Cairo. Of those ports, I can only guarantee for the GTK and WPE ports that it works to some degree. The implementation relies on a GL-oriented Cairo backend that's always been deemed experimental and is not receiving a lot of attention anymore. As such, I propose removing the ImageBuffer backend implementation, along with the code guarded by the ACCELERATED_2D_CANVAS build guard and the relevant configuration options. The patch removing the guarded code and build/configuration options is here, pending to land: https://bugs.webkit.org/show_bug.cgi?id=217603 There's also some preference cruft still left in the WebKit layer that's going to be removed later. Regards, Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is anyone maintaining Nicosia scrolling code?
On Sat, Feb 23, 2019, at 2:47 AM, Simon Fraser wrote: > There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that > I keep breaking with scrolling tree refactoring. Most of it it stubs. > Is anyone maintaining this code, because it obviously doesn’t work, and > I’d like to remove the maintenance burden. > I added the stubs there, and was planning to start adding actual implementations there in the following weeks, now that a new release cycle was just entered. I wouldn't mind disabling or removing the code temporarily in order to enable you an easier time refactoring around it. But given that the async scrolling capability is something we plan to add support for in the WPE and GTK ports, I'd appreciate some input about the scope and the timeframe of your work and possibility of sharing as much of the implementation as possible between different ports. Cheers, Zan > Simon > > ___ > 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] Switch to std::variant?
Hi, with C++17 adoption progressing, are there existing plans to switch over from WTF::Variant to stdlib-provided std::variant implementations? Some GCC-and-libstdc++ configurations would still require a fallback implementation, just like with std::optional. Bug #175583 started work on importing a C++17-compliant implementation, but currently seems stalled. https://bugs.webkit.org/show_bug.cgi?id=175583 Are there any other reservations or obstacles about adopting std::variant? Cheers, Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ImageBitmap and OffscreenCanvas patches up for review
Hi, Igalians have a couple of patches covering ImageBitmap and OffscreenCanvas functionality up for review, and would like to invite reviewers handy in this area to give them a look. Here's initial ImageBitmap patches, covering creation from Blob objects and transfer support: Implement createImageBitmap(Blob) -- https://bugs.webkit.org/show_bug.cgi?id=183247 Support transferring ImageBitmap objects -- https://bugs.webkit.org/show_bug.cgi?id=183131 There's further work necessary for complete ImageBitmap support that we want to undertake, as outlined in this meta bug: https://bugs.webkit.org/show_bug.cgi?id=182424 And here's OffscreenCanvas patches, covering initial refactoring in CanvasBase and CanvasRenderingContext2DBase: Move ImageBuffer-related functionality from HTMLCanvasElement to CanvasBase -- https://bugs.webkit.org/show_bug.cgi?id=182503 CanvasRenderingContext2DBase: use CanvasBase more extensively -- https://bugs.webkit.org/show_bug.cgi?id=182685 Similarly, we'll be taking on further work to get to a compliant OffscreenCanvas implementation: https://bugs.webkit.org/show_bug.cgi?id=183720 Because all this functionality is based on platform abstractions like ImageBuffer and GraphicsContext, all the work is port-agnostic. Reviews appreciated. Regards, Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit support in web-platform-tests
Hi, in case of no additional comments against this, I'll be opening a pull request to merge the web-platform-tests changes into that repository in the following days. The WebKit changes will follow after some further work. Cheers, Zan On Mon, Feb 12, 2018, at 4:06 PM, z...@falconsigh.net wrote: > Hi, > > the web-platform-tests repository includes tooling that enables running > those tests against a supported browser product. I'd like to propose > adding generic WebKit support there. > > > Current changes only assume usage of the WebDriver protocol, and the > WebDriver binary accepting the --port flag. Selenium executors are used > for test harness and reftests. Same WebDriver implementation can also be > tested against the WebDriver tests included in the web-platform-tests > directory, presuming the tests are enabled or explicitly specified. > > Only port-specific bit is the specification of capabilities that are > passed to the WebDriver binary, idea being that these capabilities are > the same as those supported by the WebDriver implementation. > > GTK is for now the only port that's supported, and it's leveraging the > WebDriver implementation under Source/WebDriver/ in WebKit. WPE will be > doing the same. Safari I suppose could use its own WebDriver > implementation, or perhaps even a separate product. > > Here's the current set of changes: > https://github.com/zdobersek/web-platform-tests/commit/c2ee920876ca6df7c4739feb8a6e03c77dffdb7f > > > The web-platform-tests suite can then be run like this for the GTK port, > assuming a tip-of-trunk build: > > $ /work/web-platform-tests/wpt run --webkit-port=gtk \ > --webdriver-binary=WebKitBuild/Release/bin/WebKitWebDriver \ > --binary=WebKitBuild/Release/bin/MiniBrowser \ > --binary-arg=--automation \ > --binary-arg=--javascript-can-open-windows-automatically=true \ > --binary-arg=--enable-xss-auditor=false \ > webkit /2dcontext > > This can be further wrapped into a python script and run as part of the > continuous integration system. These changes add a run-web-platform- > tests script that invokes the web-platform-tests runner tool, also > allowing each port to specify what tests to enable and what the expected > failures are: > https://github.com/Igalia/webkit/commit/df1aeeb9476c6dd220067f4fc3c6ad69a8f948ba > > Only a small subset of tests is enabled there, for prototype purposes. > The expected results system could also be improved to avoid each > expected failure having to be marked as such in separate .ini files. > > > But foremost, I'd like to have a consensus of sorts about how various > WebKit ports should be handled in the web-platform-tests repository, so > that the changes there can proceed -- whether it's fine to implement a > generic WebKit product, or whether Safari would like to be treated as a > separate browser[1], etc. > > > Regards, > Zan > > > [1] There's for instance this from a year ago (though not sure about its > functionality): > https://github.com/w3c/web-platform-tests/tree/wptrunner-safari ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit support in web-platform-tests
Hi, the web-platform-tests repository includes tooling that enables running those tests against a supported browser product. I'd like to propose adding generic WebKit support there. Current changes only assume usage of the WebDriver protocol, and the WebDriver binary accepting the --port flag. Selenium executors are used for test harness and reftests. Same WebDriver implementation can also be tested against the WebDriver tests included in the web-platform-tests directory, presuming the tests are enabled or explicitly specified. Only port-specific bit is the specification of capabilities that are passed to the WebDriver binary, idea being that these capabilities are the same as those supported by the WebDriver implementation. GTK is for now the only port that's supported, and it's leveraging the WebDriver implementation under Source/WebDriver/ in WebKit. WPE will be doing the same. Safari I suppose could use its own WebDriver implementation, or perhaps even a separate product. Here's the current set of changes: https://github.com/zdobersek/web-platform-tests/commit/c2ee920876ca6df7c4739feb8a6e03c77dffdb7f The web-platform-tests suite can then be run like this for the GTK port, assuming a tip-of-trunk build: $ /work/web-platform-tests/wpt run --webkit-port=gtk \ --webdriver-binary=WebKitBuild/Release/bin/WebKitWebDriver \ --binary=WebKitBuild/Release/bin/MiniBrowser \ --binary-arg=--automation \ --binary-arg=--javascript-can-open-windows-automatically=true \ --binary-arg=--enable-xss-auditor=false \ webkit /2dcontext This can be further wrapped into a python script and run as part of the continuous integration system. These changes add a run-web-platform-tests script that invokes the web-platform-tests runner tool, also allowing each port to specify what tests to enable and what the expected failures are: https://github.com/Igalia/webkit/commit/df1aeeb9476c6dd220067f4fc3c6ad69a8f948ba Only a small subset of tests is enabled there, for prototype purposes. The expected results system could also be improved to avoid each expected failure having to be marked as such in separate .ini files. But foremost, I'd like to have a consensus of sorts about how various WebKit ports should be handled in the web-platform-tests repository, so that the changes there can proceed -- whether it's fine to implement a generic WebKit product, or whether Safari would like to be treated as a separate browser[1], etc. Regards, Zan [1] There's for instance this from a year ago (though not sure about its functionality): https://github.com/w3c/web-platform-tests/tree/wptrunner-safari ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: upstream the WPE port
Hi, the WebKit team at Igalia would like to propose upstreaming the WPE port of WebKit, taking on the duty to maintain it alongside the GTK+ port. The WPE port started in 2014 as the 'WebKit for Wayland' project inside Igalia [1]. The port was derived from the GTK+ port, but avoided dependency on any GUI toolkit. It relied on the Wayland display protocol for on-screen presentation. That dependency was later dropped in favor of using generic interfaces to adapt to different platform-specific presentation systems. This allows any vendor to simply provide the necessary backend implementations that are tailored to their platform. The port is intended to be the Web platform engine of choice for embedded Linux systems. Since late 2014 Igalia has been sponsored by Metrological to further develop the WPE port, targeting primarily various set-top box platforms. Miguel Gomez blogged about this effort back in December [2]. The port can also address other embedded use cases, for instance in-vehicle infotainment or digital signage. The GTK+ and WPE ports mostly have the same dependencies except for the GTK+ toolkit library. That enables the two ports to already share a lot of code. The biggest difference between the two is that the WPE port exposes the WebKit2 C API, while the GTK+ port exposes a GObject-based API. Apart from that, the maintainers' plan is to further align the two ports as much as possible, ideally simply stacking the GTK+ port on top of WPE, with only a few additional tweaks for GTK+ integration. This would lessen the maintenance burden for both ports and the project as a whole. The WebKit team at Igalia thinks this port is on stable footing and has solid prospects for the future. That's why we'd like to join the upstream community and continue our work there. The patch with the port changes is in bug #171110 [3]. We have existing x86_64 buildbot configurations [4] that we would have to port over to the webkit.org build master. We're planning further builder and tester configurations for ARM architectures in the future. Layout test baselines would be landed separately. (Those too would be subject to alignment with the GTK+ port.) We're happy to address any questions or considerations. Regards, Zan [1] https://lists.webkit.org/pipermail/webkit-dev/2014-December/027087.html [2] https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for-embedded/ [3] https://bugs.webkit.org/show_bug.cgi?id=171110 [4] https://build-webkit.igalia.com/waterfall?category=WPE ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017
On Tue, Mar 28, 2017, at 10:01 AM, Ling Ho wrote: > Hi Zan, > > I have tested a git clone earlier and it should be working for you > too. We have also taken care notification emails issue to webkit- > changes list. > > Thanks, > ... > ling > Hi, the Git mirror is working now, but it's fallen behind the SVN repository. It's stuck at r214463 while SVN is at this moment at r214469. https://git.webkit.org/?p=WebKit.git;a=shortlog Cheers, Zan > > On 3/28/17 12:04 AM, z...@falconsigh.net wrote: >> On Tue, Mar 28, 2017, at 08:45 AM, Lucas Forschler wrote: >>> Quick update: >>> >>> We are currently tracking issues with our EWS bots, as well as not >>> sending change notification emails to webkit- >>> chan...@lists.webkit.org. >>> >>> If you notice anything awry, please let us know so we can >>> investigate. >>> Thanks, >>> Lucas >> >> The git.webkit.org mirror doesn't seem to be operational. The server >> itself is up and running, but Git requests against it time out. >> >> Cheers, >> Zan >> >>> >>>> On Mar 27, 2017, at 5:36 PM, Lucas Forschler <lforsch...@apple.com> >>>> wrote: >>>> >>>> Hello everyone, >>>> >>>> Commits have been disabled on svn.webkit.org[1] while we update >>>> infrastructure. >>>> We will send a follow-up when the repository is back online. >>>> >>>> Thanks, >>>> Lucas >>>> >>>>> On Mar 27, 2017, at 11:31 AM, Ling Ho <lin...@apple.com> wrote: >>>>> >>>>> Hello WebKit developers, >>>>> >>>>> We will be switching and upgrading our Subversion and Git mirror >>>>> servers this evening at 5.30pm PDT. We will be stopping svn commit >>>>> at 5.30pm, and the new server should go into service shortly after >>>>> DNS change is made. We will send out another notice once commit is >>>>> possible again on the new server. >>>>> >>>>> Thanks, >>>>> ... >>>>> ling >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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 >> > > _ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev Links: 1. http://svn.webkit.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017
On Tue, Mar 28, 2017, at 08:45 AM, Lucas Forschler wrote: > Quick update: > > We are currently tracking issues with our EWS bots, as well as not > sending change notification emails to webkit-chan...@lists.webkit.org. > > If you notice anything awry, please let us know so we can investigate. > Thanks, > Lucas The git.webkit.org mirror doesn't seem to be operational. The server itself is up and running, but Git requests against it time out. Cheers, Zan > >> On Mar 27, 2017, at 5:36 PM, Lucas Forschler >> <lforsch...@apple.com> wrote: >> >> Hello everyone, >> >> Commits have been disabled on svn.webkit.org[1] while we update >> infrastructure. >> We will send a follow-up when the repository is back online. >> >> Thanks, >> Lucas >> >>> On Mar 27, 2017, at 11:31 AM, Ling Ho <lin...@apple.com> wrote: >>> >>> Hello WebKit developers, >>> >>> We will be switching and upgrading our Subversion and Git mirror >>> servers this evening at 5.30pm PDT. We will be stopping svn commit >>> at 5.30pm, and the new server should go into service shortly after >>> DNS change is made. We will send out another notice once commit is >>> possible again on the new server. >>> >>> Thanks, >>> ... >>> ling >>> >>> >>> >>> ___ >>> 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 Links: 1. http://svn.webkit.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] update GCC version?
On Sat, Jan 7, 2017, at 08:30 PM, Alex Christensen wrote: > We are looking into using more C++14 features in WebKit, which would require > increasing the minimum supported compiler versions. For example, Yusuke’s > patch in https://bugs.webkit.org/show_bug.cgi?id=165093 compiles successfully > in clang and I verified it compiles successfully in VS2017RC, but it does not > compile successfully in the minimum supported GCC version on linux because of > lack of support for C++14 extended constexpr (see > https://isocpp.org/wiki/faq/cpp14-language#extended-constexpr ) > > We are not ready to require VS2017 just yet. It hasn’t even been fully > released. But there are many C++14 features that are not supported in VS2015 > (see https://msdn.microsoft.com/en-us/library/hh567368.aspx and > https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes ) and we > would like to use these features in WebKit. > > Would the linux community be able to increase the minimum supported GCC > version? For the record, GCC 5 has complete C++14 support. The current requirement is 4.9, so the bump would be minimal. https://gcc.gnu.org/projects/cxx-status.html#cxx14 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit GPU rendering possibility
On Fri, Nov 4, 2016, at 02:34 PM, Rogovin, Kevin wrote: > Hi, > > >I should mention, though, that we require support for hardware that only > >supports OpenGL ES 2.0. > >If FastUIDraw can't handle this, then we would need to keep a fallback > >codepath that uses Cairo, which would be unfortunate. > > FastUIDraw requires features beyond what OpenGL ES 2.0 offers. With that > in mind, the fall back is needed. > > I cannot stress how unfortunate it is to have the burden of needing to > support hardware that only satisfies a specification that is nearly 10 > years old and whose feature set corresponds to far more ancient times > (essentially first generation DX9 cards, over 11 years ago). The jump in > flexibility in handling data between ES2.0 and ES3.0/3.1 is massive. > It is unfortunate, yet that is the reality for most of the Linux ports. WebKit can still run pretty darn nice on older hardware that only supports ES 2.0 (of course depending on the content), and there's enough interest to maintain that support. I don't think supporting OpenGL ES 2.0 in FastUIDraw should be a requirement, so we'll have to keep Cairo as a fallback and baseline rasterizer. > One question, what happens with WebGL 2.0 support on WebKit? I ask > because WebGL 2.0 is essentially OpenGL ES 3.x for JavaScript. > WebGL 2.0 wouldn't be supported on platforms that don't offer OpenGL ES 3.0. This should be manageable at runtime. Regards, Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fall 2016 WebKit Contributors Meeting – Call for Speakers
Hi, unfortunately nobody from Igalia will be attending this year. While we did plan to participate, the announcement came in too late for us to find any sensible travel plans. Hope to see you next year. Regards, Zan On Thu, Oct 20, 2016, at 11:32 PM, Jonathan Davis wrote: > We will be closing registration tomorrow! > > Time is running out and spaces are limited to register for the 2016 > WebKit Contributors Meeting. If you still wish to attend but haven’t > signed up, please register here: https://webkit.org/meeting/ > > There is also room for more presentations. We have presentation > capability at the venue, so slide decks and demos are welcome. If you > have a topic to present, please let me know as soon as possible so > that it can get on the schedule. You can reply to this thread, or > email me directly with your proposed topic. > > Thanks again everyone. I look forward to seeing you at the meeting! > > Best wishes, > Jon Davis > > > > >> On Oct 6, 2016, at 2:44 PM, Jonathan Davis <j...@apple.com> wrote: >> >> Hello WebKit Contributors, >> >> This is a reminder to please register for the WebKit Contributor’s >> Meeting at https://webkit.org/meeting to reserve your spot. The >> registration deadline has been extended to October 21st, but please >> don’t wait until then to register. Spots are reserved on a first-come >> first-serve basis. >> >> We’re also calling for speakers to propose talks this year. You can >> talk about things you are interested in working on, or areas of >> WebKit that need more attention. If you don’t have a large topic, >> but still have something you want to discuss with the group, you can >> pitch a lightning talk. Lightning talks are limited 5-10 minutes to >> provide a blitz of quick, focused information. >> >> If you haven’t already submitted a proposal to me, please reply to >> this thread, or email me directly with your proposed topic. >> >> Thank you all, >> Jon Davis > _ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > Email had 1 attachment: > * smime.p7s 5k (application/pkcs7-signature) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Windows Build Now on VS2015
On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote: The days of supporting VS2013 are behind us, so if it works with VS2015, go for it. Not all c++14 features are supported, though. See https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table I’m not sure what the oldest gcc we support is. The oldest GCC we support is 4.7.0. GCC 5.0 supports all but one C++14 proposal (which covers allocation optimizations and shouldn't be a blocker): https://gcc.gnu.org/projects/cxx1y.html Clang has full C++14 coverage since version 3.4, but I'm not aware of any incorporated check for a minimal Clang version. On Aug 14, 2015, at 5:49 AM, Antti Koivisto koivi...@iki.fi wrote: Does this mean we can start using (most) C++14 features? antti On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham bfulg...@apple.com wrote: Hi Floks, We’ve finished updating the various Windows builds to VS2015. Full regression tests are now completing on these new builds, and seem to be comparable in terms of stability and correctness. Please let me know if you encounter any new issues on Windows. I know that EA encountered some JavaScript issues in a prior revision, but I haven’t been able to replicate this problem (at least yet). VS2015 is churning out a number of new build warnings, which I hope to address over the coming weeks. It will also likely have some useful static analysis results in the Windows-specific portions of the code that we should evaluate. Thanks, -Brent ___ 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
Re: [webkit-dev] Windows Build Now on VS2015
On Tue, Aug 25, 2015, at 12:55 PM, Carlos Garcia Campos wrote: El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió: On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote: The days of supporting VS2013 are behind us, so if it works with VS2015, go for it. Not all c++14 features are supported, though. See https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table I’m not sure what the oldest gcc we support is. The oldest GCC we support is 4.7.0. Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused failures in the database process implementation (see bug #98932). The EFL port didn't, to the best of my knowledge. GCC 5.0 supports all but one C++14 proposal (which covers allocation optimizations and shouldn't be a blocker): https://gcc.gnu.org/projects/cxx1y.html My main concern is how stable those features are in GCC, though. Clang has full C++14 coverage since version 3.4, but I'm not aware of any incorporated check for a minimal Clang version. On Aug 14, 2015, at 5:49 AM, Antti Koivisto koivi...@iki.fi wrote: Does this mean we can start using (most) C++14 features? antti On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham bfulg...@apple.com wrote: Hi Floks, We’ve finished updating the various Windows builds to VS2015. Full regression tests are now completing on these new builds, and seem to be comparable in terms of stability and correctness. Please let me know if you encounter any new issues on Windows. I know that EA encountered some JavaScript issues in a prior revision, but I haven’t been able to replicate this problem (at least yet). VS2015 is churning out a number of new build warnings, which I hope to address over the coming weeks. It will also likely have some useful static analysis results in the Windows-specific portions of the code that we should evaluate. Thanks, -Brent ___ 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 ___ 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] Windows Build Now on VS2015
On Tue, Aug 25, 2015, at 02:35 PM, Osztrogonác Csaba wrote: Hi, On 2015-08-25 14:29, z...@falconsigh.net wrote: On Tue, Aug 25, 2015, at 12:55 PM, Carlos Garcia Campos wrote: El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió: On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote: The days of supporting VS2013 are behind us, so if it works with VS2015, go for it. Not all c++14 features are supported, though. See https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table I’m not sure what the oldest gcc we support is. The oldest GCC we support is 4.7.0. Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused failures in the database process implementation (see bug #98932). The EFL port didn't, to the best of my knowledge. EFL port already switched IndexedDB on by https://trac.webkit.org/changeset/187596 , so we need at least GCC 4.9 since then. But do you check for that version? Anyway, there's a check for 4.7.0 in Source/WTF/wtf/Compiler.h that is apparently redundant now. br, Ossy ___ 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] Sharing the OpenGL GraphicsContext3D implementation
Forgot to reply to all, sorry for the mess, webkit-dev :/ On Wed, Feb 23, 2011 at 7:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: You could just create a new Extension3DOpenGLGtk class that inherits from Extension3DOpenGL, and do your specific thing there. The goal here is to make OpenGL GC3D shareable, so using Extensions3D calls to extensions functions in that implementation would be replaced with something like getExtensions()-extensionsFunction(). I don't see this being possible without adding prototypes to Extensions3D class, not without some dirty hacks that cast Extensions3D class to an Extensions3DOpenGLGtk class in specific cases, or similar. If you don't mind, please add me (z...@google.com) and Ken (k...@google.com) to the cc list on the bug for this issue. Created bug #55072[1] fon this issue and added both to the CC list. [1] https://bugs.webkit.org/show_bug.cgi?id=55072 Zan (Below are the two messages in their entirety that weren't sent to the list.) On Wed, Feb 23, 2011 at 7:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: You could just create a new Extension3DOpenGLGtk class that inherits from Extension3DOpenGL, and do your specific thing there. If you don't mind, please add me (z...@google.com) and Ken (k...@google.com) to the cc list on the bug for this issue. Thank you. Mo On Wed, Feb 23, 2011 at 9:06 AM, Zan Dobersek zandober...@gmail.com wrote: On Wed, Feb 23, 2011 at 3:59 PM, Mo, Zhenyao zhen...@gmail.com wrote: We already have a mechanism installed to handle extensions. Look at WebCore/platform/graphics/Extension3D.h And we have chromium specific ones in WebCore/platform/graphics/chromium/Extension3DChromium.h Develop another mechanism to handle GL extensions would cause a mess. You should look into the above mentioned classes and see if they can be used in Gtk easily. If not, then we should look into refactoring it instead creating something totally new. To use the Extensions3D class, it should be modified, adding ~90 function prototypes to the class for Mac and Gtk platforms only, and then implement those in separate files, e.g. platform/graphics/mac/Extensions3DOpenGLMac.cpp (or .mm, dunno) and platform/graphics/gtk/Extensions3DOpenGLGtk.cpp. That's basically already being done for the glBlitFramebuffer and glRenderbufferStorageMultisample functions. If the Mac developers give a green light I can come up with a patch containing these changes and providing a Mac implementation in a reasonably short time. Zan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
Hi, I'm writing this mail in order to propose changes that would make the OpenGL implementation of the GraphicsContext3D a lot easier to share between the Mac and Gtk port. Currently the mentioned implementation is only used by the Mac port. The Gtk port is also interested in using this implementation and there is already a patch available in bug #31517[1] by Martin Robinson that brings the WebGL functionality to daylight. There is, however, the issue of the OpenGL extensions functions. Current OpenGL implementation is Mac-only, and Mac port has a specific set of extensions functions available. The same cannot be said for the Gtk port, which can end up having extensions functions available that do not have the same extension suffix as the Mac port's functions (EXT vs ARB). Because of that the current proposed implementation acquires addresses of the OpenGL extensions functions and then uses shims to make the GraphicsContext3D work. I recommend a new class to be created for these two ports to use, named something like OpenGLExtensionsFunctions. Extensions-specific functions in the GraphicsContext3D class would then be replaced with calls to the corresponding functions in this class, for example OpenGLExtensionsFunctions::blitFramebuffer instead of current ::glBlitFramebufferEXT. Implementation for the Mac port would be simple, passing arguments on to functions that are currently used in the GraphicsContext3D class. Gtk port's implementation would simply call the functions that were acquired, with no need to depend on shims. Modifying the OpenGL implementation of the GraphicsContext3D class in this way would ease the use of it for the Gtk port and perhaps any other port that would go on to use this implementation with no damage to the Mac port. I'd like to hear what Mac folks think of this approach and if there are any other ideas that address this problem. Regards, Zan Dobersek [1] https://bugs.webkit.org/show_bug.cgi?id=31517 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] disableing webkit plugins on gtk+ port
Luka Napotnik wrote: Hello. I'm trying to disable plugins on the gtk+ port of webkit. I've tried to modify the WebKitWebSettings property enable-plugins but my program segfaults. Here's the code: WebKitWebSettings *settings; ... settings = webkit_web_view_get_settings(web_view); g_object_set_property(G_OBJECT(settings), enable-plugins, FALSE); webkit_web_view_set_settings(web_view, settings); Am I doing this right or is there another way? Greets, Luka ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev Similarly to what's being done in DumpRenderTree.cpp [1], you should use g_object_set: ... settings = webkit_web_view_get_settings(web_view); g_object_set(G_OBJECT(settings), enable-plugins, FALSE, NULL); // webkit_web_view_set_settings is now not needed Regards, Zan Dobersek [1]http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/gtk/DumpRenderTree.cpp#L199 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
