Re: [webkit-dev] Plugin process

2020-07-19 Thread Brent Fulgham
We haven’t removed it from Apple builds yet, because we think there are still 
some WebKit clients that use them. I.e., WebKit framework users on the platform 
that are not Safari or one of the other web browsers.

We should take another look, because it would be great to get rid of it 
completely.

Thanks,

-Brent

> 
> On Jul 19, 2020, at 11:12 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> Is anybody still using the plugin process? I understand that Safari does not 
> allow plugins anymore. Epiphany doesn't either, nor does anything packaged in 
> Linux distros  (afaik). If nothing is using it, maybe we can delete a lot of 
> code? Is it exposed in Apple system APIs?
> 
> WebKitGTK still has an enable-plugins setting that is not yet deprecated. 
> Probably long past time to at least deprecate it. There's also, incredibly, 
> an enable-java setting, which I presume toggles the old Java browser plugin. 
> I sense there must be some history behind that setting. :)
> 
> 
> ___
> 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] Introducing a minimum ICU version for WebKit

2020-04-09 Thread Brent Fulgham
Please note that Per Arne updated the Apple ZIP files to have the correctly 
aligned ICU libraries, so the Windows bots should have what they need.

I apologize for taking so long to complete that.

Thanks,

-Brent

> On Apr 3, 2020, at 4:57 PM, Ryosuke Niwa  wrote:
> 
> 
> On Fri, Apr 3, 2020 at 4:25 PM Kirsling, Ross  > wrote:
> Hi everybody,
> 
>  
> 
> Just sending out an email blast for visibility regarding 
> https://bugs.webkit.org/show_bug.cgi?id=209694 
> .
> 
>  
> 
> This patch:
> 
> Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU 62, 
> matching Mojave
> Introduces a minimum ICU version of 60.2 throughout the codebase, as required 
> by GTK for Ubuntu 18.04 LTS
>  
> 
> As written in the ChangeLog, the immediate motivations are:
> 
> To properly establish a minimum ICU version for WebKit as a whole
> (responding to a pain point identified in 
> https://bugs.webkit.org/show_bug.cgi?id=209579 
> )
> To support the development of ECMA-402 Intl API features, which JSC is quite 
> behind on
> (and which often boil down to exposing ICU functionality to JavaScript)
>  
> 
> The only remaining concern of which I am aware is that AppleWin’s ICU 
> headers, stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU 
> 49 to 62 (to match the lib files stored in WebKitSupportLibrary.zip). We do 
> have a potential workaround for this (i.e. having CMake copy the Mac headers 
> to WebKitLibraries/win) but it is feared that this may break Apple-internal 
> builds and we would certainly like to avoid a revert if possible. Any help on 
> this front would be greatly appreciated.
> 
> 
> FWIW, I've been told that Brent / Per might be able to help you there but 
> might need some more time due to other more urgent commitments.
> 
> - R. Niwa
> 
> ___
> 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] Proposal: add Privacy to WebKit Project Goals

2020-02-24 Thread Brent Fulgham
I think this looks great!
-Brent

> On Feb 23, 2020, at 5:02 PM, Maciej Stachowiak  wrote:
> 
> 
> V2, with stronger privacy language.
> 
> 
> project-new.html
>   WebKit is an open source Web content engine for browsers and other 
> applications.
> 1212
> 1313
> 14 We value real-world web compatibility, standards compliance, stability, 
> performance, security, portability, usability, and relative ease of 
> understanding and modifying the code (hackability).
>  14We value real-world web compatibility, standards compliance, stability, 
> performance, battery life, security, privacy, portability, usability, and 
> relative ease of understanding and modifying the code (hackability).
> 1515Project Goals
> 1616Web Content Engine
> 17 The project’s primary focus is content deployed on the World Wide Web, 
> using standards-based technologies such as HTML, CSS, JavaScript and the DOM. 
> However, we also want to make it possible to embed WebKit in other 
> applications, and to use it as a general-purpose display and interaction 
> engine.
>  17The project’s primary focus is content deployed on the World Wide Web, 
> using standards-based technologies such as HTML, CSS, JavaScript and DOM. 
> However, we also want to make it possible to embed WebKit in other 
> applications, and to use it as a general-purpose display and interaction 
> engine.
> 1818Open Source
> 1919WebKit should remain freely usable for both open source and 
> proprietary applications. To that end, we use BSD-style and LGPL licenses. 
> Specifically, we aim for licensing compatible with LGPL 2.1+. We do not 
> currently plan to move to LGPL 3. In addition, we strive to create a 
> courteous, welcoming environment that feels approachable to newcomers. WebKit 
> maintains a public IRC chat room and a public mailing list where the ideas of 
> contributors both new and old are heard and discussed with equal weight.
> 2020Compatibility
> 
> 2424Stability
> 2525The main WebKit code base should always maintain a high degree of 
> stability. This means that crashes, hangs and regressions should be dealt 
> with promptly, rather than letting them pile up.
> 2626Performance
> 27 Maintaining and improving speed and memory use is an important goal. We 
> never consider performance “good enough”, but strive to constantly improve. 
> As web content becomes richer and more complex, and as web browsers run on 
> more limited devices, performance gains continue to have value even if normal 
> browsing seems fast enough.
>  27Maintaining and improving speed and memory use is an important goal. We 
> never consider performance “good enough”, but strive to constantly improve. 
> As web content becomes richer and more complex, and as web browsers run on 
> more limited devices, performance gains continue to have value even if normal 
> browsing seems fast enough. We consider speed, memory use, responsiveness and 
> frame rate to be important aspects of performance.
>  28Battery Life
>  29In addition to traditional performance metrics, we aim to minimize 
> power consumption to maximize browsing battery life for portable devices.
> 2830Security
> 2931Protecting users from security violations is critical. We fix security 
> issues promptly to protect users and maintain their trust.
>  32Privacy
>  33We believe privacy is a human right. WebKit code won't track the user 
> or otherwise violate their privacy. And we will strive to prevent websites 
> and other parties from doing so.
> 3034Portability
> 3135The WebKit project seeks to address a variety of needs. We want to 
> make it reasonable to port WebKit to a variety of desktop, mobile, embedded 
> and other platforms. We will provide the infrastructure to do this with tight 
> platform integration, reusing native platform services where appropriate and 
> providing friendly embedding APIs.
> 3236Usability

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

2020-02-16 Thread Brent Fulgham


> On Feb 16, 2020, at 12:39 PM, Maciej Stachowiak  wrote:
> 
> 
> There hasn’t been any feedback on this, so below is a proposed change (in 
> PrettyPatch HTML format) to  >.
> 
> In addition to adding Privacy as a goal, I also added Battery Life, and 
> tweaked a few of the existing goals.
> 
> Thoughts?
> 
> 
> project-new.html
> 
>  32Privacy
>  33Users want their privacy respected. We avoid directly violating the 
> user's privacy, and strive to prevent websites and other parties from doing 
> so.

The term “directly violating” sounds a little soft. Do we not care about 
indirect privacy violations?

I don’t know the right wording to use, but I would like to say something along 
the lines of:

“Users want their privacy respected. We avoid violating the user’s privacy, and 
strive to prevent websites and other parties form doing so, too. We view the 
UserAgent’s primary responsibility to be protecting the interests of the user. 
We therefore do not support or intend to implement web standards that are at 
odds with these goals, or that create mechanisms to fingerprint or otherwise 
monitor user behavior.”

Thanks,

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

2019-06-27 Thread Brent Fulgham
Apple is in the process of bringing up VS2019 now. I would be in favor of 
moving the minimum to 3.14 so we can safely support VS2019 compiles.

-Brent

> On Jun 24, 2019, at 8:21 PM, Fujii Hironori  wrote:
> 
> Hi,
> 
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
> 
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181 
> 
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
> 
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
> 
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>  
> Happy WebKit 18th  
> birthday  
> 
> 
> -- Fujii
> ___
> 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] New iOS versions sending bogus User-Agent build data

2018-04-27 Thread Brent Fulgham
Hi Colin,

> On Apr 26, 2018, at 8:57 AM, Colin Bendell | +1.613.914.3387 
>  wrote:
> 
> […] images to a device. I have a laundry list of other examples where the
> server might actually know more than the client to prevent a) a broken
> user experience and b) prevent cellular data waste.

Would you mind documenting those items in a Bugzilla report? We are interested 
in specific use cases that suffer with a frozen user agent string, and what 
(apparently bad) techniques you need to use to work around it.

Thanks,

-Brent



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HSTS user tracking

2018-03-01 Thread Brent Fulgham
Sure — I’ll ask Jon to get it scheduled to post.

> On Mar 1, 2018, at 11:50 AM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> 
>> On Mar 1, 2018, at 10:44 AM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
>> 
>> On Fri, Jan 5, 2018 at 3:11 PM, Brent Fulgham <bfulg...@apple.com> wrote:
>>> I´m sorry we haven´t been forthcoming with details. We have wanted to put 
>>> together a blog post explaining our fix, but have been preoccupied with a 
>>> number of other security issues.
>>> I will make this my top priority, or at least give a rough overview to the 
>>> webkit-security folks if we can´t put together a blog-worthy document fast 
>>> enough.
>>> Thanks,
>>> -Brent
>> 
>> Hi,
>> 
>> It'd still be great to get some details about your strategy for mitigating 
>> user tracking via HSTS.
>> 
>> It should be suitable for webkit-dev, rather than the private security list, 
>> right?
> 
> I think we should still publish the blog post, if it's at all close to ready. 
> Brent?
> 
> - Maciej
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HSTS user tracking

2018-01-05 Thread Brent Fulgham
I’m sorry we haven’t been forthcoming with details. We have wanted to put 
together a blog post explaining our fix, but have been preoccupied with a 
number of other security issues.

I will make this my top priority, or at least give a rough overview to the 
webkit-security folks if we can’t put together a blog-worthy document fast 
enough.

Thanks,

-Brent

> On Jan 5, 2018, at 12:58 PM, Maciej Stachowiak <m...@apple.com> wrote:
> 
> 
> Brent Fulgham or John Wilander would know the details.
> 
> - Maciej
> 
>> On Jan 5, 2018, at 8:04 AM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
>> 
>> 
>> Hi devs,
>> 
>> Any info about how to mitigate this problem would be appreciated. Thanks!
>> 
>> Michael
>> 
>> ___
>> 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] RFC: stop using std::chrono, go back to using doubles for time

2016-11-04 Thread Brent Fulgham
EWS Hates your patch! :-)

> On Nov 4, 2016, at 10:01 AM, Filip Pizlo  wrote:
> 
> Hi everyone!
> 
> That last time we talked about this, there seemed to be a lot of agreement 
> that we should go with the Seconds/MonotonicTime/WallTime approach.
> 
> I have implemented it: https://bugs.webkit.org/show_bug.cgi?id=152045 
> 
> 
> That patch just takes a subset of our time code - all of the stuff that 
> transitively touches ParkingLot - and converts it to use the new time 
> classes.  Reviews welcome!
> 
> -Filip
> 
> 
> 
>> On May 22, 2016, at 6:41 PM, Filip Pizlo > > wrote:
>> 
>> Hi everyone!
>> 
>> I’d like us to stop using std::chrono and go back to using doubles for time. 
>>  First I list the things that I think we wanted to get from std::chrono - 
>> the reasons why we started switching to it in the first place.  Then I list 
>> some disadvantages of std::chrono that we've seen from fixing 
>> std::chrono-based code.  Finally I propose some options for how to use 
>> doubles for time.
>> 
>> Why we switched to std::chrono
>> 
>> A year ago we started using std::chrono for measuring time.  std::chrono has 
>> a rich typesystem for expressing many different kinds of time.  For example, 
>> you can distinguish between an absolute point in time and a relative time.  
>> And you can distinguish between different units, like nanoseconds, 
>> milliseconds, etc.
>> 
>> Before this, we used doubles for time.  std::chrono’s advantages over 
>> doubles are:
>> 
>> Easy to remember what unit is used: We sometimes used doubles for 
>> milliseconds and sometimes for seconds.  std::chrono prevents you from 
>> getting the two confused.
>> 
>> Easy to remember what kind of clock is used: We sometimes use the monotonic 
>> clock and sometimes the wall clock (aka the real time clock).  Bad things 
>> would happen if we passed a time measured using the monotonic clock to 
>> functions that expected time measured using the wall clock, and vice-versa.  
>> I know that I’ve made this mistake in the past, and it can be painful to 
>> debug.
>> 
>> In short, std::chrono uses compile-time type checking to catch some bugs.
>> 
>> Disadvantages of using std::chrono
>> 
>> We’ve seen some problems with std::chrono, and I think that the problems 
>> outweigh the advantages.  std::chrono suffers from a heavily templatized API 
>> that results in template creep in our own internal APIs.  std::chrono’s 
>> default of integers without overflow protection means that math involving 
>> std::chrono is inherently more dangerous than math involving double.  This 
>> is particularly bad when we use time to speak about timeouts.
>> 
>> Too many templates: std::chrono uses templates heavily.  It’s overkill for 
>> measuring time.  This leads to verbosity and template creep throughout 
>> common algorithms that take time as an argument.  For example if we use 
>> doubles, a method for sleeping for a second might look like 
>> sleepForSeconds(double).  This works even if someone wants to sleep for a 
>> nanoseconds, since 0.01 is easy to represent using a double.  Also, 
>> multiplying or dividing a double by a small constant factor (1,000,000,000 
>> is small by double standards) is virtually guaranteed to avoid any loss of 
>> precision.  But as soon as such a utility gets std::chronified, it becomes a 
>> template.  This is because you cannot have sleepFor(std::chrono::seconds), 
>> since that wouldn’t allow you to represent fractions of seconds.  This 
>> brings me to my next point.
>> 
>> Overflow danger: std::chrono is based on integers and its math methods do 
>> not support overflow protection.  This has led to serious bugs like 
>> https://bugs.webkit.org/show_bug.cgi?id=157924 
>> .  This cancels out the 
>> “remember what unit is used” benefit cited above.  It’s true that I know 
>> what type of time I have, but as soon as I duration_cast it to another unit, 
>> I may overflow.  The type system does not help!  This is insane: std::chrono 
>> requires you to do more work when writing multi-unit code, so that you 
>> satisfy the type checker, but you still have to be just as paranoid around 
>> multi-unit scenarios.  Forgetting that you have milliseconds and using it as 
>> seconds is trivially fixable.  But if std::chrono flags such an error and 
>> you fix it with a duration_cast (as any std::chrono tutorial will tell you 
>> to do), you’ve just introduced an unchecked overflow and such unchecked 
>> overflows are known to cause bugs that manifest as pages not working 
>> correctly.
>> 
>> I think that doubles are better than std::chrono in multi-unit scenarios.  
>> It may be possible to have std::chrono work with doubles, but this probably 
>> implies us writing our own clocks.  std::chrono’s default clocks use 
>> integers, not doubles.  It also may be possible to 

Re: [webkit-dev] WebKit GPU rendering possibility

2016-11-03 Thread Brent Fulgham
I would suggest “http://browserbench.org/MotionMark 
”. :-)

-Brent

> On Nov 3, 2016, at 12:17 PM, Rogovin, Kevin  wrote:
> 
> Hi,
> 
> What are some good 2D UI graphics benchmarks that are cross-platform-ish? I'd 
> think I need to port them to Fast UI Draw, but that is possible.
> 
> I am very confident that Fast UI Draw will perform at the top by a large 
> margin. The more complicated and heavier the load, the better it will do.
> 
> -Kevin
> 
> -Original Message-
> From: mmaxfi...@apple.com [mailto:mmaxfi...@apple.com] 
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin 
> Cc: Carlos Garcia Campos ; webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> It sounds like the primary focus of your work is improving performance. It 
> also sounds like the only benchmark you’ve run is an artificial one that you 
> constructed yourself.
> 
> Given these two things, I would strongly hesitate to call our interest 
> "significant community enthusiasm.”
> 
> Why don’t you start by running some of the many existing graphics benchmarks 
> with your library?
> 
> Please correct me if my assumptions are mistaken.
> 
> Thanks,
> Myles
> 
>> On Nov 3, 2016, at 12:50 AM, Rogovin, Kevin  wrote:
>> 
>> Adding a new GraphicsContext is what I want to do as it seems the path of 
>> least pain and suffering. However, all the other things of a backend I do 
>> not need to do. I do not know how to add a GraphicsContext backend in terms 
>> of makefile magicks and configuration. I also do not know the plumbing for 
>> making it active. In theory, FastUIDraw's GraphicsContext will work on any 
>> platform that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do 
>> this? Years ago I remember that the build configuration is what governed 
>> what backend was built... and I usually just piggy packed onto another... 
>> years ago I remember there was like an SDL style backend that did not 
>> require a large toolkit, just SDL.. is that still alive? where is it? I 
>> could piggy back the work there if it still is alive...
>> 
>> Also, to get permission to do this work, I need significant community 
>> enthusiasm otherwise I will not be able to justify the large amount of work 
>> needed. This is another area where I need a great deal of help.
>> 
>> Best Regards,
>> -Kevin Rogovin
>> 
>> -Original Message-
>> From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
>> Sent: Thursday, November 3, 2016 9:43 AM
>> To: Rogovin, Kevin ; Myles C. Maxfield 
>> 
>> Cc: webkit-dev@lists.webkit.org
>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>> 
>> El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
>>> Hi,
>>> 
>>> The main issue of making a Cairo backend to FastUIDraw is clipping.
>>> Cairo tracks the clipping region in CPU and does things that are fine 
>>> for CPU-based rendering (i.e. span based rendering) but are 
>>> absolutely awful for GPU rendering (from my slides, one sees that GL 
>>> backed QPainter and Cairo do much worse than CPU backed). FastUIDraw 
>>> only supports clipIn and clipOut and pushes all the clipping work to 
>>> the GPU with almost no CPU work. It does NOT track the clipping 
>>> region at all. I can give more technical details how it works (and 
>>> those details are why FastUIDraw cannot be used a backend for Cairo).
>>> For those interested in where the code is located for clipping in 
>>> FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
>>> methods clipInRect, clipOutPath and clipInPath. Their implementations 
>>> are very short and simple and are quite cheap on CPU.
>> 
>> I see. Then I guess adding a new GraphicsContext for FastUIDraw is the 
>> easiest and best way to try this out in WebKit. Would it be possible to  
>> just add a new GraphicsContext implementation? or would you also need to 
>> change other parts of the graphics implementation or the GraphicsContext API 
>> itself?
>> 
>>> Best Regards,
>>> -Kevin
>>> 
>>> -Original Message-
>>> From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
>>> Sent: Thursday, November 3, 2016 9:27 AM
>>> To: Rogovin, Kevin ; Myles C. Maxfield >> fi...@apple.com>
>>> Cc: webkit-dev@lists.webkit.org
>>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>> 
>>> El jue, 03-11-2016 a las 06:58 +, Rogovin, Kevin escribió:
 Hi!
 
 Question answers:
 1.  Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL 
 ES 3.0. One of its design goals is to make it not terribly awful to 
 write a backend to different 3D API’s.
 2.  I think I was unclear in my video. I have NOT migrated ANY 
 UI rendering library to use Fast UI Draw. What I have done is made a 
 demo
 (painter-cells) 

Re: [webkit-dev] Proposal: Remove Battery Status API code

2016-10-30 Thread Brent Fulgham
I strongly support the proposal to remove this API.

-Brent

> On Oct 30, 2016, at 5:54 PM, Simon Fraser  wrote:
> 
> I support the proposal to remove.
> 
> Simon
> 
>> On Oct 30, 2016, at 5:14 PM, Brady Eidson  wrote:
>> 
>> 
>> There's code in the tree to support the W3C Battery Status API.
>> 
>> A recent study showed the extent of the risk (discussion and link to study 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.lukaszolejnik.com_battery-2Dstatus-2Dreadout-2Das-2Da-2Dprivacy-2Drisk_=CwICAg=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84=gEUmSR3VtC-5Q3Im6T2Js1aXwjJK4RExonGEvDq2twI=ZKSbJXtXvUd44zKls9LfZwY1fsH0NRSg8KxOY7clZdI=8c9qMq7SAf9mAh8t9oHbJE45_tXRsbZBMid46hd9UXs=
>>  ) which led to Mozilla first making the API less precise 
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1124127) but then eventually 
>> removing it altogether (https://bugzilla.mozilla.org/show_bug.cgi?id=1313580)
>> 
>> Apple has never enabled this on their ports, one reason being concern for 
>> abuse in fingerprinting/tracking. 
>> The study seems to be a strong second opinion backing this concern.
>> Mozilla's actions demonstrate another vendor not seeing the API being useful 
>> enough to outweigh the user concern.
>> 
>> As one of the voices for Apple's ports I think the above episode further 
>> cements our concern in ever enabling the API.
>> 
>> As one of the voices for WebKit as a whole I think above episode suggests we 
>> should just remove the code from the tree altogether.
>> 
>> What to other Apple folks think? What do port maintainers who enable the API 
>> think?
>> 
>> Thanks,
>> ~Brady
> 
> ___
> 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] WinCairo Maintainers

2016-09-26 Thread Brent Fulgham

> On Sep 26, 2016, at 12:55 PM, Olmstead, Don  wrote:
> 
> @annulen I know you've mentioned conan.io before but I've never personally 
> used it so I'm not sure how well it would fit with everything. It's something 
> we can take a look at beforehand and see what it would take vs the single 
> repository setup.
> 
> @alexchristensen I can make a GitHub org  push the repository to it and then 
> start using GitHub releases to host the final binary.
> 
> Do either of you know of anyone who is shipping a product based on WinCairo 
> though?

1. Electronic Arts uses the WinCairo/Cairo backend as the basis for their port, 
though I’m not sure how closely it follows the upstream sources. I believe they 
do use Cairo for drawing, but do not use the Linux or Windows-specific WebKit 
code paths.

They seem pretty quiet on the list lately, though they are on the 
webkit-security list and seem to respond to notes on that list.

2. Wyatt Technology used WinCairo for its reporting tool in its ASTRA software 
>. As far as I know they are 
still using it, though I’m not sure how up-to-date their copy of the library is.

I think Alex knows of at least one other user out there.

Thanks,

-Brent



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] MathML refactoring: Project Complete!

2016-07-13 Thread Brent Fulgham
Thank you for all of this work, Frédéric! I don’t think our WebML rendering has 
ever looked so good! :-)

-Brent

> On Jul 13, 2016, at 10:22 AM, Frédéric WANG  wrote:
> 
> Hi WebKit developers,
> 
> We are happy to announce that we are done with the MathML refactoring
> proposed last December [1]. The first phase was a big clean up of the
> MathML implementation and you can find details in a first blog post [2]
> but essentially:
> 
> * MathML renderer classes now derive from RenderBlock instead of
> RenderFlexible (except RenderMathMLTable which still derives from
> RenderTable) so we no longer interfere with the flexbox code.
> * MathML renderer classes do not create anonymous renderers any more
> (except RenderMathMLFenced which creates anonymous
> RenderMathMLOperators) so the render tree essentially matches the DOM tree.
> * MathML renderer classes now perform simple box layout (again except
> for RenderMathMLTable and RenderMathMLFenced) and should be much more
> consistent with the rest of the WebKit code.
> 
> Many MathML rendering bugs have been fixed as an immediate consequence
> of this clean up. But it also became much easier to follow OpenType MATH
> & TeX rules for layout [3] and to implement important MathML features.
> This has been done in a second phase and you can find details on the
> MathML improvements in a second blog post [4].
> 
> During the development, we also decided to include a third phase: Moving
> the parsing of MathML attributes into the DOM classes instead of doing
> it in the renderer classes. This has only been partially achieved but
> could be addressed in future developments. For those who are interested,
> it is tracked in [5].
> 
> Finally, we tested the rendering on GTK, EFL, OS X and iOS ports and it
> seems good. The status of the Windows port is unknown. We expanded the
> test suite with more MathML tests and performed some gardening:
> * All the tests pass on the GTK bots.
> * All but the mismatch tests pass on EFL bots (it's not clear whether
> screenshots are correctly taken).
> * As discussed in a previous thread, OS X and iOS bots lack
> pre-installed math fonts [6] and these fonts are not whitelisted by the
> test runner. Most of the failures were due to tests requiring such math
> fonts and so these tests are now skipped.
> * The Windows port also has several unexplained failures but someone
> should analyze that more carefully.
> 
> We plan to continue MathML developments in the future including
> finishing some refactoring (RenderMathMLTable, attribute parsing...) and
> improving MathML support and rendering quality.
> 
> Thank you again to all the people who made this contribution possible!
> 
> Frédéric, for the Igalia's Web Platform Team
> 
> [1] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring
> [2] http://frederic-wang.fr/mathml-refactoring-in-webkit.html
> [3] http://www.mathml-association.org/MathMLinHTML5/
> [4] http://frederic-wang.fr/mathml-improvements-in-webkit.html
> [5] https://webkit.org/b/156536
> [6] https://trac.webkit.org/wiki/MathML/Fonts
> 
> 
> ___
> 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] Windows Bot Updates

2016-05-03 Thread Brent Fulgham
Hi Everyone,

I have just reviewed the full set of Windows EWS and build bots, and updated 
them as follows:

1. Perl 5.18 or newer, which matches the Perl shipped with Mac OS.
2. Visual Studio 2015, Update 2. This fixes a number of C++ compatibility 
issues.

At this point, it should not be necessary to have Windows-specific C++ hacks in 
the code.

Most of the places where I knew we had worked around VC++ compiler bugs were 
commented. We have now removed all such commented hacks.

Please let me know if you are aware of any other cases where we were forced to 
use less efficient or more complicated code to work around an issue with Visual 
C++. We should be able to remove those hacks now.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Is someone going to fix Windows EWS?

2016-03-30 Thread Brent Fulgham
This is happening because “Font.h” is referring to 
“”, which doesn’t always exist on Windows at the 
time the file is compiled. The CoreGraphicsSPI.h file lives in 
“WebCore/platform/spi/cg/CoreGraphicsSPI.h”, and can be found with a normal 
‘#include “CoreGraphicsSPI.h”. It’s only after a post-build step copies the 
file to “DerivedSources/ForwardingHeaders/WebCore/CoreGraphicsSPI.h” that the 
‘#include ” form works.

When a non-clean build is performed, this is fine, so EWS probably works 
properly most of the time. But if something prompts it to clean the build 
output, the file doesn’t exist and the build fails, improperly blaming the 
current patch.

I’ll talk to Alex about the copy phase of these headers and see if we can get 
this into proper position earlier.

Thanks,

-Brent


> On Mar 30, 2016, at 9:28 AM, Alexey Proskuryakov <aproskurya...@gmail.com> 
> wrote:
> 
> 
> They fail like this: 
> https://webkit-queues.webkit.org/queue-status/win-ews/bots/ews202https://webkit-queues.webkit.org/results/1069527
> 
> c:\cygwin\home\buildbot\webkit\source\webcore\platform\graphics\Font.h(57): 
> fatal error C1083: Cannot open include file: 'WebCore/CoreGraphicsSPI.h': No 
> such file or directory (compiling source file 
> C:\cygwin\home\buildbot\WebKit\Source\WebCore\DerivedSources.cpp) 
> [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCoreDerivedSources.vcxproj]
> 
> It's quite surprising that the build passes after rolling out a patch, thus 
> making EWS think that the patch is to blame. 
> 
> - Alexey
> 
> 
> 
>> 30 марта 2016 г., в 9:20, Brent Fulgham <bfulg...@apple.com> написал(а):
>> 
>> Aside from ews206 being offline for some reason, all bot seem to be running 
>> without any errors.
>> 
>> Can you point me at a couple of the patches you were looking at? I 
>> spot-checked a couple in the Review Queue and they seemed to be failing for 
>> legitimate problems with the patches.
>> 
>> Thanks,
>> 
>> -Brent
>> 
>>> On Mar 30, 2016, at 9:04 AM, Brent Fulgham <bfulg...@apple.com> wrote:
>>> 
>>> Looking now.
>>> 
>>> -Brent
>>> 
>>>> On Mar 30, 2016, at 9:02 AM, Darin Adler <da...@apple.com> wrote:
>>>> 
>>>> Every patch I look at has a red bubble for Windows on EWS. Is someone 
>>>> planning on fixing this?
>>>> 
>>>> — Darin
>>>> ___
>>>> 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] Is someone going to fix Windows EWS?

2016-03-30 Thread Brent Fulgham
Aside from ews206 being offline for some reason, all bot seem to be running 
without any errors.

Can you point me at a couple of the patches you were looking at? I spot-checked 
a couple in the Review Queue and they seemed to be failing for legitimate 
problems with the patches.

Thanks,

-Brent

> On Mar 30, 2016, at 9:04 AM, Brent Fulgham <bfulg...@apple.com> wrote:
> 
> Looking now.
> 
> -Brent
> 
>> On Mar 30, 2016, at 9:02 AM, Darin Adler <da...@apple.com> wrote:
>> 
>> Every patch I look at has a red bubble for Windows on EWS. Is someone 
>> planning on fixing this?
>> 
>> — Darin
>> ___
>> 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] Is someone going to fix Windows EWS?

2016-03-30 Thread Brent Fulgham
Looking now.

-Brent

> On Mar 30, 2016, at 9:02 AM, Darin Adler  wrote:
> 
> Every patch I look at has a red bubble for Windows on EWS. Is someone 
> planning on fixing this?
> 
> — Darin
> ___
> 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] Proposal: Use #pragma once instead of header guards

2016-03-09 Thread Brent Fulgham

> On Mar 9, 2016, at 5:27 PM, Anders Carlsson  wrote:
> 
> I propose that we instead start using
> 
> #pragma once

+1
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

2016-03-03 Thread Brent Fulgham
+1. I am in favor of this as well!

-Brent

> On Mar 3, 2016, at 11:23 AM, Saam barati  wrote:
> 
> +1.
> I like how “override” only reads.
> 
> Saam
> 
>> On Mar 3, 2016, at 9:54 AM, Ryosuke Niwa  wrote:
>> 
>> I think "virtual" + "override" is more of a historical artifact than
>> the preferred style because we used to have OVERRIDE macro before all
>> compilers supported C++11.  I think we should just use only "override"
>> going forward.
>> - R. Niwa
>> 
>> 
>> On Thu, Mar 3, 2016 at 9:38 AM, Darin Adler  wrote:
>>> Antti proposed using only “override” a while back since it’s less verbose 
>>> and still unambiguous. I don’t think we reached consensus on which style to 
>>> prefer for the project, though.
>>> 
>>> — Darin
>>> ___
>>> 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] Crash Traces on Windows Now Functional

2015-10-15 Thread Brent Fulgham
Hi Folks!

Our Windows test bots have long been unable to produce usable stack traces when 
crashes were encountered. I’m pleased to announce that I finally fixed this 
problem.

Now that this is working, I would appreciate your help:

1. Please let me know if you see crashes happening on Windows, but do not find 
a relevant stack trace.
2. Please let me know if the stack trace for a crash seems unrelated to the 
test it is associated with.
3. Finally, please use the stack traces to help fix any crashes introduced by 
your changes! :-)

Thanks,

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake on Windows

2015-09-29 Thread Brent Fulgham
Hi Youenn,

We are using native CMake from the Windows command line, though I believe the 
Cygwin version should work.

I have a longer-term goal of being able to do development without requiring 
Cygwin, though we are a long way from achieving that just yet.

Thanks,

-Brent

> On Sep 29, 2015, at 12:36 AM, youenn fablet <youe...@gmail.com> wrote:
> 
> Awesome !
> 
> Quick question: is CMake used from cygwin?
> Also, is there a current/future Windows build efficiency benefit?
>y
> 
> Le mar. 29 sept. 2015 à 06:34, Mital Vora <mital.d.v...@gmail.com 
> <mailto:mital.d.v...@gmail.com>> a écrit :
> Great job guys !
> 
> On Sep 29, 2015 4:31 AM, "Brent Fulgham" <bfulg...@apple.com 
> <mailto:bfulg...@apple.com>> wrote:
> Yes — this is great work!
> 
> We’re still working through a few rough edges, but very soon we can get rid 
> of the whole Windows-specific build cruft, which will be a happy day.
> 
> Thanks,
> 
> -Brent
> 
> > On Sep 28, 2015, at 3:03 PM, Michael Catanzaro <mcatanz...@igalia.com 
> > <mailto:mcatanz...@igalia.com>> wrote:
> >
> > On Mon, 2015-09-28 at 13:28 -0700, Alex Christensen wrote:
> >> All the Windows buildbots are now using Windows.  We are planning to
> >> leave all the Visual Studio projects in the tree for a couple weeks,
> >
> > Thanks Alex! It sounds like you're planning to remove the Visual Studio
> > projects in a couple weeks, and it's great news that we'll soon be rid
> > of another build system.
> >
> > Michael
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev 
> > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] CMake on Windows

2015-09-28 Thread Brent Fulgham
Yes — this is great work!

We’re still working through a few rough edges, but very soon we can get rid of 
the whole Windows-specific build cruft, which will be a happy day.

Thanks,

-Brent

> On Sep 28, 2015, at 3:03 PM, Michael Catanzaro  wrote:
> 
> On Mon, 2015-09-28 at 13:28 -0700, Alex Christensen wrote:
>> All the Windows buildbots are now using Windows.  We are planning to
>> leave all the Visual Studio projects in the tree for a couple weeks,
> 
> Thanks Alex! It sounds like you're planning to remove the Visual Studio
> projects in a couple weeks, and it's great news that we'll soon be rid
> of another build system.
> 
> Michael
> ___
> 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] WinCairo Stability

2015-08-21 Thread Brent Fulgham
Alex Christensen does keep the WinCairo port up and running, and we have a 
build bot that tracks that.

Unfortunately, we don’t have an active WinCairo test bot, so it’s not always 
possible to know when something is broken in a subtle way on that port.

Please let us know what you find out!

Thanks,

-Brent

 On Aug 21, 2015, at 3:54 PM, Vienneau, Christopher cvienn...@ea.com wrote:
 
 Thanks Darin,
 
 I've got my release build up now which is sufficient to do some more 
 verification that I wanted to do.  I hadn't known about the build dashboard, 
 that will be a handy tool for me in the future.
 
 Chris
 
 -Original Message-
 From: Darin Adler [mailto:da...@apple.com] 
 Sent: Friday, August 21, 2015 3:16 PM
 To: Vienneau, Christopher cvienn...@ea.com
 Cc: WebKit Development webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] WinCairo Stability
 
 These all look like backtraces from assertion failures. If you are working on 
 WebKit, the next step would be to figure out which assertion is failing.
 
 If you’re looking for greater stability, you could try a release build 
 instead of a debug build, which won’t include the assertions.
 
 I’m not sure if there’s anyone actively trying to keep the WinCairo port 
 working well. It doesn’t have a build bot on the Dashboard 
 https://build.webkit.org/dashboard/ so I there’s no easy way for WebKit 
 contributors to notice if platform-specific bugs are introduced.
 
 — Darin
 ___
 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] Windows Build Now on VS2015

2015-08-11 Thread Brent Fulgham
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] Migrating to Visual Studio 2015

2015-08-06 Thread Brent Fulgham
Hi Everyone,

Now that Visual Studio 2015 Express is available for download, I would like to 
migrate our Windows builds over to the new compiler.

This will allow us to start taking advantage of more C++14 features, as well as 
allowing us to remove a number of workarounds we’ve held in our code base to 
work around compiler errors.

If this poses a problem for anyone currently working on WebKit, please contact 
me so that we can take appropriate steps to avoid any problems.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] border-radius lost when applying -webkit-filter

2015-07-30 Thread Brent Fulgham
I'll see if I can reproduce this using our Apple Windows port, which also uses 
GraphicsLayerCA, though one based on  Windows graphics primitives.

The WinCairo compositor is based on the OpenGL ES backend, via the ANGLE 
library. Alex Christensen knows more about how that works.

Thanks,

-Brent

Sent from my iPad

 On Jul 30, 2015, at 2:26 PM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 I'm testing on the Mac OS X port, which uses GraphicsLayerCA.
 
 Sounds like a bug with whichever compositor the win-cairo port is using, 
 which I am not familiar with.
 
 --Myles
 On Jul 29, 2015, at 10:24 AM, Vienneau, Christopher cvienn...@ea.com wrote:
 
 Thanks Myles,
  
 Before I go through the effort of re-integrating, a few questions about your 
 test:
  
 Which port are you testing on? I had been able to repro in our demo and the 
 win-cairo demo (both using the 179714 build). 
 Are you are using the GraphicsLayerCA as I mentioned below? If so regardless 
 that your version is newer than mine, it *might* be why it’s working.
  
 Chris
  
 From: Myles C. Maxfield [mailto:mmaxfi...@apple.com] 
 Sent: Tuesday, July 28, 2015 5:36 PM
 To: Vienneau, Christopher
 Cc: Webkit Development List
 Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter
  
 This works for me using the latest ToT build. I would recommend updating 
 your source tree.
  
 --Myles
 On Jul 28, 2015, at 4:52 PM, Vienneau, Christopher cvienn...@ea.com wrote:
  
 Hi,
  
 I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this 
 issue where border radius is lost if a css filter is also applied.  My 
 sample page looks like this:
 !DOCTYPE html
  
 html
 titleBasic CSS Filters/title
 headBasic CSS Filters/head
  
 style
 #pic {
   border-radius: 10px;
   -webkit-filter: sepia(0.8);
 }
 /style
  
 body
 div
   img id=pic src=testImage.jpg
 /div
 /body
 /html
  
 When I run with the above code the image is rendered with the Sepi filter, 
 but the border radius is not applied.  If I comment out the filter the image 
 is properly rendered with the border radius applied.  By debugging I can see 
 that a different code path is followed in the two cases.  
 Without the filter:
  WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path 
   path, WebCore::WindRule windRule) Line 951C++
WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const 
 WebCore::FloatRoundedRect  rect) Line 586 C++

 WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext
  * context, const WebCore::FloatRect  rect, const WebCore::FloatRoundedRect 
  clipRect) Line 540  C++
WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo 
  paintInfo, const WebCore::LayoutPoint  paintOffset) Line 180  C++
 …
 we get into clipRoundedInnerRect which goes into the code which can perform 
 the clipping operation, and all works as expected.
  
 With the Filter (3 callstacks below):
  
  WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
  WebCore::FloatRoundedRect  roundedRect) Line 377  C++

 WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents() Line 1960 
C++

 WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration() Line 595  
 C++

 WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
   layer, WTF::VectorWebCore::GraphicsLayer *,0,WTF::CrashOnOverflow  
 childLayersOfEnclosingLayer, int depth) Line 1522 C++
 …
  
  
  WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
  WebCore::FloatRoundedRect  roundedRect) Line 377  C++
WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
 Line 1124   C++

 WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003  
 C++

 WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
   layer, WTF::VectorWebCore::GraphicsLayer *,0,WTF::CrashOnOverflow  
 childLayersOfEnclosingLayer, int depth) Line 1609 C++
 …
  
  WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
  WebCore::FloatRoundedRect  roundedRect) Line 377  C++
WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
 Line 1124   C++

 WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003  
 C++
 
 WebKitd.dll!WebCore::RenderLayerCompositor::updateCompositingDescendantGeometry(WebCore::RenderLayer
   compositingAncestor, WebCore::RenderLayer  layer, bool 
 compositedChildrenOnly) Line 1862   C++
 …
  
 In this path we never call clipRoundedInnerRect, we do however call 
 setContentsClippingRect with what looks like appropriate parameters to do 
 what we would want.  However upon 

Re: [webkit-dev] Compilation issue with VS2015RC

2015-07-10 Thread Brent Fulgham
Hi Chris,

We noticed the same thing. Please see 
https://bugs.webkit.org/show_bug.cgi?id=146579, where we are discussing how 
to move forward.

Thanks!

-Brent

 On Jul 10, 2015, at 4:05 PM, Vienneau, Christopher cvienn...@ea.com wrote:
 
 Hello,
  
 Recently we’ve been attempting to move our code base to build with VS2015 RC 
 since this provides us with some support that we’ll be needing in the future 
 for our products.  The changes for compilation with the new compiler haven’t 
 been too bad, and I have everything building with the exception of one line:
  
 FILE: JSCSSValueCustom.cpp
 Line95:
 67   JSValue toJS(ExecState*, JSDOMGlobalObject* globalObject, 
 CSSValue* value)
 68   {
 69   if (!value)
 70   return jsNull();
 71   
 72   // Scripts should only ever see cloned CSSValues, never the 
 internal ones.
 73   ASSERT(value-isCSSOMSafe());
 74   
 75   // If we're here under erroneous circumstances, prefer 
 returning null over a potentially insecure value.
 76   if (!value-isCSSOMSafe())
 77   return jsNull();
 78   
 79   JSObject* wrapper = getCachedWrapper(globalObject-world(), 
 value);
 80   
 81   if (wrapper)
 82   return wrapper;
 83   
 84   if (value-isWebKitCSSTransformValue())
 85   wrapper = CREATE_DOM_WRAPPER(globalObject, 
 WebKitCSSTransformValue, value);
 86   else if (value-isWebKitCSSFilterValue())
 87   wrapper = CREATE_DOM_WRAPPER(globalObject, 
 WebKitCSSFilterValue, value);
 88   else if (value-isValueList())
 89   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSValueList, 
 value);
 90   else if (value-isSVGPaint())
 91   wrapper = CREATE_DOM_WRAPPER(globalObject, SVGPaint, 
 value);
 92   else if (value-isSVGColor())
 93   wrapper = CREATE_DOM_WRAPPER(globalObject, SVGColor, 
 value);
 94   else if (value-isPrimitiveValue())
 95   wrapper = CREATE_DOM_WRAPPER(globalObject, 
 CSSPrimitiveValue, value);
 96   else
 97   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSValue, 
 value);
 98   
 99   return wrapper;
 100 }
  
 It produces the linker error:
 JSBindingsAllInOne.obj : error LNK2019: unresolved external symbol public: 
 __thiscall WebCore::CSSPrimitiveValue::operatorclass WTF::Refclass 
 WebCore::CSSPrimitiveValue  class WTF::Refclass 
 WebCore::CSSPrimitiveValue(void)const  
 (??$?BV?$Ref@VCSSPrimitiveValue@WebCore@@@WTF@@@CSSPrimitiveValue@WebCore@@QBE?AV?$Ref@VCSSPrimitiveValue@WebCore@@@WTF@@XZ)
  referenced in function class WebCore::JSDOMWrapper * __cdecl 
 WebCore::createWrapperclass WebCore::JSCSSPrimitiveValue,class 
 WebCore::CSSPrimitiveValue(class WebCore::JSDOMGlobalObject *,class 
 WebCore::CSSPrimitiveValue *) 
 (??$createWrapper@VJSCSSPrimitiveValue@WebCore@@VCSSPrimitiveValue@2@@WebCore@@YAPAVJSDOMWrapper@0@PAVJSDOMGlobalObject@0@PAVCSSPrimitiveValue@0@@Z)
  
 As you can see there are many other similar code lines in the area, none of 
 which cause a problem.  Despite my many attempts I can’t seem to satisfy the 
 linker by providing it the definition it needs.
 · I’ve attempted manually adding the copy constructor definition (I 
 believe that is what it is describing):
 o   CSSPrimitiveValue::CSSPrimitiveValue(ClassType classType, const 
 CSSPrimitiveValue cloneFrom)
 o   CSSPrimitiveValue::CSSPrimitiveValue(const CSSPrimitiveValue cloneFrom)
 · I’ve tried removing the usage of the “AllInOne” file, thinking that 
 it may be causing some issue.
 · I’ve attempted to debug the code when the offending line is 
 commented out, hoping to see better how the other lines function.  Though I’m 
 not sure what path would cause it to execute, I haven’t hit it in my limited 
 testing.
 · One of my colleagues reached out the MS on the issue, but it 
 behaves as expect on their end (small sample code does not find a bug in the 
 compiler). 
 https://social.msdn.microsoft.com/Forums/en-US/6b9787f3-62bd-473a-8aa1-5f6cd85ed87b/breaking-change-in-visual-studio-2015-rc?forum=vcgeneral
  
 https://social.msdn.microsoft.com/Forums/en-US/6b9787f3-62bd-473a-8aa1-5f6cd85ed87b/breaking-change-in-visual-studio-2015-rc?forum=vcgeneral
  
  
 Any suggestions would be much appreciated
  
 Thanks
  
 Chris
  
  
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 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] Please be careful with webkitpy changes!

2015-04-01 Thread Brent Fulgham
The Windows EWS bots process patches fairly quickly. Once I corrected the 
problem today, it managed to process about 97 patches in about an hour.

I do think one bottleneck is due to individual EWS bots “locking” patches. The 
first bot to reach a patch locks the patch against other bots handling it. If 
the patch happens to be ‘consumed’ be a bot with some kind of problem (e.g., 
bad local configuration, a full disk drive, etc.), that patch will not be 
touched again — even if the other eight EWS bots are sitting dormant.

Is there some other processing metric you are concerned about?

 Brent Fulgham - Apple Inc.



 On Apr 1, 2015, at 2:26 PM, Maciej Stachowiak m...@apple.com wrote:
 
 
 Is it possible to make EWS start processing changes more promptly?
 
 On Apr 1, 2015, at 12:42 PM, Brent Fulgham bfulg...@apple.com wrote:
 
 Hi Everyone,
 
 We lost Windows EWS coverage for the past 36 hours due to a very 
 benign-appearing change to some webkitpy code. I haven’t yet figured out why 
 this particular set of changes caused the Windows bots to start failing, but 
 it has to do with various differences between the Cygwin Python 2.7.8 build 
 and the versions used on our other EWS bots.
 
 This does not seem like something developers SHOULD have to worry about, but 
 it’s an unfortunately reality that they really do need to.
 
 To make matters worse, the patch that introduced the problem passed EWS. 
 This is because the EWS bots only really begin using changes to webkitpy 
 when they restart processing (about once every 10-13 build iterations).
 
 To help combat this problem, I’d like to request that when making changes to 
 webkitpy, please keep an eye on the various EWS bots to make sure they 
 continue processing. If they do start failing, please roll the patch back 
 out and we can work together to resolve the issue.
 
 I apologize for how manual and inconvenient this needs to be (at least for 
 now), but keeping the EWS up and running is critical to the smooth function 
 of this project.
 
 If you have any questions, please don’t hesitate to e-mail me or look for me 
 on IRC.
 
 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] Please be careful with webkitpy changes!

2015-04-01 Thread Brent Fulgham
Hi Everyone,

We lost Windows EWS coverage for the past 36 hours due to a very 
benign-appearing change to some webkitpy code. I haven’t yet figured out why 
this particular set of changes caused the Windows bots to start failing, but it 
has to do with various differences between the Cygwin Python 2.7.8 build and 
the versions used on our other EWS bots.

This does not seem like something developers SHOULD have to worry about, but 
it’s an unfortunately reality that they really do need to.

To make matters worse, the patch that introduced the problem passed EWS. This 
is because the EWS bots only really begin using changes to webkitpy when they 
restart processing (about once every 10-13 build iterations).

To help combat this problem, I’d like to request that when making changes to 
webkitpy, please keep an eye on the various EWS bots to make sure they continue 
processing. If they do start failing, please roll the patch back out and we can 
work together to resolve the issue.

I apologize for how manual and inconvenient this needs to be (at least for 
now), but keeping the EWS up and running is critical to the smooth function of 
this project.

If you have any questions, please don’t hesitate to e-mail me or look for me on 
IRC.

Thanks!

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Modern image formats for WebKit

2015-03-20 Thread Brent Fulgham

 On Mar 20, 2015, at 2:39 PM, Darin Adler da...@apple.com wrote:
 
 Dave Hyatt originally created this when we first were planning the Apple 
 Windows port of WebKit, but in the end we chose to not use them for the 
 Windows port. They aren’t used in the Windows port nor in the Mac or iOS 
 ports; for all of those we use a separate image decoding library.
 
 So this is a really a question for people working on other active ports like 
 the EFL and GTK ones. Are there other libraries that you could use for image 
 decoding, or do you still want to keep and maintain a WebKit copy of these 
 image decoders?

The WinCairo and GTK ports definitely use these image decoders. I think the EFL 
port does as well, but I’m not sure.

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WorkQueue for Windows?

2015-03-07 Thread Brent Fulgham
Hi Antti,

Take a look at https://bugs.webkit.org/show_bug.cgi?id=142432. I haven't 
landed this yet, because I was hoping to get some kind of test for this. 
However, it seems to introduce no problems, so we could go ahead and land it.

Question: why do we have a separate WorkQueue implementation in DumpRenderTree 
*and* WebKitTestRunner? Seems like we could do some consolidation...

-Brent


 On Mar 6, 2015, at 10:55 AM, Anders Carlsson ander...@apple.com wrote:
 
 I think we used to have a WorkQueue implementation for Windows WK2 - anyone 
 should be able to dig it up.
 
 (Alternatively, we can just make an implementation using std::thread).
 
 - Anders
 
 On Mar 6, 2015, at 10:46 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 Hi,
 
 I'd like to start using WTF::WorkQueue abstraction in WebCore code. However 
 we are currently missing a Windows implementation (WorkQueue used to be part 
 of WK2). Anyone interested in making one? I assume it wouldn't be a 
 difficult task for someone who knows the platform.
 
 
   antti
 ___
 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] Remove CSS_IMAGE_ORIENTATION Feature Guard

2015-02-27 Thread Brent Fulgham
Hi Gyuyoung,

Since you completed work on Bug 92330, I think we now do wish to keep the 
ENABLE_CSS_IMAGE_ORIENTATION Flag.

Can you please confirm?

Thanks,

-Brent

 On Jul 2, 2013, at 6:00 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:
 
 Hi Brent,
 
 Sorry for no activity on this. This work was pushed back on the my priority 
 list. Thus, I agree to remove this feature if nobody(including me) submits 
 meaningful patch until July 17th.
 
 Gyuyoung. 
 
 
 On Wed, Jul 3, 2013 at 3:05 AM, Brent Fulgham bfulg...@apple.com 
 mailto:bfulg...@apple.com wrote:
 Hi Everyone,
 
 I haven't seen any action on https://bugs.webkit.org/show_bug.cgi?id=116555 
 https://bugs.webkit.org/show_bug.cgi?id=116555 (or 
 https://bugs.webkit.org/show_bug.cgi?id=92330 
 https://bugs.webkit.org/show_bug.cgi?id=92330) in the past month.
 
 I'd like to remove this logic unless there is some activity here.  We can 
 always add it back in from SVN history if someone does want to work on it.
 
 I'll submit a patch to remove this code on July 17th unless something changes.
 
 Thanks,
 
 -Brent
 
 
 
 On Jun 4, 2013, at 10:15 PM, Gyuyoung Kim wrote:
 
 Hi,
 
 I'm interested in this feature. So, I took Bug 92330 over. Though I rebased 
 the feature according to review comments, this feature doesn't work yet. So, 
 I have investigated why it doesn't work. However, unfortunately, I need to 
 have time a little further. If there is no big reason this patch should be 
 removed, I'd like to support this feature.
 
 Gyuyoung.
 On Jun 5, 2013 9:45 AM, Mike Lawther mikelawt...@google.com 
 mailto:mikelawt...@google.com wrote:
 Fwiw, the original author is no longer working on Blink, and the code has 
 been removed from there.
 
 mike
 
 On Jun 5, 2013 1:24 AM, Brent Fulgham bfulg...@apple.com  wrote:
 We have code in WebKit that is protected by the 
 ENABLE(CSS_IMAGE_ORIENTATION) guard, but no active WebKit ports seem to 
 enable this feature.
 
 Is anyone currently working on (or planning to work on) this feature?
 
 Since this CSS feature is currently in an early draft form, and is likely to 
 change, we may not want to retain this dead code as it will most likely 
 become obsolete very quickly.
 
 If no one wants to claim ownership of this feature in the next few days, I 
 will submit a patch to remove the dead code.
 
 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 mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 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] Windows Bots Are Green!

2015-02-20 Thread Brent Fulgham
Hi Everyone,

Over the past few weeks I’ve spent a considerable amount of time reviewing and 
correcting a number of problems with the Windows testing infrastructure.

We were skipping thousands of tests, including Accessibility, http tests, and 
large sections of forms, css, and svg tests. Some tests were skipped because 
features were supposedly incomplete, but in the years since the skip entry was 
added to the file, the work had been completed and feature worked perfectly 
well. Some tests were skipped simply because feature flags had never been 
enabled on Windows.

Happily, all of this is in the past. Now that this work is complete, we have 
much more test coverage of many areas of WebKit that had been previously 
ignored on this platform.

1. We are now using native Windows Apache to run our HTTP tests, and have been 
doing so for the past couple of weeks. This seems to be quite stable, and is 
allowing us to make sure SSL and other important features work properly on 
Windows.
2. Accessibility tests are back up and running.
3. Thanks to Ossy, we now run all JSC stress tests on Windows.
4. Nearly all other tests are now running, with a few notable exceptions below.
5. I have switched to running Windows tests in a single process, because I 
found that running in parallel introduced inconsistent results. (See 
https://bugs.webkit.org/show_bug.cgi?id=140914 
https://bugs.webkit.org/show_bug.cgi?id=140914).

So now that I’ve completed this task, PLEASE help keep the Windows bots green! 
:-)

If you are at all interested in the various Windows ports, and are looking for 
something to do, there are a number of bugs I’ve filed that could use some 
attention:

1. For some reason, running layout tests in parallel introduces inconsistent 
behavior and spurious failures. There must be some kind of cross-talk between 
the different shards. https://bugs.webkit.org/show_bug.cgi?id=140914 
https://bugs.webkit.org/show_bug.cgi?id=140914.
2. There are a number of debug assertions firing that cause Debug test runs to 
exit early. (see https://bugs.webkit.org/show_bug.cgi?id=140517 
https://bugs.webkit.org/show_bug.cgi?id=140517, 
3. Something weird is going on with the page cache. 
https://bugs.webkit.org/show_bug.cgi?id=140190, 
https://bugs.webkit.org/show_bug.cgi?id=140871 
https://bugs.webkit.org/show_bug.cgi?id=140871
4. Accessibility tests have a number of problems:
(a) Several Accessibility tests fail in debug mode because they assert that 
they are accessing text iterators before layout is complete. The comment with 
this assertion indicates that this can cause crashes and instability. 
https://bugs.webkit.org/show_bug.cgi?id=140867 
https://bugs.webkit.org/show_bug.cgi?id=140867
(b) Some accessibility tests are very flaky with regard to digging down into 
the DOM. Test will pass one run, fail the next. 
https://bugs.webkit.org/show_bug.cgi?id=140798 
https://bugs.webkit.org/show_bug.cgi?id=140798

Feel free to contact me any time if you want to tackle any of these problems!

Otherwise, please just help keep the Windows bots green. I don’t want to have 
to go through all of this again! :-)

Best regards,

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WinCairo 64-bit Bot Failures

2015-01-25 Thread Brent Fulgham
Hi Everyone,

It looks like the WinCairo 64-bit bot is having some trouble due to the dread 
Cygwin rebaseline requirement:

Could someone with bot access please take the bot down and rebaseline it?

These (annoying) failures are one of the reasons I’ve been trying to get the 
build to work outside of Cygwin. (Patches welcome!)

Thanks,

-Brent
3-- Build started: Project: JavaScriptCoreGenerated, Configuration: 
Release_WinCairo Win32 --
3  /usr/bin/bash
3  touch %ConfigurationBuildDir%\buildfailed
3  perl build-generated-files.pl %ConfigurationBuildDir% 
C:\cygwin\home\webkitbot\win-cairo-release\build\WebKitLibraries\win 
%PlatformArchitecture%
3  echo 
'/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/CSS.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Console.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOM.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMStorage.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Database.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Debugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/GenericTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Inspector.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/LayerTree.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Network.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Page.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Runtime.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Timeline.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Worker.json
 ' | cmp -s - EnabledInspectorDomains || echo 
'/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/CSS.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Console.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOM.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMStorage.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Database.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Debugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/GenericTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Inspector.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/LayerTree.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Network.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Page.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Runtime.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Timeline.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Worker.json
 '  EnabledInspectorDomains
30 [main] sh 3272 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x3D)
3  /bin/sh: fork: retry: Resource temporarily unavailable
30 [main] sh 2024 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x33)
3  /bin/sh: fork: retry: Resource temporarily unavailable
30 [main] sh 2072 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x3C)
3  /bin/sh: fork: retry: Resource temporarily unavailable
30 [main] sh 2084 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x33)
3  /bin/sh: fork: retry: Resource temporarily unavailable
30 [main] sh 3528 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: 

Re: [webkit-dev] Abandoned Tests

2015-01-22 Thread Brent Fulgham
Oh! Sorry. All of these tests fail.

They fail because none of the ports actually implement the features they test:

1. fast/dom/title-directionalty and 
fast/dom/title-directionality-removeChild.html:

These test that title supports a ‘dir’ property. We don’t, so they all fail.

2. fast/events/drag-image-filename.html:

These expect DRT/WKTR to support ‘dumpFilenameBeingDragged’, which might be a 
useful debugging method.

3. fast/autoresize:

These expect the system to support something called “enableAutoResizeMode(x, y, 
width, height)”. I’m not sure exactly what it’s supposed to do.

4. fast/overflow/scrollbar-restored-and-then-locked.html

These expect DRT/WKTR to support “setScrollbarPolicy”, which seems to allow you 
to force a scrollbar (horizontal or vertical) to be on or off. Perhaps this
would be a useful thing to have for testing.

Thanks,

-Brent

 On Jan 22, 2015, at 6:41 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 That's what I mean. What happens when we actually run them?
 
 On Jan 21, 2015, at 9:29 PM, Brent Fulgham bfulg...@apple.com wrote:
 
 Hi Myles,
 
 These tests don’t fail — they are all skipped on mac, win, gtk, and efl.
 
 -Brent
 
 On Jan 21, 2015, at 9:24 PM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 On which platforms do they fail?
 
 —Myles
 On Jan 21, 2015, at 8:48 PM, Brent Fulgham bfulg...@apple.com wrote:
 
 I’ve been reviewing the various Windows layout tests, and have run across 
 a few tests that seem to be leftovers from the Chromium project. I think 
 all ports currently skip these tests:
 
 1. fast/dom/title-directionality-removeChild.html
 2. fast/dom/title-directionality.html
 3. fast/events/drag-image-filename.html
 4. fast/autoresize
 5. fast/overflow/scrollbar-restored-and-then-locked.html
 
 If no one is using these tests, or plans to, I would like to remove them 
 and the disconnected bits of code in DRT/WKTR that were originally meant 
 to drive this code.
 
 If I don’t hear anything by this time next week, I’ll remove the code.
 
 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] Abandoned Tests

2015-01-21 Thread Brent Fulgham
I’ve been reviewing the various Windows layout tests, and have run across a few 
tests that seem to be leftovers from the Chromium project. I think all ports 
currently skip these tests:

1. fast/dom/title-directionality-removeChild.html
2. fast/dom/title-directionality.html
3. fast/events/drag-image-filename.html
4. fast/autoresize
5. fast/overflow/scrollbar-restored-and-then-locked.html

If no one is using these tests, or plans to, I would like to remove them and 
the disconnected bits of code in DRT/WKTR that were originally meant to drive 
this code.

If I don’t hear anything by this time next week, I’ll remove the code.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Abandoned Tests

2015-01-21 Thread Brent Fulgham
Hi Myles,

These tests don’t fail — they are all skipped on mac, win, gtk, and efl.

-Brent

 On Jan 21, 2015, at 9:24 PM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 On which platforms do they fail?
 
 —Myles
 On Jan 21, 2015, at 8:48 PM, Brent Fulgham bfulg...@apple.com wrote:
 
 I’ve been reviewing the various Windows layout tests, and have run across a 
 few tests that seem to be leftovers from the Chromium project. I think all 
 ports currently skip these tests:
 
 1. fast/dom/title-directionality-removeChild.html
 2. fast/dom/title-directionality.html
 3. fast/events/drag-image-filename.html
 4. fast/autoresize
 5. fast/overflow/scrollbar-restored-and-then-locked.html
 
 If no one is using these tests, or plans to, I would like to remove them and 
 the disconnected bits of code in DRT/WKTR that were originally meant to 
 drive this code.
 
 If I don’t hear anything by this time next week, I’ll remove the code.
 
 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


Re: [webkit-dev] Disk cache

2014-11-03 Thread Brent Fulgham
I wonder if we could easily modify the Windows port to make use of a Network 
process.

-Brent

 On Nov 3, 2014, at 8:07 AM, Anders Carlsson ander...@apple.com 
 mailto:ander...@apple.com wrote:
 
 
 On Nov 3, 2014, at 12:22 AM, Benjamin Poulain benja...@webkit.org 
 mailto:benja...@webkit.org wrote:
 
 I believe it would be better to enable the network process for all process 
 models. Maintaining multiple configurations for marginal gains is not 
 sustainable, especially in the network stack.
 
 I agree 100%. Not to mention that we also want to get rid of the “single web 
 process” code path, and just make it a special case of having multiple web 
 processes with a maximum process cap of 1.
 
 - Anders
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto: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] Fwd: Planning on Requiring Python 2.7 Soon

2014-09-15 Thread Brent Fulgham
Hi Everyone,

This is just a reminder that I plan on making source updates on Wednesday that 
will require Python 2.7 for our test system. So far, it sounds like this will 
not be a problem for anyone, but please let me know if this will be a 
significant issue for you.

Thanks,

-Brent

 Begin forwarded message:
 
 From: Brent Fulgham bfulg...@apple.com
 Date: September 10, 2014 at 4:31:05 PM PDT
 To: webkit-dev webkit-dev@lists.webkit.org
 Subject: [webkit-dev] Planning on Requiring Python 2.7 Soon
 
 Hi Everyone,
 
 Now that I’ve worked through the minor issues that prevented us from using 
 Python 2.7 on our Windows bots, I’d like to move the goalposts and require 
 Python 2.7 (or newer) for our build and test machines.
 
 Will this cause anyone any problems if this becomes the new law of the land?
 
 I plan on making this change on September 17th if I do not hear from anyone 
 on this topic.
 
 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] Planning on Requiring Python 2.7 Soon

2014-09-10 Thread Brent Fulgham
Hi Everyone,

Now that I’ve worked through the minor issues that prevented us from using 
Python 2.7 on our Windows bots, I’d like to move the goalposts and require 
Python 2.7 (or newer) for our build and test machines.

Will this cause anyone any problems if this becomes the new law of the land?

I plan on making this change on September 17th if I do not hear from anyone on 
this topic.

Thanks!

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Windows (Temporary) Build Turmoil

2014-07-09 Thread Brent Fulgham
If you don’t care about building WebKit on Windows, you can stop reading now!

Still here?  Okay:

I’m attempting to make the Windows build rely less on the Cygwin tool chain. 
There are a number of reasons for this, but one of the major benefits I hope to 
derive is to reduce the amount of effort required to successfully build WebKit 
on Windows.

In service of that goal, I am actually making things slightly more complicated: 
you now need to install a Windows build of Perl and Python, You can use 
ActiveState’s builds (http://downloads.activestate.com), or the ‘official’ 
Windows ports of these products.

If you encounter any problems with this “dual Perl/dual Python” situation, 
please let me know and I’ll work to resolve whatever difficulty you encounter. 
However, based on my testing on our internal build machines I do not anticipate 
you will have any trouble.

Thanks,

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] help: HTML5 video Overlay with accelerated composition

2014-05-29 Thread Brent Fulgham
Can you provide specifics about your test case?

1. Are you using WebKit QT, or something else?
2. Can you provide an example showing what you are trying to do?

Thanks,

-Brent

 On May 29, 2014, at 4:11 AM, T andolsi thouraya.ando...@gmail.com wrote:
 
 Hi,
 
 
 Triying to use overlay for Video enabling the accelerated composition,
 I see that the graphic is always on top of the video, and video is not
 visible.
 
 The backroung RenderLayer is always on top if the Video Render Layer.
 
 Is it possible to use Overlay for HTML5 video support with accelerated
 composition?
 
 
 Regards,
 Thouraya.
 ___
 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] Another Update: Cygwin Recommendations for Windows Builders

2014-04-23 Thread Brent Fulgham
A couple of weeks ago I reported a problem I noticed with Python 2.7 in our 
Cygwin-based builds:

 2. Python version 2.6.8:  If not, you get errors indicating “Invalid Python 
 installation: unable to open 
 ‘/cygdrive/c/Cygwin/include/python2.7/pyconfig.h”. This seems to be a 
 regression since 2.6.8. Again, Cygwin tries to upgrade you to 2.7.3 every 
 time you run the Cygwin setup utility. You must manually specify that you 
 want 2.6.8.


I tracked down the cause of this issue (see 
https://bugs.webkit.org/show_bug.cgi?id=132023 if you are curious), and have 
updated our builders to use Python 2.7.

If you update to ToT WebKit, you should be able to safely build and run with 
Python 2.7.

I have also removed the warning in update-webkit that would complain about 
Python 2.7 when you attempted to get updated sources.

Please let me know if you encounter any problems with this new environment.

Thanks,

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Problems building JavaScriptCore/WebKit for Windows desktop

2014-04-09 Thread Brent Fulgham
Hi Eric,

I’m sorry you encountered problems building WebKit. I’ve interleaved some 
responses below.

On Apr 1, 2014, at 4:34 AM, Eric Wing ewmail...@gmail.com wrote:

 I am trying to build JavaScriptCore for Windows desktop. (Ultimately,
 I just want a x86_64 .lib and .dll I can link against for Win 7 and 8.
 I would be happy not building it and just downloading the pre-build
 binaries somewhere if that's an option.)

You might want to take a look at dim3 http://en.wikipedia.org/wiki/Dim3. 
Brian Barnes has been generating JSC builds from time-to-time for use in his 
game engine.

 - The cygwin-downloader instructions about installing from the Local
 Directory doesn't seem to work. When it is time to hit 'Next' in the
 select the packages screen, it seems that the packages are not
 detected. This results in nothing getting installed. My attempts to
 force it to detect and install have failed.

As far as I know, this works. Please file a bug at http://bugs.webkit.org 
with log output if you are seeing problems.

   - The python version it picks by default is 2.7.x and Webkit
 complains it needs 2.6.x so I have to force a downgrade.

Yes. This is extremely annoying, but Cygwin has not released a 32-bit Python 
that works.

   - The curl or ssl package has some kind of bug and either requires a
 downgrade of one of the packages or a change to the
 update-webkit-dependency script to use tlsv1 instead of sslv3

This is a known issue with cURL 7.34.0, which I documented separately. This has 
been fixed by the cURL project, but I have not seen a Cygwin update with the 
fixes.

   - There is a missing instruction that C:\cygwin\bin must be added to
 the Windows %PATH%, otherwise a bunch of /usr/bin/which bash
 commands fail (because it can't find bash)

I’m surprised by this. The CMD files that emit this error message should be 
setup to ignore it. If it cannot find bash, it updates the PATH with the Cygwin 
path. So, I suspect that those messages are simply warnings to you, not actual 
errors that block the build. If they are terminating your build, please file a 
bug and attach logging output.

   - I get a warning about having svn 1.8.8 when 1.7.10 is the supported 
 one

Yes. I discussed this issue separately.

 - The php instructions to install php don't work. I think a link is broken.

Can you file a bug with the error you are seeing?

 - Running update-webkit causes me problems with Git (it just hangs) so
 I went to the SVN source ball.

I think I ran into this error myself several months ago when I accidentally put 
a git checkout somewhere inside my svn repository. If you continue to see a 
problem with this, please file a bug.

 - update-webkit reports after the SVN 1.8.8 warning with 2 instances
 of Error (2): The system cannot find the file specified. I don't
 know what it's complaining about. It goes on to tell me I don't have
 the Mozilla Math fonts. (I think those links may be stale.) But
 finally it says Installed tools are correct for the Webkit build”

The ‘cannot find the file specified’ are checks for installed MathML fonts. You 
need these for testing (and to get good MathML rendering in WinLauncher), but 
they are not needed to build. You can ignore these messages.

 Using the latest version (Monday) with Visual Studio 2013, I think
 there are some new bugs in the code base. The build now expects Core
 Foundation to be available on Windows to build WTF. This was not the
 case before and I think this is a new bug. This propagates down to
 SchedulePair.h which doesn't seem to have any non-Core Foundation
 path. (I expect this will be a problem speaking from my Android work.)

Both the Apple Windows and WinCairo ports use (a form of) CoreFoundation. 
WinCairo uses the ‘OpenCFLite” version of CoreFoundation. You need this support 
library to build WebKit and JSC, as documented on our website.

 One of the prior versions was failing on ruby related stuff or could
 not find files. I'm not fuzzy on the details because I've tried way
 too many things.

I’m sorry you encountered problems, but its very difficult to make suggestions 
without some details. Could you please file bugs about what you’ve encountered?

Good luck!

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Update: Cygwin Recommendations for Windows Builders

2014-04-04 Thread Brent Fulgham
Hi folks,

Yesterday I documented a few problems I was having with Cygwin, and asked if 
anyone else was encountering any issues. Since then, I’ve figured out what was 
going on, and I wanted to post a follow-up to document my findings. I’ll also 
be updating our Wiki page on the topic 
(http://trac.webkit.org/wiki/BuildingOnWindows).

1. Curl version 7.34.0 has a known bug that prevents it from authenticating 
over SSL. This means that ‘update-webkit’ will fail when attempting to sync 
with our servers at apple.com.  Please be sure to use cURL 7.33.0 (and make 
sure libcurl is the matching version).  See 
http://curl.haxx.se/mail/tracker-2014-01/0003.html for details.
Note: This has already been fixed by the cURL team, and we just need to 
wait for the Cygwin folks to update their builds.

2. Subversion 1.8 refuses to handshake with our servers at apple.com. I’m 
working with the right folks internally to fix this, at which point we can 
allow svn 1.8 clients. For now, we need to stick to Svn 1.7.

3. My initial concerns about Make 4.0 were unfounded. After trying the version 
I did not find there to be any issues.

The only significant issue I currently have is with Python 2.7.3. I’ll report 
back once I understand how to resolve this problem.

I have confirmed that if you stick to the above versions of software, you can 
successfully configure and run a Windows build environment. If any of you have 
encountered other problems, please let me know.

Thanks,

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Increasing Finickiness of Cygwin Installations

2014-04-03 Thread Brent Fulgham
Hi everyone,

I’ve been reviewing some of the setup and reliability problems with our Windows 
builders, and have discovered that there are a number of challenges to getting 
a working Cygwin environment for building WebKit:

You must use very specific versions of some Cygwin tools:

1. curl version 7.33.0:  If not, you get certificate errors when attempting to 
retrieve WebKitAuxilliaryLibraries.zip from apple.com.  Cygwin attempts to 
install 7.34.0, which will cause failures during “update-webkit”.  You must 
manually select the 7.33 build.
2. Python version 2.6.8:  If not, you get errors indicating “Invalid Python 
installation: unable to open ‘/cygdrive/c/Cygwin/include/python2.7/pyconfig.h”. 
This seems to be a regression since 2.6.8. Again, Cygwin tries to upgrade you 
to 2.7.3 every time you run the Cygwin setup utility. You must manually specify 
that you want 2.6.8.
3. Subversion 1.7: If not, you get errors updating sources due to incompatible 
authentication with svn.webkit.org.

I also noticed that Cygwin tried to update to GNU Make 4.0; I left it at 
3.82.90 since our Mac builders use 3.81 and I wanted to avoid yet another 
possible difference.

I experimented with using the 64-bit Cygwin installation, but found that their 
build of bison failed to process our CSSGrammar.y file (exiting with error 141 
without doing anything). The 32-bit build of bison does not share this problem.

While there is a significant benefit to sharing the various build scripts and 
setup routines with our UNIX-flavored ports, I’m growing increasingly concerned 
that relying on Cygwin to provide similar benefits on Windows may become more 
difficult.

I would love to move our Python requirement to 2.7 to be more consistent with 
our Mac builders, but have not found a suitable workaround. Are any other 
WebKit people aware of this problem or solutions for Cygwin?

Thanks,

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] DerivedSources.make: Another try?

2014-03-19 Thread Brent Fulgham
Hi All,

I’m arriving to this conversation a bit late, but had a few comments:

On Mar 16, 2014, at 11:06 AM, Patrick Gansterer par...@paroga.com wrote:

 DerivedSources.make depends heavily on UNIX command line tools (cat, sed, 
 sort, ...) which are not part of a clean Windows installation and don't 
 provide Windows like installers.
 The point is if we want to make cygwin (with all of its pro and cons) a 
 requirement. At the moment the minimal requirements for building on Windows 
 are GNU Win32 GPerf, Win flex-bision, Perl, Python and Ruby (which provide 
 nice native Windows installers).
 Bugs like 48166 suggest that also not all Apple folks are happy with cygwin.

To paraphrase Churchill, Cygwin is the worst form of UNIX abstraction, except 
for all the others. We find that it is a whole lot easier to get a Windows 
build system up and running using Cygwin than trying to piece together a set of 
disparate GNU tools built and hosted by different parties.

I would not want to move from a system where I can direct people to download 
and run our Cygwin installer, to one where I have to point out a dozen 
different GNU Win32 packages to manually install and setup.

I would be much more interested in a system where we did not need these 
external tools. For example, driving the entire build system through just CMake 
with Perl or Python (or Ruby) would be interesting.

Unfortunately, we still have strong need for a number of UNIX-y tools, such as 
Flex, Bison, and GPerf. This is a common problem for all projects I am aware of 
that involve language implementations.

So I’m not sure that jettisoning Cygwin is a likely outcome at present.

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Error while building webkit on windows

2014-03-05 Thread Brent Fulgham
Hi,

The problem is with the processing of the CSSGrammar.y file.

On Mar 5, 2014, at 1:52 AM, Baskar CV baskar...@hotmail.com wrote:

 10  ./CSSGrammar.y:62.1: error: syntax error, unexpected end of file
 10  open3: exec of /usr/bin/gcc -E -P -x c++ -DENABLE_3D_RENDERING 
 -DENABLE_CHANNEL_MESSAGING -DENABLE_CSS_BOX_DECORATION_BREAK 
 -DENABLE_CSS_FILTERS -DENABLE_CSS_IMAGE_SET -DENABLE_CSS_REGIONS 
 -DENABLE_CSS_SHAPES -DENABLE_CSS_SHAPE_INSIDE -DENABLE_CSS_STICKY_POSITION 
 -DENABLE_CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED 
 -DENABLE_DETAILS_ELEMENT -DENABLE_FILTERS -DENABLE_FULLSCREEN_API 
 -DENABLE_GEOLOCATION -DENABLE_HIGH_DPI_CANVAS -DENABLE_ICONDATABASE 
 -DENABLE_LEGACY_CSS_VENDOR_PREFIXES -DENABLE_MATHML 
 -DENABLE_MEDIA_CONTROLS_SCRIPT -DENABLE_MEDIA_STATISTICS 
 -DENABLE_METER_ELEMENT -DENABLE_PAGE_VISIBILITY_API -DENABLE_PROMISES 
 -DENABLE_REQUEST_ANIMATION_FRAME -DENABLE_SHARED_WORKERS 
 -DENABLE_SQL_DATABASE -DENABLE_SUBPIXEL_LAYOUT -DENABLE_SVG 
 -DENABLE_SVG_FONTS -DENABLE_TEMPLATE_ELEMENT -DENABLE_VIDEO 
 -DENABLE_VIDEO_TRACK -DENABLE_VIEW_MODE_CSS_MEDIA -DENABLE_WEB_SOCKETS 
 -DENABLE_XHR_TIMEOUT -DENABLE_XSLT /webkit/Source/WebCore/css/CSSGrammar.y.in 
 failed at /webkit/Source/WebCore/bindings/scripts/preprocessor.pm line 81
 10  ...propagated at /webkit/Source/WebCore/css/makegrammar.pl line 84.
 10  /webkit/Source/WebCore/DerivedSources.make:842: recipe for target 
 'CSSGrammar.cpp' failed
 10  make: *** [CSSGrammar.cpp] Error 2
 10  make: *** Waiting for unfinished jobs
 10  CSSPropertyNames.gperf: No keywords in input file!
 10  calling gperf failed: 256 at /webkit/Source/WebCore/css/makeprop.pl line 
 306.
 10  /webkit/Source/WebCore/DerivedSources.make:785: recipe for target 
 'CSSPropertyNames.h' failed
 10  make: *** [CSSPropertyNames.h] Error 1

Things to check:

1. Is CSSGrammar.y complete? Make sure the checkout didn’t get messed up in 
some fashion.
2. Do you have gperf, flex, and bison installed?  You need flex/bison to 
process the grammar file and turn it into the stub implementation.

 10  CSSPropertyNames.gperf: No keywords in input file!

This makes me think that you do NOT have gperf installed. Did you use our 
Cygwin installer package? Or are you using your own local install?

If you are using your own install from the Cygwin website, you should use the 
Setup.exe utility and make sure that flex, bison, and gperf are installed.

Thanks,

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebGL backends

2014-02-10 Thread Brent Fulgham
Hi Dean,

The WinCairo port uses the ANGLE library (and therefore, the “OpenGL” 
machinery) to do WebGL.

I’m pretty sure the GTK+ port uses OpenGL directly, but Martin Robinson can 
probably confirm that.

I think that only really leaves EFL, which may be using OpenGLES?  I’m not sure.

-Brent


On Feb 9, 2014, at 12:59 PM, Dean Jackson d...@apple.com wrote:

 Hi floks.
 
 I’m looking into simplifying our WebGL code, particularly our 
 GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL 
 backend for its ports, but it isn’t clear to me what backend the other ports 
 are using.
 
 Could the other port developers please reply to let me know how you’re 
 accessing OpenGL?
 
 Thanks,
 
 Dean
 
 ___
 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] Ports relying on ICU with features omitted?

2014-02-10 Thread Brent Fulgham
Hi Darin,

On Feb 10, 2014, at 9:40 AM, Darin Adler da...@apple.com wrote:

 I’d like to find out which ports are relying on WebKit support for ICU 
 without certain key features. Maintaining these extra code paths creates some 
 difficulties, and it would be helpful to remove them once no one is relying 
 them. For example, we have support for:
 
 […]

 I know this is not needed for PLATFORM(MAC), PLATFORM(IOS), and PLATFORM(WIN).
 
 So I guess I am looking for an answer for PLATFORM(GTK) and PLATFORM(EFL) and 
 any others I might have forgotten to ask about.

I believe that the dim3 game engine (http://www.klinksoftware.net) uses 
JavaScriptCore with a custom ICU. I don’t remember what ICU features they 
exclude, but they might be impacted by this change.

I suspect they could follow WinCE’s approach if this was a significant problem 
for them.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Make accelerated compositing mandatory

2014-01-28 Thread Brent Fulgham
The same is true for the WinCairo port, though I know Alex Christensen has been 
working towards correcting that.

-Brent

On Jan 28, 2014, at 7:49 AM, Martin Robinson mrobin...@webkit.org wrote:

 On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur abu...@adobe.com wrote:
 Do you happen to know if we still have ports that build WebKit without
 accelerated compositing? If not, I'd like to write a patch that removes the
 flag and makes AC mandatory.
 
 From IRC, I've heard that the Haiku port (not upstreamed) disables the AC
 flag, but they agree they should switch it on in the future.
 
 Yes, GTK+ on Windows does not use accelerated compositing. I'm also
 fairly certain the WinCE port does not enable accelerated compositing.
 
 --Martin
 ___
 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] Make accelerated compositing mandatory

2014-01-28 Thread Brent Fulgham
The same is true for the WinCairo port, though I know Alex Christensen has been 
working towards correcting that.

-Brent

On Jan 28, 2014, at 7:49 AM, Martin Robinson mrobin...@webkit.org wrote:

 On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur abu...@adobe.com wrote:
 Do you happen to know if we still have ports that build WebKit without
 accelerated compositing? If not, I'd like to write a patch that removes the
 flag and makes AC mandatory.
 
 From IRC, I've heard that the Haiku port (not upstreamed) disables the AC
 flag, but they agree they should switch it on in the future.
 
 Yes, GTK+ on Windows does not use accelerated compositing. I'm also
 fairly certain the WinCE port does not enable accelerated compositing.
 
 --Martin
 ___
 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] Apple Mac EWS 10.9 upgrade?

2014-01-07 Thread Brent Fulgham
Hi,

On Jan 6, 2014, at 1:53 PM, Alexey Proskuryakov a...@webkit.org wrote:
 06 янв. 2014 г., в 12:51, Lucas Forschler lforsch...@apple.com написал(а):
 
 The Apple Mac EWS bots are currently running 10.8.5.
 I would like to see if there is any opposition (or support) for upgrading 
 them to 10.9 / Mavericks.
 
 Mavericks bots are substantially less reliable at this point, so this will 
 degrade EWS performance. E.g. Mavericks WK2 Release was completely 
 dysfunctional for two days recently for unclear reasons.

This is troubling. Why are they less reliable?

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-04 Thread Brent Fulgham
Hi Alex,

 On Jan 4, 2014, at 12:01 PM, Alex Christensen alex.christen...@flexsim.com 
 wrote:
 
 [...]  but I like to err on the more explicit side of coding. It is hard to 
 say does this make the code cleaner more than it removes useful 
 information? or will this cause problems for other developers? with a 
 style guideline.  

The problem is that those declarations aren't really doing what you think they 
are; we are simply engaging in 'type theater'. 

The annotations indicate what the author thought the resulting type of the RHS 
expression would be, or perhaps were at one time. But they are only showing 
what we are asking the compiler to coerce the result into. I would argue that 
the number of times we really want to coerce the result of an expression to 
something new are relatively rare, and could be handled be the new 'type' 
syntax, or explicit cast declarations.

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-03 Thread Brent Fulgham
Hi antti,

On Jan 3, 2014, at 4:12 AM, Antti Koivisto koivi...@iki.fi wrote:

 If we start making rules I'd add the following:
 
 - Use auto when the type name is already mentioned on a line:

+1

 - Use auto when the type is irrelevant. This covers things like iterators 
 and adapter classes:

+1

 - Use auto when type is obvious for people with basic familiarity with a 
 subsystem:
 
 auto style = renderer.style();

I think this is the crux of the argument against using ‘auto’.  Few of us are 
experts in all parts of the system, so it’s not clear why type is returned here.

My personal preference is to use auto, and rely on the IDE to show me what the 
actual type is when I view the code.

However, this does not work well when using our code review tools, since there 
is no ‘type overlay’ available to show us what specific type is being used in 
this case. So I can understand the argument against using ‘auto’ in this 
circumstance.

-Brent



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-02 Thread Brent Fulgham

On Jan 2, 2014, at 1:54 PM, Filip Pizlo fpi...@apple.com wrote:

 I think the goal should be that if you do introduce a temporary variable for 
 some reason, then being explicit about its type is better.  Consider that in 
 your second example, there might be 200 lines of code between the call to 
 optimalSize() and the call to setSize().  I that case, we're essentially 
 choosing between having the code reader see this:
 
 auto newSize = optimalSize();
 
 or this:
 
 CGSize newSize = optimalSize();

I’m not sure that having the temporary created 200 lines before it was used 
would be improved with either of these cases! ;-)

Allowing the compiler to infer type seems like a big win, for all the same 
reasons it is for SML and other Hindley-Milner languages. Why must I manually 
enter stuff that the compiler should be able to determine for me?

Our development environments should be capable of showing us the resulting 
‘auto’ type, so I feel like requiring explicit type declarations are a step 
backwards.

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-02 Thread Brent Fulgham
Hi Adam,

On Jan 2, 2014, at 2:08 PM, Adam Roben aro...@webkit.org wrote:

 I found 
 http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
 very persuasive in my thinking about when to use auto.

I think this does a much better job of explaining the benefits of ‘auto’ than I 
was able to come up with.

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-02 Thread Brent Fulgham
Hi Filip,

Coming back to your earlier example:

 auto newSize = optimalSize();
 vs:
 CGSize newSize = optimalSize();

If I understand your argument, you feel that the explicit CGSize declaration 
helps the reader because it makes the return value of optimalSize() explicit.

However, that declaration is only stating the type that the author *thinks* 
optimalSize() returns.  There is nothing to guarantee that optimalSize() 
returns a CGSize; only that it returns something that the compiler can turn 
into a CGSize through some set of casts.

The code stating CGSize could have been correct at one point, but the return 
type of optimalSize might have been changed to some similar type without anyone 
noticing.

Using ‘auto’ doesn’t seem to make this situation any worse.

In fact, although Sutter’s suggestion of:

auto newSize = CGSize { optimalSize(); }

looks gross to my eye, it might be a useful approach because it would force the 
compiler to complain if we were returning something that was not explicitely a 
CGSize type.

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Windows a Release Build Broken

2013-12-27 Thread Brent Fulgham

 On Dec 27, 2013, at 9:26 AM, Joseph Pecoraro pecor...@apple.com wrote:
 
 Windows bots on build.webkit.org are now green.

Thanks!

 Thanks for pointing me to the fixes in bugzilla comments.

Sorry to disturb your holiday, but thanks for fixing it. :)

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Windows a Release Build Broken

2013-12-25 Thread Brent Fulgham
The changes in Bug 126091 breaks the Windows Release build.

https://bugs.webkit.org/show_bug.cgi?id=126091

-Brent

Sent from my iPad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Migration to Visual Studio 2013 Is Happening Now

2013-12-20 Thread Brent Fulgham
Hi Ossy,

I’m not sure what’s going on. Those bots do have VS2013 on them. It looks like 
a process may be locking the build log, preventing anything from happening.

I’ll look into it ASAP.

Thanks,

-Brent

On Dec 20, 2013, at 2:45 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

 Hi,
 
 It seems the Windows EWS bots should be updated too:
 http://webkit-queues.appspot.com/queue-status/win-ews
 
 Ossy
 
 Brent Fulgham írta:
 I am landing changes to switch our builds over to Visual Studio 2013.  You 
 can assume I know about any build failures on the Windows port. However, 
 please let me know if you encounter any problems on non-Windows platforms 
 ASAP.
 Thanks,
 -Brent
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Migration to Visual Studio 2013 Is Happening Now

2013-12-13 Thread Brent Fulgham
I am landing changes to switch our builds over to Visual Studio 2013.  You can 
assume I know about any build failures on the Windows port. However, please let 
me know if you encounter any problems on non-Windows platforms ASAP.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Migration to Visual Studio 2013 Starts in About 12 Hours

2013-12-12 Thread Brent Fulgham
Hi floks!

Last week I promised that we would be moving to Visual Studio 2013 builds this 
Friday (tomorrow). I plan to start this work tomorrow morning, and hope to have 
everything completed within a couple of hours.

This should not impact non-Windows ports, so I anticipate minimal problems for 
most of you.

I am also on bot-watch duty this week, so I am in a great position to see if my 
changes create any problems (and of course, fix them). However, I do encourage 
you to e-mail me if you encounter build problems once I land the changes to our 
project files.

Hopefully this will be a smooth transition, and we can all start enjoying the 
new compiler features as soon as possible!

Best regards,

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebKit, C++11, and Visual Studio 2013

2013-12-06 Thread Brent Fulgham
Hi Everyone,

We are working hard to move WebKit toward stronger adoption of C++11 features, 
such as variadic templates, ranged for-loops, and initializer lists. 
Unfortunately, this effort has been hampered by the small subset of C++11 
features available in Visual Studio 2010.

You can get a feel for the level of C++11 support in the last few versions of 
Visual Studio here:
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

With Visual Studio 2013, we finally have access to a compiler that supports the 
major C++11 features we need. Consequently, we intend to switch to VS2013 and 
begin taking advantage of these new language constructs.

Over the next week we will be landed a series of source changes that allow 
WebKit to be built with VS2013, but will continue to build with VS2010 on our 
build machines.  Next Friday, we plan to land project file changes to switch to 
the new compiler, and will simultaneously convert our build system to use 
VS2013 as well.

Once the revised project files are landed, we will no longer be officially 
supporting Visual Studio 2010 as a compiler target.

For those playing at home, you can track progress by following 
https://bugs.webkit.org/show_bug.cgi?id=125192.

WebKit continues to build with the free “Visual Studio 2013 Express” software, 
so I do not anticipate that this change will block any external developers from 
running Windows builds.

Thanks,

-Brent



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit, C++11, and Visual Studio 2013

2013-12-06 Thread Brent Fulgham
Hi Alex,

There are a few items missing from VS2012 (see 
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx) that we are 
already using in the Mac-specific source code:

1. Variadic Templates
2. Initializer Lists
3. Explicit conversion operators
4. Deleted functions

None of those items are supported in VS2012, and we would like to expand their 
use to the rest of WebKit.  Clang and GCC already support these features, so 
VS2012 (and earlier) hold the rest of the project back.

-Brent


On Dec 6, 2013, at 4:05 PM, Alex Christensen alex.christen...@flexsim.com 
wrote:

 Is there any advantage of VS2013 instead of VS2012?  I've been using VS2012 
 for a while, and it works fine.  It also has the C++11 features we want to 
 use.  Staying one version behind the latest usually prevents updates from 
 breaking things.
 
 Alex Christensen
 
 
 On Fri, Dec 6, 2013 at 3:53 PM, Brent Fulgham bfulg...@apple.com wrote:
 Hi Everyone,
 
 We are working hard to move WebKit toward stronger adoption of C++11 
 features, such as variadic templates, ranged for-loops, and initializer 
 lists. Unfortunately, this effort has been hampered by the small subset of 
 C++11 features available in Visual Studio 2010.
 
 You can get a feel for the level of C++11 support in the last few versions of 
 Visual Studio here:
   http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
 
 With Visual Studio 2013, we finally have access to a compiler that supports 
 the major C++11 features we need. Consequently, we intend to switch to VS2013 
 and begin taking advantage of these new language constructs.
 
 Over the next week we will be landed a series of source changes that allow 
 WebKit to be built with VS2013, but will continue to build with VS2010 on our 
 build machines.  Next Friday, we plan to land project file changes to switch 
 to the new compiler, and will simultaneously convert our build system to use 
 VS2013 as well.
 
 Once the revised project files are landed, we will no longer be officially 
 supporting Visual Studio 2010 as a compiler target.
 
 For those playing at home, you can track progress by following 
 https://bugs.webkit.org/show_bug.cgi?id=125192.
 
 WebKit continues to build with the free “Visual Studio 2013 Express” 
 software, so I do not anticipate that this change will block any external 
 developers from running Windows builds.
 
 Thanks,
 
 -Brent
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
 
 -- 
  
 Alex Christensen
 
 FlexSim Software Products, Inc.
 
 1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097
 
 Voice: 801-224-6914 | Fax: 801-224-6984
 
 Email: al...@flexsim.com
 
 URL: www.flexsim.com
 
  
 
  
 This message may contain confidential information, and is intended
 
 only for the use of the individual(s) to whom it is addressed. 
 
 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] C stack direction

2013-11-22 Thread Brent Fulgham

On Nov 21, 2013, at 2:14 PM, Darin Adler da...@apple.com wrote:

 On Nov 21, 2013, at 5:33 AM, Steven Coul (scoul) sc...@cisco.com wrote:
 
 But since it's WTF functionality that isn't being used in another component 
 atm. I would tend to keep it.
 
 Actually, we wouldn’t do that. WTF is only for WebKit, not intended to be a 
 general purpose library. We don’t keep things in it that we aren’t using.

Plus, the code is always present in the source repository. It's not lost if we 
remove it from the working set we build today.

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO = how to activate HTML5 video tag ?

2013-10-15 Thread Brent Fulgham

On Oct 14, 2013, at 8:29 PM, Justin Haygood justin.hayg...@reaktix.com wrote:

 Would it be possible to use Media Foundation with a fall back? You can’t 
 depend on Media Foundation even on Windows Vista+ anyway (N editions don’t 
 have it), but it’s a COM API so you can detect that it is not available to 
 use something else.

Sure. The media code currently has fallback support (at least in the Apple 
port) to cascade from AVFoundation back to QuickTime if needed.

The only downside is needing to provide implementations for each fallback path 
you want to support.

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO = how to activate HTML5 video tag ?

2013-10-14 Thread Brent Fulgham
Alex, Brendan:

I do think that something like Media Foundation would be a useful way to go, 
since WinCairo is pretty solidly Windows-only.

-Brent


On Oct 14, 2013, at 10:00 AM, Brendan Long s...@brendanlong.com wrote:

 On 10/14/2013 10:39 AM, Mital Vora wrote:
 * are we considering any other possibilities besides gstreamer like ffmpeg 
 (http://www.ffmpeg.org/) or any other. 
 By the way, if this is just for Windows, you may want to look at Media 
 Foundation.
 
 Also, I took at look at the media players before Chromium was removed, and I 
 didn't see an FFMPEG media player. Maybe Chromium's media player has always 
 been in the Chromium tree instead of the WebKit tree.
 ___
 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] [WinCairo] : ENABLE_VIDEO = how to activate HTML5 video tag ?

2013-10-14 Thread Brent Fulgham
The only problem with Media Foundation is that it is Vista-and-newer only.  
There is no Windows XP version.

-Brent

On Oct 14, 2013, at 10:23 AM, Brent Fulgham bfulg...@apple.com wrote:

 Alex, Brendan:
 
 I do think that something like Media Foundation would be a useful way to go, 
 since WinCairo is pretty solidly Windows-only.
 
 -Brent
 
 
 On Oct 14, 2013, at 10:00 AM, Brendan Long s...@brendanlong.com wrote:
 
 On 10/14/2013 10:39 AM, Mital Vora wrote:
 * are we considering any other possibilities besides gstreamer like ffmpeg 
 (http://www.ffmpeg.org/) or any other. 
 By the way, if this is just for Windows, you may want to look at Media 
 Foundation.
 
 Also, I took at look at the media players before Chromium was removed, and I 
 didn't see an FFMPEG media player. Maybe Chromium's media player has always 
 been in the Chromium tree instead of the WebKit tree.
 ___
 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] Wink browser

2013-10-10 Thread Brent Fulgham
Fantastic work! I can't wait to see what you do with it.

-Brent

Sent from my iPad

 On Oct 10, 2013, at 6:08 PM, Alex Christensen alex.christen...@flexsim.com 
 wrote:
 
 With the removal of Chromium and Qt, there are no projects of which I am 
 aware that allow Windows users to use WebKit with content from the open 
 internet. I've started a web browser project I'm calling Wink to get the 
 public to use WebKit on Windows, and I'm collecting crash reports with stack 
 traces to allow me to locate and fix common crashes.
 
 I've created Winkbrowser.org and Winkbrowser.org/nightly.php as a start. 
 Could whoever manages nightly.webkit.org please send me some example code? 
 You might have noticed that writing aesthetically pleasing php isn't exactly 
 my strength. 
 
 I hope this will be seen as beneficial to the WebKit community. 
 
 Alex Christensen 
 ___
 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] Please install shellwords on the bots

2013-10-07 Thread Brent Fulgham
It appears that Shellwords is part of the standard Ruby install we use on the 
Cygwin-based Windows systems.

-Brent

On Oct 6, 2013, at 2:06 PM, Filip Pizlo fpi...@apple.com wrote:

 
 On Oct 6, 2013, at 2:00 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 10/6/13, 1:54 PM, Filip Pizlo wrote:
 This bug: https://bugs.webkit.org/show_bug.cgi?id=120696
 
 Is for making run-javascriptcore-tests run all of the tests in
 parallel and in a way that is aware of our multiple tiers.  It vastly
 improves JSC test coverage.
 
 Right now, the script will refuse to do anything if your machine
 doesn't have the Ruby shellwords package installed.  Eventually I'll
 change that to make it just fail.
 
 Please install shellwords on the bots so that this script can work.
 
 (And no, I don't see an easy alternative to using shellwords for this
 testing infrastructure.  It would take a lot more code if we didn't
 want to use shellwords.  So, you should install shellwords to run
 javascriptcore tests.  It's already installed by default on a lot of
 OS's.)
 
 I'll be landing this patch soon.  We need the test coverage.
 
 Could run-javascriptcore-tests just install shellwords when it is missing?
 
 Probably.
 
 
 There is a precedent of this, webkit-patch downloads every missing
 packages, making it easy to use without installing the dependencies.
 
 In the case of shellwords, the majority of WebKit developers will already 
 have it.  It’s part of the Ruby standard library as of version 2.
 
 
 Benjamin
 
 ___
 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] [WinCairo] : is ACCELERATED COMPOSITING under progress ?

2013-10-07 Thread Brent Fulgham

On Oct 7, 2013, at 11:32 AM, Urbain EGIS urbain.e...@gmail.com wrote:

 Expecting ACCELERATED_COMPOSITING along with WinCairo, I noticed come 
 conflicts raised by building WebKit over MsDev 2010. Looks like 
 ACCELERATED_COMPOSITING is sort of  wired to CoreAnimation (and 
 CoreGraphics).
 
 So is there any plan to make WinCairo sensitive to HW acceleration ? 
 Regardless of Corexxx stuff… ?

Yes. This will be based on the Texture Mapper code, which is partially working 
under WinCairo.  But work is stalled at the moment due to time constraints.

-Brent




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Use ICU in WebKit code

2013-10-05 Thread Brent Fulgham
The WinCairo port is as close to the AppleWin port as possible. It uses ICU and 
I have no intention of changing that.

The WinCE port is maintained by Patrick Gangsterer. I believe that this port 
does not want to use ICU, preferring to use the limited subset of i18n features 
provided by the operating system.

I have heard from a number of people, mainly using WebKit in resource 
constrained environments, who prefer to omit ICU due to its relatively large 
footprint. But many of their concerns about library size might be satisfied by 
rebuilding ICU with settings that omit the large encoding database. This makes 
sense if their use cases do not need these features.

-Brent

Sent from my iPad

 On Oct 4, 2013, at 11:48 PM, Dirk Schulze dschu...@adobe.com wrote:
 
 
 On Oct 5, 2013, at 7:37 AM, Darin Adler da...@apple.com wrote:
 
 Any thoughts on this? I am not sure what the status of the WinCE port is, 
 but I’d like to hear from the maintainers of that port on the port status 
 and their view on this strategy.
 
 Do you really mean WinCE or WinCairo? I thought that WinCE was discontinued a 
 long time ago and already removed. Probably I was wrong.
 
 Greetings,
 Dirk
 ___
 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] Announcement: CSS3_TEXT_DECORATION flag

2013-10-04 Thread Brent Fulgham
Yes, WinCairo uses the new inspector.

On Oct 4, 2013, at 11:45 AM, Antonio Gomes toniki...@webkit.org wrote:

 All (?wincairo I'm not sure?) ports on trunk use the new Inspector,
 and the old one is being removed:
 https://bugs.webkit.org/show_bug.cgi?id=122295
 
 On Fri, Oct 4, 2013 at 2:24 PM, Sam Weinig wei...@apple.com wrote:
 Or better yet, enable it for all ports on ToT.
 
 -Sam
 
 
 On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com wrote:
 
 Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it?
 
 I have a legitimate use for -webkit-text-decoration-color that would allow
 me to eliminate a hack in the Inspector.
 
 — Timothy Hatcher
 
 
 On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 Hello, all!
 
 Between the current and previous versions of the CSS3 Text spec, the text
 decoration section was split out into its own spec [1] [2] [3]. Because of
 this shift, I’m going to be creating a new compile-time flag:
 CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in
 [4]. For those who wish to follow progress, the feature bug is at [5]. The
 first thing I am working on is the text-decoration-skip: ink property [6]. I
 will also be migrating existing text-decorations code from behind the
 existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag.
 
 Thanks,
 Myles C. Maxfield
 
 [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/
 [2] http://www.w3.org/TR/css3-text/
 [3] http://www.w3.org/TR/css-text-decor-3/
 [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
 [5] https://bugs.webkit.org/show_bug.cgi?id=58491
 [6] https://bugs.webkit.org/show_bug.cgi?id=121806
 ___
 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] WebGL :: Win32 = build successful and rendering assumed so = but white page

2013-10-03 Thread Brent Fulgham
Hi Hugo,

I think most of us in the WebKit project are aware of the missing pieces on the 
Apple Windows port, and have plans to rectify this.

However, I don’t understand what your needs are regarding WebGL and the Apple 
Windows port. This port is not licensed for use outside of Apple’s own 
products, and only exists as a mechanism for outside developers to debug 
problems and run early-warning builds of our current sources.

If you would like to embed a Windows version of WebKit for use in your own 
software, I would suggest using the WinCairo port, which seeks to be 
feature-compatible with the Apple Windows port.  An added bonus is that WebGL 
*already exists and works* in this port.

Alex Christensen has been working to further expand the WinCairo port, and 
often hangs out on our IRC channel.

Thanks,

-Brent

On Oct 3, 2013, at 1:49 PM, Hugo Machefer hugo.mache...@gmail.com wrote:

 Thanks a lot Timothy. For some: part of my job might consist in doing this 
 work  -for Windows-  required to actually display the result. Then, assuming 
 WebKit-r156532 compiles and runs WebGL content succesfully  for Mac  
 (probably provided some settings :  'defaults write com.apple.Safari 
 WebKitWebGLEnabled -bool YES'  specified from the terminal) would that be a 
 good approach, according to you, to watch step-by-step what happens across 
 Mac OS, by using efficient debugger, and report what is missing   -for 
 Windows-   ? To fill the gap...
 
 Do you or anyone assess this analogy to mimic behaviours around OpenGLES2 
 from Mac OS X to WIN32 (involving Angle in-the-middle ;-) ?
 
 PS: again, sorry for any piece of naivety or groundless indolence in my 
 analysis: these technical areas turn out to be new to me.
 
 On Thu, Oct 3, 2013 at 6:15 PM, Tim Horton timothy_hor...@apple.com wrote:
 On 2013.10.03, at 09:06, Hugo Machefer hugo.mache...@gmail.com wrote:
 
 Dear all. Might not the best place  -here-  to describe my issue [Win32], 
 but I don't know where exactly this shall be submitted, as a novice by 
 WebKit. To recap, I managed to compile WebKit-r156532 sources by Microsoft 
 Visual Studio 2010 using CoreGraphics (ie without Cairo) in Debug mode. To 
 activate WebGL, additionally, I have set: 
 
 The AppleWin port (the one you describe) does not currently support WebGL. 
 Much of the underlying mechanism is implemented, but there’s still some work 
 required to actually display the result.
 
 #define ENABLE_WEBGL 1 
 #define WTF_USE_3D_GRAPHICS 1 
 #define WTF_USE_OPENGL 1 
 #define WTF_USE_OPENGL_ES_2 1 
 #define WTF_USE_EGL 1 
 #define WTF_USE_GRAPHICS_SURFACE 1
 
 I hope/guess this is the right approach = could anyone confirm ? Then LINK 
 turns out to be fortunate, by adding these libraries : 
 translator_common.lib; libEGL.lib; libGLESv2.lib; preprocessor.lib; 
 translator_glsl.lib; translator_hlsl.lib to WebKit sub-project.
 
 However, execution fails by http://get.webgl.org. Indeed, HTML content 
 pretends : 
 Your browser supports WebGL
 However: a blank area is displayed in place of expected movic 3D based 
 cube... 
 
 Apologize in case this concern forsooth comes to break any rule by 
 lists.webkit.org , due to Windows matters...
 
 ___
 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] PSA: WebKit2 and DrawingAreaImpl

2013-10-02 Thread Brent Fulgham
Hi Anders,

On Oct 1, 2013, at 6:19 PM, Anders Carlsson ander...@apple.com wrote:

 I just wanted to let everyone know that we (Apple) are moving away from 
 DrawingAreaImpl and always using our tiled drawing area. Longer term we’d 
 like to remove DrawingAreaImpl completely since it was designed back when we 
 didn’t run in accelerated compositing mode all the time.

I believe that this only effects WebKit2, correct? If so, this will have no 
impact on the Windows port or the WinCairo port.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WTF::fastMalloc

2013-10-01 Thread Brent Fulgham
So are you proposing to use the system allocator on Windows? Or would we keep 
using the existing FastMalloc implementation?

The current malloc logic has been the source of a number of mysterious crashes 
on Windows, so reverting to the system allocator might be a good thing for 
stability. I don’t know what the potential performance ramifications would be.

-Brent

On Oct 1, 2013, at 3:23 PM, Geoffrey Garen gga...@apple.com wrote:

 Apple's Windows port uses FastMalloc and the last measurements we took show 
 it to be a large performance gain over the default Windows malloc 
 implementation.
 
 I believe those measurements were taken 5 Windows versions ago.
 
 While this port is only used by iTunes these days, we still would not want 
 to regress its performance. Can the new allocator be made to work with 
 Windows?
 
 The set of porting tasks is the same set I outlined for GTK.
 
 The Windows port is missing many performance features, including tiled 
 scrolling, LLInt, parallel garbage collection, DFG, and FTL. Given those 
 other major missing pieces, I don’t think this piece is worth the porting 
 time.
 
 Geoff
 ___
 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] Invalid file committed on the Webkit tree for windows

2013-09-20 Thread Brent Fulgham
This appears to have been corrected in r156161.

Thanks,

-Brent

On Sep 20, 2013, at 2:20 AM, Konstantin Tokarev annu...@yandex.ru wrote:

 
 20.09.2013, 13:16, Van Den Berghe, Vincent 
 vincent.vandenber...@bvdinfo.com:
 Hello,
 
 When doing an SVN update to get the latest WebKit tree on Windows, I get the 
 following error:
 
 Failed to run the WC DB work queue associated with
 
 'C:\cygwin\home\vvdb\WebKit\LayoutTests\fast\hidpi\resources', work item
 
 193377 (file-install LayoutTests/fast/hidpi/resources/image?test.png 1 0 1 1)
 
 Can't move 'C:\cygwin\home\vvdb\WebKit\.svn\tmp\svn-9BDA1924' to
 
 'C:\cygwin\home\vvdb\WebKit\LayoutTests\fast\hidpi\resources\image?test.png':
 
 The filename, directory name, or volume label syntax is incorrect.
 
 The reason is that “image?test.png' is not a valid filename on Windows. 
 What’s worse, after this error the “svn cleanup” doesn’t work anymore 
 because SVN tries to undo something that can’t be done by definition.
 
 The only way to restore the local tree to a valid state is either (1) 
 restore it from a backup, or (2) find the entry in .svn/wc.db (which is an 
 sqlite database) and remove it manually.
 
 There should be a way for these kinds of problems to be prevented or 
 corrected as soon as possible (being able to “svn update” is kind of a 
 fundamental thing). I can’t even patch because my tree is invalid L.
 
 You can use git mirror instead of svn to be resistant to such issues when 
 they happen.
 
 -- 
 Regards,
 Konstantin
 ___
 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] Loading and unloading webkit, threading, AtomicString and crashes

2013-09-15 Thread Brent Fulgham
Hi Vincent,

Thank you for this very detailed explanation of the issue. I need to think 
about this for a bit.

It seems like the WK2 infrastructure should suffer from this same issue. 
Perhaps if we revived WK2 on Windows it would provide a better match to this 
situation.

Could you please do me a favor: copy the text of your e-mail and paste it into 
a new bug at https://bugs.webkit.org and cc me and Darin on this? Just file it 
under WebKit Misc.

Thanks!

-Brent

Sent from my iPad

On Sep 15, 2013, at 8:53 AM, Van Den Berghe, Vincent 
vincent.vandenber...@bvdinfo.com wrote:

 Hello again,
  
 (for Brent Fulgham: codeword “onion”, I repeat, codeword “onion” J)
  
 Context
 Consider embedding WebKit in an ASP.NET website (even though what follows is 
 valid in other scenarios). In order to do this, you need a (managed) thread 
 with a message loop. If you want this to work reliably, you make sure all 
 WebKit’s COM objects are created on that thread. If you chose not to, what 
 follows is still valid.
 Note that this thread doesn’t need to be the main process thread: in the case 
 of a worker process of a web server, you don’t even have access to that. For 
 WebKit, it just needs to be “a” thread with a message loop, as long as it’s 
 the same one.
  
 When you instantiate a Webkit COM object for the first time, Windows’ COM 
 will ultimately call LoadLibrary on WebKit.dll. It will do so on the thread 
 that wants to instantiate the COM object. This initializes the CRT and 
 triggers a call to DllMain with the argument ul_reason_for_call set to 
 DLL_PROCESS_ATTACH.
 When the last reference to the last WebKit object is released, COM will NOT 
 call FreeLibrary(). COM doesn’t know the concept of “last object”, and will 
 keep the DLL around to avoid the overhead of loading it again should another 
 instance be needed.
 By default, your unmanaged DLL will remain loaded until the process is 
 terminated. The main process thread will then call FreeLibrary(), prompting 
 indirectly another call to DllMain with the argument ul_reason_for_call 
 hanksset to DLL_PROCESS_DETACH.
 The main thing to take away from this, is that the thread executing 
 DLL_PROCESS_ATTACH code and the thread executing DLL_PROCESS_DETACH code will 
 not necessarily be the same. In the above scenario, they will never be the 
 same.
 For those who prefer the horse’s mouth: http://msdn.microsoft.com/en-ure 
 us/library/windows/desktop/ms682583(v=vs.85).aspxus 
  
 AtomicString
 Consider the following code:
  
 LONG FontPlatformData::adjustedGDIFontWeight(LONG gdiFontWeight, const 
 String family)
 {
 static AtomicString lucidaStr(Lucida Grande);
 if (equalIgnoringCase(family, lucidaStr)) {
 if (gdiFontWeight == FW_NORMAL)
 return FW_MEDIUM;
 if (gdiFontWeight == FW_BOLD)
 return FW_SEMIBOLD;
 }
 return gdiFontWeight;
  
  
 This is a method (one of many examples) with a static AtomicString object. 
 The constructor of lucidaStr will be executed in a thread-safe way (exactly 
 once) by the first thread that will enter this method. The C++ compiler will 
 generate code that will make sure of it, at least if the compiler obeys 
 C++0x, which mandates this behavior.
 Code will also be executed that registers the destructor  of lucidaStr so 
 that it is executed when the program terminates. The mechanism is similar to 
 functions registered with atexit(). Destruction order will be reverse 
 construction order, as expected.
 This code being in a DLL, it means that the destructor will be called when 
 the DLL is unloaded: after the the DLL_PROCESS_DETACH code of DllMain, the 
 CRT will do so.
 Given the context described above, it means that the destructor of an 
 AtomicString will be executed by a different thread than the one that 
 executed its constructor.
  
 When an AtomicString is destroyed, the following method is executed:
  
 void AtomicString::remove(StringImpl* string)
 {
 ASSERT(string-isAtomic());
 AtomicStringTableLocker locker;
 HashSetStringImpl* atomicStringTable = stringTable();
 HashSetStringImpl*::iterator iterator = atomicStringTable.find(string);
 ASSERT_WITH_MESSAGE(iterator != atomicStringTable.end(), The string 
 being removed is atomic in the string table of an other thread!);
 atomicStringTable.remove(iterator);
 }
  
  
 This will fail on the assertion, since the string was created on the string 
 table of a different thread.
 The process will therefore crash on termination. Every time.
  
 Why this is relevant
 One can argue that for “eternal’ processes, this is not relevant. 
 Unfortunately, this is wrong. For example on Windows, IIS worker processes 
 can be periodically recycled for legitimate reasons (elapsed or scheduled 
 time, number of requests, memory usage or on demand). Every legitimate 
 requests will log a process crash, which is bad form (to say the least).
  
 Workaround
 The workaround I’ve applied was to change

Re: [webkit-dev] Loading and unloading webkit, threading, AtomicString and crashes

2013-09-15 Thread Brent Fulgham
I realized it was easier to light a candle than curse the darkness, so I 
converted the original e-mail to a bug.  Let's move discussion of this issue 
there:

https://bugs.webkit.org/show_bug.cgi?id=121407

Thanks!

-Brent

On Sep 15, 2013, at 10:52 AM, Alexey Proskuryakov a...@webkit.org wrote:

 
 15.09.2013, в 08:53, Van Den Berghe, Vincent 
 vincent.vandenber...@bvdinfo.com написал(а):
 
 static AtomicString lucidaStr(Lucida Grande);
 
 
 It is a mistake to use static objects with destructors in WebKit - we don't 
 want to waste time destructing them at process termination time. To fix this 
 issue, DEFINE_STATIC_LOCAL should be used.
 
 In a somewhat dated checkout I have on this machine, I found 5 instances of 
 static AtomicString in WebCore, and none in WebKit/win.
 
 - WBR, Alexey Proskuryakov
 
 ___
 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] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Brent Fulgham
Hi Vincent and Mark:

On Sep 13, 2013, at 1:06 AM, Salisbury, Mark mark.salisb...@hp.com wrote:

 Vincent,
  
 Maybe some tips I’ve learned could be of help to you or others:
 ·Calling DestroyWindow will cause WebView::close() to be called (when 
 WM_DESTROY is received), but it does not cause WebView’s destructor to be 
 called, that doesn’t happen until the RCW holding the last COM reference is 
 destroyed and the COM ref count goes to 0.  This happens on the GC thread 
 (.NET internals), and deleting core webkit objects from a thread besides the 
 main thread can lead to undefined behavior.  I’d see crashes from concurrent 
 javascript GCs.  I fixed this by marshaling the delete call back to the main 
 thread (in every single COM exposed class).

I’m not sure this is limited to WebKit, or .NET.  I think destroying any GDI or 
other “User Interface” content outside of the main thread causes bad things to 
happen. I’ve seen this with MFC and base WinAPI programs as well.

To be fair, Mac OS has a number of similar constraints on how UI elements are 
handled, resulting in a bunch of infrastructure to allow things to be spun off 
for later processing on the main thread.

 ·WebView’s destructor calls DestroyWindow() on a tool tip window 
 which may or may not have been destroyed (at least on WinCE).  When embedding 
 in a .NET application, there can be a decent gap between the time the 
 WebView’s window is destroyed and the destructor is called.  It’s possible 
 that in the instances when Windows destroyed the tool tip window (because it 
 is a child of the webview window) that the tool tip handle is assigned to 
 another window by the time WebView’s destructor is called.  You can guess 
 what happens then when WebView’s destructor deletes the tool tip window.  
 Windows in the system disappear – sometimes causing a crash.  The only fix I 
 could figure out what to check to see if the window is still a tool tip 
 window before deleting it.

This sounds like a bug. Could you please file one and add me to the CC list on 
it?

 I don’t know if anyone wants to see a patch land for either of these 
 problems, they’re confined to embedded WebKit on Windows under .NET…

I’d love to see the patches.  You are obviously not the only person to suffer 
from these issues, and it would be great to at least document the issue and how 
to work around it.

Thanks!

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] TimerWindowWndProc and dangling page instances

2013-09-13 Thread Brent Fulgham
Hi Vincent,

On Sep 13, 2013, at 1:34 AM, Van Den Berghe, Vincent 
vincent.vandenber...@bvdinfo.com wrote:

 I’m embedding the Wincairo build of WebKit to generate PDF files from web 
 pages in an ASP.NET application.

Yay!

 Webkit isn’t really designed for such a scenario but with some careful 
 patching, a solution can be constructed which is “reasonably reliable”.   
 However, these patches touch on WebKit’s fundamental design decisions and I’m 
 reluctant to submit them without first some validation of someone who knows 
 the code better.   Some are more hacks than patches.

I would still encourage you to file bugs about these items so that there is 
documented history about the issue, and how to work around the problem.

WebKit is designed to be embedded in other applications — that’s exactly why I 
put together the WInCairo port in the first place. However, it has been 
optimized and coded for specific scenarios that may not match your needs. If we 
can make WebKit work better in these other areas (without breaking the existing 
use cases) I would be very strongly in favor of integrating such changes.

 So I became a member of the webkit-dev list and submitted the result of my 
 last frustrating bug hunt to see what happens. And it looks like it’s not 
 totally worthless.

I have always found the webkit-dev list to be extremely helpful. However, we 
will expect you to do some work, too — namely filing bugs and documenting what 
you are doing.  And, hopefully, contributing code to fix the issue!

Also, please CC me on any such bugs you file.

Thanks,

-Brent___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Changes in QtWebKit development

2013-09-13 Thread Brent Fulgham

On Sep 13, 2013, at 10:22 AM, Benjamin Poulain benja...@webkit.org wrote:

 On 9/13/13, 4:50 AM, Albisser Zeno wrote:
 As many of you have probably noticed already, we have recently been focusing 
 on a project called Qt WebEngine. Our WebKit efforts have therefore been 
 reduced significantly over the past weeks.
 While we will keep shipping QtWebKit with Qt for the foreseeable future, we 
 want to concentrate our efforts on Qt WebEngine.
 Therefore we are planning some changes to our development setup. In 
 particular we are planning to remove our QtWebKit/Mac and QtWebKit/Windows 
 builds from WebKit trunk. We will keep maintaining these platforms in a 
 separate branch through the Qt project’s gerrit infrastructure.
 This essentially means our presence in trunk will be reduced to 
 QtWebKit/Linux.
 
 We are planning to gradually implement the required changes within the next 
 month.
 If this proves to bring significant issues for some development, please do 
 let us know and we can sort out a way to work together on a phase-out 
 process.
 This is sad.
 
 When modules of Qt are put on maintenance, it is basically a synonym to 
 it's unmaintained, just let it die. I am very unexcited about having one of 
 those in the tree along the live development from everyone else.
 It is unfair for all the ports who put real efforts in the WebKit opensource 
 project.
 
 Realistically, how much development will go in QtWebKit/Linux? Why does it 
 stay in WebKit trunk if the two other ports are maintained in a branch?

Why don’t they create a WebKit branch and label it as their maintenance branch, 
and then we can purge the Qt stuff to lighten the size of the LayoutTests 
repository.

I don’t see much benefit in keeping the code in place if their plan is to be 
gone shortly.

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Announcing new port: Nix

2013-09-12 Thread Brent Fulgham
Hi,

On 09/12/13, Osztrogonác Csaba  o...@inf.u-szeged.hu wrote:
 Improving cURL network backend (which used by Apple's WinCairo port too)
 
 
The WinCairo port is not an Apple project, though it is tied very closely to 
the existing Apple Windows port.

However, I am quite happy that people have been working on improving the 
libcURL support :-)

 I think these changes/fixes are benefit to the WebKit project. Some of
 them for all ports, some of them for only Linux users, some of them for
 only ARM devices, ...
 
 
The WinCairo port has certainly benefited from these changes. I know that an 
Icon bitmap bug fix was also applicable to the Apple Windows port, though I 
don't think it was something every actually triggered in field use.

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Announcing new port: Nix

2013-09-12 Thread Brent Fulgham

 However, you've already clarified that you're going to improve WebRTC and 
 are, in fact, in the process of doing so.  Furthermore, you've clarified that 
 there is a demand for your port and human resources to maintain it.
 
 I'm actually curious if anyone's opposed to supporting Nix port and why if so.

I'm really interested to see the port, and how they implemented things. There 
are likely to be many things that could be shared with some other ports.

It's not as though they want to provide their own JavaScript implementation! ;)

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Changes to main Frame creation in WebCore

2013-08-18 Thread Brent Fulgham
I can take care of this for the Windows ports. Can you cc me on the bug, please?

Thanks,

-Brent

Sent from my iPhone

On Aug 18, 2013, at 4:33 PM, Andreas Kling akl...@apple.com wrote:

 Hello everyone!
 
 Just a friendly heads-up that I’m planning to land some changes to the way 
 main Frames are created in WebCore soon.
 
 Previously, the WebKit layer would create a Frame with no owner element, and 
 Frame::create() would implicitly tell Page that this is going to be the 
 Page::mainFrame(). That mechanism leaves an awkward window in time where 
 Page::m_mainFrame is null, and the goal here is to get rid of that by having 
 Page construct the main Frame itself.
 
 To do that, the Page constructor needs a FrameLoaderClient for the main 
 Frame, in addition to all the other PageClients it already takes as an 
 argument.
 
 I have a patch here with WebKit1/mac and WebKit2 working, reviewed, and ready 
 to rock: https://webkit.org/b/119964
 
 Someone with know-how from WK1 ports will need to tweak the Page setup code 
 in the relevant WebKit1 initialization function(s) to add a FrameLoaderClient 
 to the PageClients passed to Page::Page(), and pick up the automatically 
 created Page::mainFrame() instead of creating their own brand-new Frame and 
 expecting it to become the main Frame.
 
 Regards,
 Andreas
 ___
 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 Broken?

2013-08-02 Thread Brent Fulgham
Hi Rakesh,

On Aug 2, 2013, at 1:29 AM, Rakesh Sadhu rakeshsa...@hotmail.com wrote:

 But I am facing one more  problem , my release winlauncher launches properly 
 whereas 
 debug winlauncher fails with the message Failed to determine path to AAS 
 Directory”.

WebKit requires certain support DLLs to run properly (e.g., libxml2.dll, 
zlib1.dll, cairo.dll).  For the standard Apple build, these live in the Program 
Files directory and will be installed on your system if you have iTunes. We do 
not have an installer or canonical location for the WinCairo port’s support 
libraries; usually they are just copied to the same directory as the 
application.

 In the file DLLLauncherMain.cpp ::moidfypath 
 
 //#if defined(_M_X64)
 static const wstring pathPrefix = LC:\\Program Files\\Common 
 Files\\Apple\\Apple Application Support;
 //#else
// static const wstring pathPrefix = LC:\\Program Files (x86)\\Common 
 Files\\Apple\\Apple Application Support;
 //#endif
 
 I commented above lines , but i was encountering another problem  
 msvcr80.dll missing .

You could also just return true without doing anything, which is probably the 
right thing to do for the WinCairo port.

The missing “msvcr80.dll” makes me think you have some VS2005-based support 
library DLLs in your path. The current set of WinCairo support dlls are all 
build with VS2010, and do not link against this old runtime.

-Brent





 
 So is it like , my windows somehow got corrupted and i need to redo all or is 
 there any work around for this .
 
 regards
 RSadhu
 
 
 Subject: Re: [webkit-dev] Windows Build Broken?
 From: bfulg...@apple.com
 Date: Thu, 1 Aug 2013 09:50:11 -0700
 CC: mital.d.v...@gmail.com; webkit-dev@lists.webkit.org
 To: rakeshsa...@hotmail.com
 
 Please review your build log.  The problem is the following:
 
 fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or 
 directory”
 
 You do not have the DirectX SDK installed, as documented in Step 4 of 
 http://www.webkit.org/building/tools.html.
 
 -Brent
 
 
 On Aug 1, 2013, at 1:46 AM, Rakesh Sadhu rakeshsa...@hotmail.com wrote:
 
 Hi ,
 I couldn't fix the problem  with vs2005.
 Now I am trying to build with vs2010 and it fails too.
 here is the pasebin link : http://pastebin.com/W0YyGXZG
 Kindly guide.
 
 
 regards
 RSadhu
 
 
 Date: Tue, 23 Jul 2013 07:21:23 +0530
 Subject: Re: [webkit-dev] Windows Build Broken?
 From: mital.d.v...@gmail.com
 To: rakeshsa...@hotmail.com
 CC: webkit-dev@lists.webkit.org
 
 Sorry Its not exactly the same error. but Its similar error which is present 
 in build-webkit
 
 
 I am trying to build using Visual Studio 2010 Express using commandline 
 cygwin tools
 
 Thanks,
 
 Mital Vora.
 
 
 On Tue, Jul 23, 2013 at 7:17 AM, Mital Vora mital.d.v...@gmail.com wrote:
 Hi, 
 
 For the WinCairo Build as well these are the exact errors coming in the 
 buildbot
 
 Building results into: 
 /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/WebKitBuild
 WEBKIT_OUTPUTDIR is set to: 
 C:\Projects\BuildSlave\win-cairo-release\build\WebKitBuild
 WEBKIT_LIBRARIES is set to: 
 Use of uninitialized value in print at 
 /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/Tools/Scripts/webkitdirs.pm
  line 1644.
 
 http://build.webkit.org/builders/WinCairo%20Release/builds/28414/steps/compile-webkit/logs/stdio
 
 
 
 Windows and WinCairo Build from commandline seems broken.. can anybody help 
 fixing this.
 
 Regards,
 
 Mital Vora.
 
 
 On Sun, Jul 21, 2013 at 9:07 PM, Rakesh Sadhu rakeshsa...@hotmail.com wrote:
 Hi ,
 I updated my webkit source code and tried to build it on windows machine , 
 and it fails to compile, with following error
 
 Tools/Scripts/build-webkit --debug
 
 Installing WebKitSupportLibrary...
 The WebKitSupportLibrary has been sucessfully installed in
  /home/rsadhu/trunk/WebKitLibraries/win
 *
 Cannot find '/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
 10.0/Common7/IDE/VCExpress.exe'
 Please execute the file 'vcvars32.bat' from
 'C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\'
 to setup the necessary environment variables.
 *
 Died at /home/rsadhu/trunk/Tools/Scripts/webkitdirs.pm line 1627.
 
 
 Any Pointers on this?
 
 
 ___
 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] WebGL on Windows

2013-08-02 Thread Brent Fulgham
Let’s do it!

-Brent

On Aug 2, 2013, at 1:57 PM, Benjamin Poulain benja...@webkit.org wrote:

 On Fri, Aug 2, 2013 at 1:09 PM, Alex Christensen achristen...@apple.com 
 wrote:
 In the near future I plan to enable WebGL on the AppleWin and WinCairo ports.
 
 This change will require the addition of 2 dlls from ANGLE for anyone who 
 wants to use WebGL on Windows: libEGL.dll (58kb) and libGLESv2.dll (917kb).  
 I’ve soft linked these dlls so that WebKit will work without WebGL for anyone 
 who does not want to ship the additional dlls.  This change will also add 
 about 30 seconds to the clean build time of these ports.
 
 Yay! Great job.
 
 Benjamin
 ___
 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 Broken?

2013-08-01 Thread Brent Fulgham
Please review your build log.  The problem is the following:

fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or 
directory”

You do not have the DirectX SDK installed, as documented in Step 4 of 
http://www.webkit.org/building/tools.html.

-Brent


On Aug 1, 2013, at 1:46 AM, Rakesh Sadhu rakeshsa...@hotmail.com wrote:

 Hi ,
 I couldn't fix the problem  with vs2005.
 Now I am trying to build with vs2010 and it fails too.
 here is the pasebin link : http://pastebin.com/W0YyGXZG
 Kindly guide.
 
 
 regards
 RSadhu
 
 
 Date: Tue, 23 Jul 2013 07:21:23 +0530
 Subject: Re: [webkit-dev] Windows Build Broken?
 From: mital.d.v...@gmail.com
 To: rakeshsa...@hotmail.com
 CC: webkit-dev@lists.webkit.org
 
 Sorry Its not exactly the same error. but Its similar error which is present 
 in build-webkit
 
 
 I am trying to build using Visual Studio 2010 Express using commandline 
 cygwin tools
 
 Thanks,
 
 Mital Vora.
 
 
 On Tue, Jul 23, 2013 at 7:17 AM, Mital Vora mital.d.v...@gmail.com wrote:
 Hi, 
 
 For the WinCairo Build as well these are the exact errors coming in the 
 buildbot
 
 Building results into: 
 /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/WebKitBuild
 WEBKIT_OUTPUTDIR is set to: 
 C:\Projects\BuildSlave\win-cairo-release\build\WebKitBuild
 WEBKIT_LIBRARIES is set to: 
 Use of uninitialized value in print at 
 /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/Tools/Scripts/webkitdirs.pm
  line 1644.
 
 http://build.webkit.org/builders/WinCairo%20Release/builds/28414/steps/compile-webkit/logs/stdio
 
 
 
 Windows and WinCairo Build from commandline seems broken.. can anybody help 
 fixing this.
 
 Regards,
 
 Mital Vora.
 
 
 On Sun, Jul 21, 2013 at 9:07 PM, Rakesh Sadhu rakeshsa...@hotmail.com wrote:
 Hi ,
 I updated my webkit source code and tried to build it on windows machine , 
 and it fails to compile, with following error
 
 Tools/Scripts/build-webkit --debug
 
 Installing WebKitSupportLibrary...
 The WebKitSupportLibrary has been sucessfully installed in
  /home/rsadhu/trunk/WebKitLibraries/win
 *
 Cannot find '/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
 10.0/Common7/IDE/VCExpress.exe'
 Please execute the file 'vcvars32.bat' from
 'C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\'
 to setup the necessary environment variables.
 *
 Died at /home/rsadhu/trunk/Tools/Scripts/webkitdirs.pm line 1627.
 
 
 Any Pointers on this?
 
 
 ___
 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] Ports not building as C++11?

2013-07-30 Thread Brent Fulgham
Hi Patrick,

On Jul 29, 2013, at 10:42 AM, Patrick East patri...@bsquare.com wrote:

 There is support for C++11 on Windows Embedded Compact 2013 using the newer 
 VC11 compiler, but for CE 5, 6, or WEC 7 they will not be able to support it 
 since they are limited to the VC9 compiler. Afaik there doesn’t appear to be 
 any plans from Microsoft to back-port the newer compiler and run time to 
 support older versions of CE.

That’s too bad.  Can you give me an idea of how big a ‘market’ we are talking 
about for these older OS releases?  Are these targets likely to need or benefit 
from access to a ToT WebKit build?

 I realize that CE 5, 6, and 7 are probably not top priorities for the 
 community, but these changes will basically force dropping support for those 
 platforms. We do have some interest in keeping WebKit working for our 
 downstream build, so if it’s possible to make this change over to using C++11 
 in a way that can allow for building without the new features that would be 
 ideal. If there is anything we can do that help make this happen let me know.

I think the goal is to (at least initially) conditionalize the use of various 
C++11 idioms.  But I think we will soon reach a critical mass where we will 
assume the compiler supports the newer language constructs.

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Ports not building as C++11?

2013-07-28 Thread Brent Fulgham
We can support auto and move semantics.  We cannot support ranged iterators 
until VS2012.

But at least it's a step in the right direction...

Sent from my iPad

On Jul 28, 2013, at 2:36 PM, Oliver Hunt oli...@apple.com wrote:

 So wait, is everyone using C++11 now?
 
 I dream of using auto…
 
 :-D
 
 On Jul 28, 2013, at 12:47 PM, Gergely Kis gerg...@homejinni.com wrote:
 
 Hi,
 
 On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen k...@carewolf.com 
 wrote:
 became required in WebKit2. The only fallout will likely be the loss of the 
 Qt
 MIPS bot which is maintained by a third party and is too old.
 The MIPS bot was updated to Debian Wheezy and GCC 4.7.2 a few weeks
 ago, I just forgot to update the buildbot slave info file, did it now.
 
 Best Regards,
 Gergely
 the 3rd party maintaining the MIPS bot :)
 ___
 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] Ports not building as C++11?

2013-07-27 Thread Brent Fulgham
The only platform I know cannot support C++11 is WinCE, and that port is in 
favor of making the move to C++11 in anticipation of updated build tools from 
Microsoft.

What other platform are we talking about here? The GNU compilers have supported 
C++11 for a long time.

-Brent

Sent from my iPhone

On Jul 26, 2013, at 8:12 PM, Anders Carlsson ander...@apple.com wrote:

 
 On Jul 26, 2013, at 8:09 PM, Allan Sandfeld Jensen k...@carewolf.com wrote:
 
 On Friday 26 July 2013, Anders Carlsson wrote:
 Hi everyone,
 
 when Oliver landed his “let’s break everything” patches in JSC the other
 day, I noticed that some of the follow-up build fixes by other ports were
 removing use of C++11 features (mainly nullptr).
 
 Are there any ports that aren’t building as C++11? If so, why not?
 Yes, and because C++11 is not supported on all the platforms we support. 
 
 Could you please elaborate? What compilers are you using?
 
 We don't all have the option to not care about the platforms of a certain 
 fruit 
 themed vendor's 1 or 2 year old operating systems.
 
 I don’t think this comment adds anything constructive.
 
 Thanks,
 - Anders
 ___
 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] Remove CSS_IMAGE_ORIENTATION Feature Guard

2013-07-02 Thread Brent Fulgham
Hi Everyone,

I haven't seen any action on https://bugs.webkit.org/show_bug.cgi?id=116555 (or 
https://bugs.webkit.org/show_bug.cgi?id=92330) in the past month.

I'd like to remove this logic unless there is some activity here.  We can 
always add it back in from SVN history if someone does want to work on it.

I'll submit a patch to remove this code on July 17th unless something changes.

Thanks,

-Brent



On Jun 4, 2013, at 10:15 PM, Gyuyoung Kim wrote:

 Hi,
 
 I'm interested in this feature. So, I took Bug 92330 over. Though I rebased 
 the feature according to review comments, this feature doesn't work yet. So, 
 I have investigated why it doesn't work. However, unfortunately, I need to 
 have time a little further. If there is no big reason this patch should be 
 removed, I'd like to support this feature.
 
 Gyuyoung.
 On Jun 5, 2013 9:45 AM, Mike Lawther mikelawt...@google.com wrote:
 Fwiw, the original author is no longer working on Blink, and the code has 
 been removed from there.
 
 mike
 
 On Jun 5, 2013 1:24 AM, Brent Fulgham bfulg...@apple.com wrote:
 We have code in WebKit that is protected by the ENABLE(CSS_IMAGE_ORIENTATION) 
 guard, but no active WebKit ports seem to enable this feature.
 
 Is anyone currently working on (or planning to work on) this feature?
 
 Since this CSS feature is currently in an early draft form, and is likely to 
 change, we may not want to retain this dead code as it will most likely 
 become obsolete very quickly.
 
 If no one wants to claim ownership of this feature in the next few days, I 
 will submit a patch to remove the dead code.
 
 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


Re: [webkit-dev] There is a linking error when build webkit on windows 7

2013-06-18 Thread Brent Fulgham
Hi SiqinBilige:

On Jun 18, 2013, at 8:03 PM, siqinbilige siqinbil...@gmail.com wrote:

 I wan to build webkit on Windows.
 My environment is :
  Windows 7 Ultimate (Service Pack1) 64bit (japanese)
  Intel(R) Core(TM) i7 CPU / 12.0GB Memory
  VC++ 2010 Express
  Microsoft Windows SDK for windows 7(7.1)
  Safari 5.1.7

All of that should be fine...

 When I run build-webkit, first failed with libs.
  1LINK : fatal error LNK1181: 入力ファイル 'libicuuc.lib' を開けません。

First clue above...

 1Base64.obj : error LNK2019: 未解決の外部シンボル _u_charDirection_46 が関数 enum 
 WTF::Unicode::Direction __cdecl WTF::Unicode::direction(int) 
 (?direction@Unicode@WTF@@YA?AW4Direction@12@H@Z) で参照されました。
 1StringImpl.obj : error LNK2001: 外部シンボル _u_charDirection_46 は未解決です。
 1WTFString.obj : error LNK2001: 外部シンボル _u_charDirection_46 は未解決です。
 1StringImpl.obj : error LNK2019: 未解決の外部シンボル _u_foldCase_46 が関数 bool 
 __cdecl 

... second clue.

When we build on Windows, we do not expect to see the version suffix on the 
function symbols (i.e., the _u_charDirection_46 should be _u_charDirection).

This means that the build system was unable to find the libicuuc.lib library 
in its path, and instead is building using the older symbols.

This usually happens when the WebKitSupportLibraries are not installed, or are 
installed in the wrong place.

Do you have a folder called WebKitLibraries/win/lib32?

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] There is a linking error when build webkit on windows 7

2013-06-18 Thread Brent Fulgham
Hi Siqinbilige:

On Jun 18, 2013, at 8:31 PM, ビリゴ スチン siqinbil...@gmail.com wrote:

 Yes, There is a WebKitLibraries/win/lib32 folder and also have 
 WebKitLibraries/win/lib folder.
 first, there is one file WebKitSystemInterface.lib.
 I copied the all of the files which including libicuuc.lib from 
 WebKitLibraries/win/lib to WebKitLibraries/win/lib32.
 When I run build-webkit, first failed with libs.
 1LINK : fatal error LNK1181: 入力ファイル 'libicuuc.lib' を開けません。
 was passed.
 But failed when linking.

There is a script that runs at the start of the WTFGenerated build 
(build-generated-files.sh) that checks for the presence of the 
lib32/libicuuc.lib file.  It creates a file in your build folder 
(${CONFIGURATIONBUILDDIR}/include/private/ICUVersion.h), which governs 
whether it is looking for versioned (old-stye) or new-style.

Even though you corrected the library paths, this ICUVersion.h file is probably 
messing up your build.

Try deleting it (or just changing the #define U_DISABLE_RENAMING 0 to 
#define U_DISABLE_RENAMING 1, and then do a full rebuild.

-Brent 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Remove CSS_IMAGE_ORIENTATION Feature Guard

2013-06-05 Thread Brent Fulgham
Hi Gyuyoung,

On Jun 4, 2013, at 10:15 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:

 I'm interested in this feature. So, I took Bug 92330 over. Though I rebased 
 the feature according to review comments, this feature doesn't work yet. So, 
 I have investigated why it doesn't work. However, unfortunately, I need to 
 have time a little further. If there is no big reason this patch should be 
 removed, I'd like to support this feature
 
Great!  We'll leave it in then.

-Brent

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Remove CSS_IMAGE_ORIENTATION Feature Guard

2013-06-04 Thread Brent Fulgham
We have code in WebKit that is protected by the ENABLE(CSS_IMAGE_ORIENTATION) 
guard, but no active WebKit ports seem to enable this feature.

Is anyone currently working on (or planning to work on) this feature?

Since this CSS feature is currently in an early draft form, and is likely to 
change, we may not want to retain this dead code as it will most likely become 
obsolete very quickly.

If no one wants to claim ownership of this feature in the next few days, I will 
submit a patch to remove the dead code.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Mismatched Allocators in Windows

2013-05-01 Thread Brent Fulgham
While investigating a crash in the 'create-lots-of-workers' test (see
https://bugs.webkit.org/show_bug.cgi?id=115130), I found that there were a
number of cases where objects were created using the system allocator, but
later freed using the 'fastFree' overload provided by fastMalloc.h.

I proposed having Windows build using the same settings as Gtk/EFL/QT,
which is to avoid overloading global operator new/delete with the
fastMalloc varients (which fixes the crash).  However, I was not sure if
this would create any kind of performance regression.

Oliver Hunt suggested I document which objects were falling into this
mismatched allocator/deallocator camp.

I used a tool called BoundsChecker (similar to Valgrind) to see if I could
identify which objects fell into this category:

Allocator mismatches (running DumpRenderTree on create-lots-of-workers):

1. DumpRenderTree.cpp, Line 245:

[...]
if (lastSlash != -1  lastSlash + 1  path.length())
path = path.substr(0, lastSlash + 1);

return path;

Here, path is set to the result of the substr method, which internally uses
the system 'new'.  When this temporary is destroyed on return, it is
passing through fastFree.

2. DumpRenderTree.cpp, Line 307 (addQTDirToPATH):

// And add the QuickTime dll.
wstring newPath;
newPath.append(qtPath);
newPath.append(L;);
newPath.append(oldPath.data(), oldPath.size());
SetEnvironmentVariableW(pathEnvironmentVariable, newPath.data());

The various calls to 'append' internally use the system 'new'.  When the
newPath temporary is destroyed on method exit, it is cleaned up by fastFree.

3. CSSParser.cpp, Line 421 (setupParser):

if (!stringLength || string.is8Bit()) {
m_dataStart8 = adoptArrayPtr(new LChar[length]);

The m_dataStart8 array is supposedly allocated using system new. In the
destructor, fastFree is getting called.

3. SelectorFilter.cpp, Line 89 (setupParentStack):

m_parentStack.shrink(0);
m_ancestorIdentifierFilter = adoptPtr(new
BloomFilterbloomFilterKeyBits);

The m_ancestorIdentifierFilter BloomFilter is allocated using system new,
but destroyed (later, in SelectorFilter::popParentStackFrame) by fastFree.

4. WebKitSystemInterface.cpp, Line 724 (wkCACFContextCreate):

Create of the context object is allocated with system new.  Later,
wkCACFContextDestroy calls fastFree to cleanup.

5. PluginPackageWin.cpp, Line 174 (fetchInfo):

OwnArrayPtrchar versionInfoData = adoptArrayPtr(new
char[versionInfoSize]);

A character array is allocated using system new, and is cleaned up at scope
exit by fastFree.

4. ThreadingWin.cpp, Line 230 (createThreadInternal):

OwnPtrThreadFunctionInvocation invocation = adoptPtr(new
ThreadFunctionInvocation(entryPoint, data));

ThreadFunctionInvocation is allocated with system new, but deleted by
fastFree.

Not all of these cases make sense to me, so BoundsChecker may be reporting
some false positives.  For example, I don't see how the 'ThreadingWin.cpp'
case would simultaneously see system 'new' for the adoptPtr call, but then
call 'fastFree' when cleaning up.  The entire object's life-cycle is in a
few lines of code.

Thanks,

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

2013-04-16 Thread Brent Fulgham
Hi Daniel,

I'm afraid I don't quite understand the nature of the change you are
proposing:

1. Is it sufficient to supply the full path to the include files (e.g.,
change Foo.h to WebCore/html/Foo.h) to achieve these gains?
2. ... or ... is it sufficient to copy all header files to a common include
target path (e.g., $(BuildDir)/include) to achieve these gains?

I understand that in either case, we would want to remove the various
compiler include path directives so that there are fewer places for it to
search.

Is something else needed?

Thanks,

-Brent


On Tue, Apr 16, 2013 at 12:59 AM, Daniel Bratell brat...@opera.com wrote:

 Den 2013-03-28 18:53:48 skrev Daniel Bratell brat...@opera.com:


  On a Xeon W3550 (quad 3.06GHz), with plenty of RAM but a spinning disk
 and Windows 7:

 webcore_dom: 58 seconds - 38 seconds (-35%)
 webcore_rendering: 106 seconds - 73 seconds (-30%)
 webcore_platform: 59 seconds - 34 seconds (-43%)

 (Yes, better than the 25% mentioned in the subject but this was on a
 different computer)


 I understand that this is not as interesting anymore since gyp is gone and
 Windows is a smaller platform than it used to be, but for the record, I've
 kept working on it in between other things and the total gain is about 7
 minutes, which is better than the 25% estimate.

 This is in chromium land with the patch in http://pastebin.com/90vx4sepand 
 the script in
 http://pastebin.com/WmzGY8zs. Both are pre-blink so they should look
 familiar, though they apply to gyp files which are gone. Neither have been
 cleaned up so they are a bit embarrassing but if someone wants to keep
 working on this in WebKit they might be a good starting point.

 To do in that case:

 * Port to the new build system for Windows.

 * Test compile a lot of platform and verify gains in Windows.

 * Integrate the idltopath.pm map generator into the build system.

 * Apply.


 /Daniel
 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/**mailman/listinfo/webkit-devhttps://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] Buildsystem cleanup

2013-04-10 Thread Brent Fulgham
Hi everyone:

Sent from my iPhone

On Apr 10, 2013, at 3:30 PM, Roger Fong roger_f...@apple.com wrote:

 2. If you're working on Windows, open up the solution with Visual Studio and 
 do work as usual, unless you want to add files in which case you go through 
 the CMake scripts again before moving on.
   Would all the project filters and solution dependencies would still be 
 in tact? Or is the solution file something that we would maintain that would 
 hook into the generated projects?. 

I think the enable/disable stuff we use for conditionally building WinCairo 
versus stock Apple would go away; ale generates project files with only the 
relevant items per build.

 -I'm assuming there's a CMake flag for specifying which version of visual 
 studio to generate project files for?

Yes, it's -G

It allows choices between Xcode, Visual Studio 2006, VS2012, etc.

 ... move to CMake. I don't think we really have the resources to get things 
 hooked up on our end in the immediate future, but perhaps in the coming 
 months.

I can help with this now.

 Also if we do end up switching over I would highly push for all other ports 
 besides Mac to adopt CMake and require any new ports to use it as well.

Agreed!

Patrick, can you expound a little on the abilities cmake apparently has for 
performing shell operations? I think you suggested at one point that some of 
the. Things we currently do with BASH and DOS shell scripts could be done by 
cmake. Can you elaborate on what kind of things?

- Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


  1   2   3   >