Re: [webkit-dev] New EWS Non-Unified builder

[Myles C. Maxfield via webkit-dev]

This seems to be a discussion around “when is doing things lazily valuable.” If 
the work will always have to be done eventually, then doing it lazily is worse 
than doing it up front. But of the work has a significant chance of never being 
needed to be done, then doing it lazily is better.

I think one could make a case that, on an infinite timescale, fixing a file’s 
includes will always have to be done, because it will always, eventually, one 
day, cause breakage.

> On Apr 30, 2021, at 8:44 AM, Darin Adler via webkit-dev 
>  wrote:
> 
> OK. I acknowledge my view on this is different from the others commenting 
> here, perhaps because of different ideas about what is hard and requires 
> expertise. I won’t stand in the way of changes you want to make. You know my 
> view now.
> 
> — 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] Request for Position: COLR v1 Vector Color Fonts

[Myles C. Maxfield via webkit-dev]

Hi Dominik!

Thanks for the request.

We (Apple’s WebKit team and Core Text team) have feedback about some technical 
details of the spec, but I’ll omit that here, since this is not the right place 
for it. We’ll open issues on the GitHub repository you linked to with these 
detailed items of feedback.

At a high level, here is a list of things we like about the proposal:
Chrome aims to ship support for advanced vector-based color fonts

Inversely, here is a list of things we don’t like about the proposal:
It re-invents the wheel. This new format is as expressive and powerful as any 
general-purpose 2D graphics serialization format. There are many, many existing 
serialization formats for general-purpose 2D graphics.
It doesn’t exist yet (outside of a development configuration of Chrome). 
OT-SVG, which is just as expressive*, exists and has shipping implementations 
in DirectWrite, Core Text, Firefox, and many (most? all?) of Adobe creation 
apps. Many OT-SVG fonts already exist.
Because this proposal doesn’t exist yet outside of Chrome, there is no 
ecosystem in existing authoring tools. Conversely, many design authoring tools 
already export SVG.
Supporting both OT-SVG and this new proposal is twice (-ish) the maintenance 
burden, for a format that isn’t any more expressive* than the format we support 
already.
Supporting both OT-SVG and this new proposal increases our binary size. We 
expect the additional binary size increase to be roughly equivalent to the 
binary size increase we observed after implementing OT-SVG. (OT-SVG does 
involve an XML parser, but WebKit already links with an XML parser, so we 
expect the size of this new proposal to be roughly equal to the size increase 
we saw after implementing OT-SVG. This proposal would require its own novel 
parsing / overflow detecting / interpretation code.)
Supporting both OT-SVG and this new proposal roughly doubles the surface area 
for security attacks for vector-based color fonts.
Even considering an engine that only supports this proposal and not SVG, we 
haven’t seen any evidence that avoiding XML will reduce security bugs compared 
to a novel binary format. Historically, in WebKit, we’ve observed that opaque 
binary formats (like image formats) have plenty of their own security bugs.
The spec has over 2,500 lines, and the images/ directory of the spec has 77 
figures, and there is only a single implementation of this proposal. It’s 
complicated enough that we’re not confident that it can be implemented 
interoperably. We’re worried the behavior of the drawing operations may be 
specific to Skia, and difficult/impossible to implement on Core Graphics. For 
example, at first glance, we are not sure that the radial gradients in this 
proposal can be implemented on Core Graphics. As far as we’re aware, this 
proposal has not undergone a rigorous standardization process from many 
independent stakeholders.
Embedding raster image data inside color font tables is common today, but this 
new proposal has no affordances for allowing it, despite its vector facilities 
being as expressive as any general-purpose 2d graphics serialization format. 
Therefore, it doesn’t actually improve upon the color font table fragmentation 
situation, which is widely regarded as one of the biggest drawbacks to color 
fonts today.

Given these two lists, Apple’s WebKit team and Core Text team are negative on 
this proposal.

Thanks,
Myles

* Except for font variations, which A) can be added to OT-SVG easily, and B) 
probably aren't a particularly compelling feature in conjunction with color 
font technology, at least now.

> On Mar 23, 2021, at 4:23 AM, Dominik Röttsches  wrote:
> 
> Hi, 
> 
> This is a request for WebKit's position on COLR v1 vector color fonts.
> 
> Spec:
> 
> https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md 
> 
> Proposed changes to ISO/IEC 14496-22 (Amendment 2)
> 
> Chromium Bug:
> https://crbug.com/1170733 
> 
> Summary:
> 
> COLR v1 fonts are a new vector color font format that provides gradients, 
> transforms and compositions for font glyph drawing enabling an expressive, 
> very compact glyph definition format for OFF/OpenType fonts. This format 
> provides size and rendering fidelity (scaling) advantages over bitmap fonts 
> such as SBIX, CBDT/CBLC fonts for glyph designs that lend themselves well to 
> being encoded as vector art. 
> 
> Thank you in advance for your position statement on this topic,
> 
> Dominik 
> 
> 
> 
> 
> 
> 

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

Re: [webkit-dev] Request for position: CSS Ruby Layout Module

[Myles C. Maxfield]

We are positive on these.

Thanks,
Myles

> On Sep 23, 2020, at 9:20 PM, TAMURA, Kent  wrote:
> 
> I'd like to request an official position of WebKit on CSS Ruby Layout Module 
> [1], especially on the following features in the specification:
> 
> - Ruby-specific 'display' property values: ruby, ruby-base, ruby-text, 
> ruby-base-container, ruby-text-container
> - 'ruby-merge' property
> - 'ruby-align' property, and remove 'text-align' property support for .
>with text-align is used in 0.002% of page views. [2]
> - 'ruby-overhang' property
> 
> Note that Firefox already shipped them.
> 
> 
> [1] https://drafts.csswg.org/css-ruby-1/ 
> 
> [2] https://www.chromestatus.com/metrics/feature/timeline/popularity/3313 
> 
> 
> -- 
> TAMURA Kent 
> Software Engineer, Google 
> 
> 
> ___
> 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] Request for position on @font-face descriptors ascent/descent/line-gap-override to override font metrics

[Myles C. Maxfield]

I’m on record in that csswg-drafts issue as being positive on these descriptors.

Myles

> On Sep 18, 2020, at 12:55 PM, Xiaocheng Hu  wrote:
> 
> 
> Hi webkit-dev,
> 
> I'd like to request an official position on @font-face descriptors 
> `ascent-override`, `descent-override` and `line-gap-override` for overriding 
> the default font metrics.
> 
> Explainer: https://gist.github.com/xiaochengh/da1fa52648d6184fd8022d7134c168c1
> Spec: https://drafts.csswg.org/css-fonts-4/#font-metrics-override-desc
> Chromestatus: https://www.chromestatus.com/feature/5651198621253632
> 
> Other information:
> 
> These descriptors are newly added into CSS Fonts Level [1], following a 
> recent resolution [2].
> Chromium has already implemented them in M86 behind a flag [3].
> 
> [1] https://github.com/w3c/csswg-drafts/pull/5521
> [2] https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-693528301
> [3] 
> https://chromium-review.googlesource.com/q/hashtag:%22font-metrics-override%22
> 
> Thanks,
> Xiaocheng
> ___
> 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] Implementing OffscreenCanvas

[Myles C. Maxfield]

> On Oct 10, 2019, at 12:57 PM, Ryosuke Niwa  wrote:
> 
> Hi Chris,
> 
> I'm excited that you're working on OffscreenCanvas because I think it would 
> be a valuable feature

Me too!!!

> , and I'm confident we can come up with a strategy to limit its privacy & 
> security risk as we see fit.
> 
> However, many of your patches seem to ignore the fact most of WebCore objects 
> aren't thread safe. For example, CSS parser and the entire CSS object model 
> aren't designed to used in non-main thread. Regardless of how ready Linux 
> ports might be, we can't land or enable this feature in WebKit until all 
> thread safety issues are sorted out.
> 
> Unfortunately, I can't make a time commitment to review & find every thread 
> safety issue in your patches. Please work with relevant experts and go over 
> your code changes.

I’d be happy to work with you on this.

> 
> For example, it's never safe to an object that's RefCounted in multiple 
> threads because RefCounted isn't thread safe. One would have to use 
> ThreadSafeRefCounted. It's never safe to use AtomString from one another in 
> another because AtomString has a pool of strings per thread. For that matter, 
> it's never safe to use a single String object from two or more threads 
> because String itself is RefCounted and isn't thread safe. It's not not okay 
> to do readonly access to basic container types like Vector, HashMap, etc... 
> because they don't guarantee atomic update of internal data structures and 
> doing so can result in UAF.
> 
> I think the hardest part of this project is validating that enabling this 
> feature wouldn't introduce dozens of new thread safety issues and thereby 
> security vulnerabilities.

Sounds like this this is a good candidate for a feature flag.

> 
> - R. Niwa
> 
> On Thu, Oct 10, 2019 at 4:23 AM Chris Lord  > wrote:
> 
> I've spent the last month or so 'finishing' the implementation of
> OffscreenCanvas[1], based on Žan Doberšek's work from a year ago[2].
> OffscreenCanvas is an API for being able to use canvas drawing without a
> visible canvas, and from within Workers. It's supported by Blink and has
> partial support in Gecko.
> 
> It's at the point now where I'd consider it a finished draft - it is
> almost fully implemented and passes the majority of relevant tests in a
> debug build without crashing, but has some areas that need completion on
> other platforms (async drawing on non-Linux) and some missing parts (Web
> Inspector, ImageBitmapRenderingContext). It almost certainly needs
> reworking in places.
> 
> My work is on GitHub[3] - I'd like to solicit reviews and comment. Some
> of the bugs hanging off [2] have patches that need review and I think
> are near ready to being landable as the foundation of this work. It is
> broadly split up like so:
> 
> - Refactor to move functionality from HTMLCanvasElement to CanvasBase
> - Refactor to not unnecessarily require HTMLCanvasElement in places
> - Implement OffscreenCanvas functionality
> - Make font loading/styling usable from a Worker and without a Document
> - Implement AnimationFrameProvider on DedicatedWorkerGlobalScope
> - Implement asynchronous drawing updates on placeholder canvases
> 
> I expect the font-related stuff to be the most contentious, and my
> AnimationFrameProvider implementation may be too trivial (but might be
> ok for a first go?)
> 
> All feedback appreciated. Best regards,
> 
> Chris
> 
> [1]
> https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface
>  
> 
> [2] https://bugs.webkit.org/show_bug.cgi?id=183720 
> 
> [3] https://github.com/Cwiiis/webkit/tree/offscreen-canvas 
> 
> ___
> 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] MathML Refresh Heads up

[Myles C. Maxfield]

> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa  wrote:
> 
> 
> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang  > wrote:
> Hello WebKit developers,
> 
> As some of you may know, Igalia is working on MathML support in Chromium
> this year [1]. As part of that effort we joined a new MathML Refresh
> Community Group [2] and one goal is to focus on a core spec for browser
> implementations [3] to:
> - Remove deprecated/uncommon/duplicate math features that could be
> implemented by polyfills (relying on MathML core and other web
> technologies).
> 
> I'd be very much concerned about backwards compatibility here when it come to 
> removing any features.
> It's important to notice that WebKit is also used by hundreds of thousands of 
> iOS apps and macOS apps.
> How do we know we won't break those applications?
> 
> In general, I don't agree with whatever Google said about MathML being too 
> complex, etc…

The original sentence doesn’t say they will be removing anything in WebKit. 
There are plenty of features that have been removed from specs that we continue 
supporting in WebKit for backwards compatibility.

We could also consider migrating our implementation to a JS polyfill if one 
exists.

Is there a characterization of which features are planned for deprecation? We 
might be able to do some analysis on iBooks' and iOS apps’ content.

> 
> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
> help implementation and conformance testing.
> - Align MathML with CSS/HTML (parsing, layout...), introducing new web
> platform features (CSS, fonts...) for math if necessary.

This sounds wonderful! A more coherent MathML story going forward would be 
fantastic.

> 
> On the other hand, these seem like very valuable improvements.
> 
> We expect that this effort will improve browser interoperability and
> reduce complexity of current implementations.
> 
> Given there aren't too many websites that deploy MathML directly on 
> production, my concerns are more about existing iOS and madOS apps that embed 
> WKWebView or WebView / UIWebView and use MathML.
> 
> - 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] Server based HTML features

[Myles C. Maxfield]

> On Oct 26, 2017, at 7:12 AM, Nagendra K  wrote:
> 
> Hi,
> 
> I have a Linux based embedded device which has WebKit of 2010, can I backport 
> features like xhr2, CSP1. Do these features depend on any other features?
> Reading the standard there seems to be dependencies with feature like 
> webworkers, ES6.
> Can someone share the info on xhr2 and CSP1 dependencies. Also do these 
> features have depency on the PORT like webkitgtk, Qt etc. 

I don’t believe the WebKit project is interested in back-porting features 
across 7 years of commits. Feel free to do this in your fork, but don’t expect 
much help or support from the WebKit developer community.

> 
> Second a basic question, how the browser and WebKit communicate?

WebKit is a framework (or library, depending on your port), and we communicate 
the same way any other framework communicates with any other framework.

> 
> Thanks and Regards,
> Nagendra
> 
> ___
> 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: Remove ENABLE(MATHML)

[Myles C. Maxfield]

Is there any development being done on MathML? There are quite a few places 
where our implementation is fairly broken. This, coupled with the fact that 
most places which use MathML on the Web fallback to MathJax (which doesn’t need 
MathML) makes me question whether we want to continue supporting MathML in the 
first place.

> On Oct 25, 2017, at 11:37 AM, Michael Catanzaro  wrote:
> 
> On Wed, Oct 25, 2017 at 12:05 PM, Maciej Stachowiak  wrote:
>> Why don't we wait to hear from port owners whether they would actually want 
>> to disable MathML for reason of compatibiltiy. Knowing answers to the above 
>> questions would help.
> 
> For GTK and WPE, I think it's fine to have MathML enabled unconditionally.
> 
> 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] Forward.h's Vector

[Myles C. Maxfield]

> On Sep 13, 2017, at 8:11 AM, JF Bastien  wrote:
> 
> Hello WebCritters,
> 
> I’m moving some code around, and one particular header I have is included 
> everywhere in JSC so I’d like it to be lightweight and include as few other 
> headers as possible. It unfortunately uses WTF::Vector, but it only does so 
> as a pointer:
> 
> void ohNoes(Vector*);
> 
> It seems like something a forward declaration would fix nicely, and oh joy 
> and wonder we have Forward.h just for this! Here’s what it does:
> 
> template minCapacity, typename Malloc> class Vector;
> 
> That’s nice and great for T, but all the other template parameters are SOL 
> because Vector is actually declared with default template parameters:
> 
> template CrashOnOverflow, size_t minCapacity = 16, typename Malloc = FastMalloc>
> class Vector : private VectorBuffer {
> 
> The extra painful thing is that, contrary to what I originally thought, one 
> cannot declare Vector in Forward.h and then define it in Vector.h with the 
> same defaults twice! Ideally the compiler would just yell at a mismatch, but 
> instead it says error: template parameter redefines default argument (thanks 
> clang, that’s exactly what I’m trying to do, just tell me if you catch a 
> mismatch and ODR away otherwise).
> 
> Here’s what I propose:
> 
> Change the forward declaration in Forward.h to contain the default template 
> parameters (and forward-declare CrashOnOverflow).
> Remove these default template parameters from Vector.h.
When looking for default parameters, I would expect to find them next to the 
Vector definition. If we do this, #4 should be required.
> Include Forward.h in Vector.h.
> Optionally, if the WebCritters think it useful, leave a comment just above 
> the Vector definition redirecting to Forward.h for defaults (or more fancy, 
> use size_t inlineCapacity /*=0*/ style like LLVM’s codebase does, and have a 
> tool that checks for consistency).
> Optionally, try to fix C++20 so this isn’t A Thing anymore. Note that my 
> hopes are low because of modules (why fix it if modules will magically make 
> this not a thing).
> 
> Alternatively, I could just include Vector.h and be done with it.
> 
> Thoughts?
> 
> JF
> 
> ___
> 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] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Myles C. Maxfield]

I often use the “Show Preprocessed Source” option in Xcode. Will I be able to 
continue using this?

> On Aug 29, 2017, at 8:10 AM, Sergio Villar Senin  wrote:
> 
> O Lun, 28-08-2017 ás 17:37 -0700, Keith Miller escribiu:
>> Hello fellow Webkittens,
>> 
>> Are you growing tired of long cat naps while waiting 45 minutes for
>> WebKit to build? (I’ve definitely never done this 蘿!)
>> Do you want WebKit to build up to 3-4x faster on a clean build?*
>> Does seeing your incremental build… stay the same sound good?
>> 
>> You’ll be purring with excitement after you switch to unified source
>> builds!**
> 
> [...]
> 
>> Are there other issues that people think might occur with unified
>> sources? Note, It’s also likely that there are some source files that
>> need to be excluded from the unified source builds for various
>> reasons.
> 
> I wonder whether the unified sources builds would still allow us to
> keep using compiler caches like ccache.
> 
> Second question/caveat is, wouldn't the bundle build penalize too much
> incremental builds? If your data is correct we would get a <20% build
> time increment for a single change in a cpp file which is I think the
> most common scenario for a WebKit developer.
> 
> Don't get me wrong, I'm really excited about this change, just wanted
> to make sure that it does not penalize too much other scenarios.
> 
> BR
> ___
> 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] Looking to remove cygwin dependency for javascript tests for Windows ports

[Myles C. Maxfield]

Alex’s claim should be broadened: The right direction is to eventually not use 
Cygwin for anything at all.

> On Aug 2, 2017, at 8:35 PM, Alex Christensen  wrote:
> 
> I think eventually running all tests on Windows without Cygwin would be a 
> step in the right direction.
> 
>> On Aug 2, 2017, at 9:53 AM, Szabo, Stephan (San Francisco) 
>>  wrote:
>> 
>> Hi,
>> 
>> As part of Sony's work on getting the jsconly build for Windows, we're also 
>> looking at the possibility of trying to remove/reduce the dependency on 
>> Cygwin for the javascript tests from run-javascript-tests since the build 
>> itself runs from a normal windows shell. Internally we did a very 
>> preliminary POC of a version of run-jsc-stress-tests for windows which built 
>> perl scripts for the test scripts rather than shell scripts and were able to 
>> get a bunch of the tests running. We attached that to 
>> https://bugs.webkit.org/show_bug.cgi?id=174985 . Obviously, that's not a 
>> reasonable version for inclusion, but we wanted to discuss whether there was 
>> support for removing the dependency before doing too much more down this 
>> path.
>> 
>> Our current thinking is that if we go forward with this, we'd probably step 
>> it as:
>> 1. Move the test script and test runner code from run-jsc-stress-tests into 
>> a ruby file that is included from the main script
>> 2. Make an option to allow using an alternate version of the above
>> 3. Make an alternate version that didn't rely on shell
>> 
>> Thanks,
>> Stephan
>> ___
>> 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] Passing a font from WebProcess to UIProcess

[Myles C. Maxfield]

I don’t think there is a platform independent method.

—Myles

> On Aug 4, 2017, at 3:48 PM, Joshua Watt <jpewhac...@gmail.com> wrote:
> 
> On Fri, 2017-08-04 at 13:15 +0200, Myles C. Maxfield wrote:
>> You can
>> use CTFontDescriptorCopyAttributes() and CTFontDescriptorCreateWithAt
>> tributes() and serialize the intermediate dictionary.
> 
> Ah, I should have clarified: This is on a Linux port :). I was hoping
> for some platform independent method, but perhaps that isn't possible.
> 
>> 
>> —Myles
>> 
>>> On Jul 19, 2017, at 7:48 PM, Joshua Watt <jpewhac...@gmail.com>
>>> wrote:
>>> 
>>> All,
>>> 
>>> I have a need to "pass" a font from the WebProcess to the UIProcess
>>> (really, I just need to be able to recreate the same font in the
>>> UIProcess that was used in the WebProcess). Does anyone know of a
>>> mechanism to do this (preferably in a platform independent manner)?
>>> Ideally, there would be some structure or string that "describes" a
>>> font that could then pass through and use it to (re)construct the
>>> Font
>>> in the UIProcess.
>>> 
>>> Thanks,
>>> Joshua Watt
>>> ___
>>> 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] Passing a font from WebProcess to UIProcess

[Myles C. Maxfield]

You can use CTFontDescriptorCopyAttributes() 

 and CTFontDescriptorCreateWithAttributes() 

 and serialize the intermediate dictionary.

—Myles

> On Jul 19, 2017, at 7:48 PM, Joshua Watt  wrote:
> 
> All,
> 
> I have a need to "pass" a font from the WebProcess to the UIProcess
> (really, I just need to be able to recreate the same font in the
> UIProcess that was used in the WebProcess). Does anyone know of a
> mechanism to do this (preferably in a platform independent manner)?
> Ideally, there would be some structure or string that "describes" a
> font that could then pass through and use it to (re)construct the Font
> in the UIProcess.
> 
> Thanks,
> Joshua Watt
> ___
> 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] Konstantin Tokarev is now a WebKit reviewer

[Myles C. Maxfield]

Yyyy!!

> On May 22, 2017, at 5:09 PM, Yusuke SUZUKI  wrote:
> 
> Congrats!
> 
> On Tue, May 23, 2017 at 2:25 Mark Lam  > wrote:
> Hi everyone,
> 
> I would like to announce that Konstantin Tokarev (annulen on #webkit) is now 
> a WebKit reviewer.  Konstantin has extensive knowledge of WebKit, and has 
> resurrected the QtWebKit port, helped WebKit compete against Chromium in the 
> Qt project, and ensured that the dozens of applications that depend on 
> QtWebKit will soon be able to receive updated versions of WebKit.
> 
> Please join me in congratulating Konstantin, and send him some patches to 
> review.
> 
> Konstantin, congratulations.
> 
> Mark
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
> -- 
> Regards,
> Yusuke Suzuki
> ___
> 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] Heads up: ICU source compatibility breakage in 59.1 release

[Myles C. Maxfield]

The fact that we use ICU is an implementation detail. It seems wrong to let 
this affect our public API.

—Myles

> On May 2, 2017, at 10:31 AM, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> ICU 59.1 release came out recently, featuring major source compatibility 
> break. Notably, they've changed type of UChar to be char16_t, which does not 
> allow automatic type conversion from unsigned short in C++ code.
> 
> Possible compilation fix is patch [1], however it changes definitions of 
> JSChar and WKChar in public headers. Another problem is keeping compatibility 
> with older ICU releases, that requires ICU version check in public headers.
> 
> Any thoughts how should it be resolved?
> 
> [1] 
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/icu59.patch?h=packages/webkit2gtk
> 
> -- 
> 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] WebKitLegacy on iOS

[Myles C. Maxfield]

The iOS app review policy currently disallows custom builds of WebKit in any 
app on the App Store. Are you planning on submitting your app to the App Store?

—Myles

> On Apr 11, 2017, at 1:55 PM, Pavel Kapinos  
> wrote:
> 
> Hi,
> 
> I am sorry for bothering here. I posted first on webkit-help, but it seems 
> nobody is there, so I hope somebody from developers may give me a clue. Thank 
> you!
> 
> I git WebKit from webkit.org build it for device and embedded WebKitLegacy 
> and WebCore into iOS app. Then loaded and run app on device no problem! App 
> instantiates WebView and loads URL into it and it all works great - except I 
> can't add that instance of WebView as subview to UIView as it is a WAKView 
> apparently Did I miss something here or when compiling and building WebKit? I 
> need WebView as opposed to UIWebView WKWebView, as WebView can give access to 
> DOM through the standard DOM bindings. Thank you very much! 
> 
> Cheers,
> Pavel.
> ___
> 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] WebCore/platform standalone library

[Myles C. Maxfield]

Don and I have implemented this at 
https://bugs.webkit.org/show_bug.cgi?id=143358

I think we're all ready to go! Reviews welcome!

(mcatanzaro: feel free to do a partial review for the non-Xcode build stuff )

--Myles

> On Jan 18, 2017, at 1:39 PM, Alex Christensen <achristen...@apple.com> wrote:
> 
> Windows must also stay a static library.  I can volunteer the 
> currently-completely-experimental-anyways Mac CMake build to have PAL as a 
> shared library.  It would be nice if people had more of a reason to keep it 
> working.
>> On Jan 18, 2017, at 1:23 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
>> 
>> On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
>>> Static (At least for the Xcode projects. I imagine the cmake-based
>>> projects could do whatever they want here).
>> 
>> For GTK+ we really want static as well, we do not want a new shared
>> library. So no difference here.
>> 
>> 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] WebCore/platform standalone library

[Myles C. Maxfield]

Alright - I’ve had a long and involved conversation with people who know things 
about Apple’s internal build infrastructure. The result of this conversation is:

1. Currently, the build infrastructure is configured in such a way as to not be 
compatible with a new folder in the top-level Source directory. Therefore, PAL 
must live inside a subdirectory of WebCore for now. We have plans to 
reconfigure the build infrastructure to relax this constraint, but it is 
difficult enough that it won’t be done soon. Once the constraint is relaxed, we 
can move PAL to a top-level directory inside Source.

2. Making a new Xcode project for PAL is the most sensible way forward.

I think this unblocks us. I’ll answer all the open questions inline below.

—Myles

> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote:
> 
> Here’s a quick rundown of where we stand. Please correct me if any of this is 
> inaccurate.
> 
> There are a few separate issues:
> Path on disk of PAL folder: Sounds like everyone more-or-less agrees that 
> this should belong in Source/, not in Source/WebCore/. However, I believe 
> this is currently incompatible with Apple’s internal build infrastructure. If 
> that’s true, then this issue is decided.

Source/WebCore/PAL

> Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
> top-level namespace PAL (and not WebCore::PAL).

PAL, not WebCore::PAL

> #include style of PAL headers: Sounds like everyone agrees this should be the 
>  style. There are two ways to achieve this:
> Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has 
> a problem where it is easy to include other files inside WebCore but outside 
> of PAL, since they are in the search path. This is the approach Don and I 
> took in our patch, and solved this problem by using the Python script to 
> check the #include lines.
> Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. 
> This has the same problem WTF has where there is a nested folder with the 
> same name.

The second option

> Presence of an Xcode project: Sounds like this is possible and the best way 
> forward. Does this work back to the earliest OS we build on?

Yes

> Static library or shared library: I was under the impression that using a 
> shared library could potentially have performance problems, which would not 
> occur with a static library. However, a shared library would enforce layering 
> naturally, whereas a static library would need either
> An application to link to it and not to WebCore, such as a unit test suite, or
> Some out-of-band layering enforcement, like a Python script.
>   I’m a little hesitant to rely on a testing application to 
> enforce layering in shipping code because some ports may choose not to build 
> those tests.

Static (At least for the Xcode projects. I imagine the cmake-based projects 
could do whatever they want here).

> 
> 
> 
> 
> So, here are the items which need to be solved:
> Do Xcode cross-project references work going back to the oldest Xcode we 
> build on?
> Regarding issue #2 above, should I put source files in WebCore/pal or 
> WebCore/PAL/pal?
> How do people feel about relying on a non-shipping application to enforce 
> laying in shipping code?
> 
> 
> Also (note to self): I need to figure out the ForwardingHeaders story.
> 
> —Myles
> 
>> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev <annu...@yandex.ru 
>> <mailto:annu...@yandex.ru>> wrote:
>> 
>> 
>> 
>> 14.01.2017, 17:16, "Fujii Hironori" <fujii.hiron...@gmail.com 
>> <mailto:fujii.hiron...@gmail.com>>:
>>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev <annu...@yandex.ru 
>>> <mailto:annu...@yandex.ru>> wrote:
>>>>  Static library is just an (indexed) archive of object files, symbol 
>>>> dependencies are not resolved when it is created. Instead this happens 
>>>> when static library is linked into shared library or executable.
>>>> 
>>>>  If PAL is static and uses symbol from WebCore, link failure may happen 
>>>> only[*] if that symbol is not used anywhere in WebCore itself (provided 
>>>> that PAL stays after WebCore in linker command line and options like 
>>>> --start-group/--end-group are not used).
>>>> 
>>>>  [*] Assuming linker behavior similar to ELF linkers
>>> 
>>> You can check unresolved symbols of the static library by creating a
>>> unit test executable of PAL.
>> 
>> Actually, it enough just to avoid adding WebCore to include directories of 
>> PAL, and code with layering violation won't compile.
>> 

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

The ar utility isn’t a linker - it just collects object files. I don’t believe 
it has any concept of matching symbols up to exported symbols in external 
shared libraries (like JavaScriptCore for WTF).

(But of course someone can correct me if I’m wrong.)

—Myles

> On Jan 14, 2017, at 1:38 PM, Darin Adler <da...@apple.com> wrote:
> 
>> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote:
>> 
>> However, a shared library would enforce layering naturally, whereas a static 
>> library would need either an application to link to it and not to WebCore, 
>> such as a unit test suite, or some out-of-band layering enforcement, like a 
>> Python script.
> 
> I’m surprised to learn this. There is no way to build a static library that 
> gives us linker errors if there are unresolved references?
> 
> — Darin

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

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Here’s a quick rundown of where we stand. Please correct me if any of this is 
inaccurate.

There are a few separate issues:
Path on disk of PAL folder: Sounds like everyone more-or-less agrees that this 
should belong in Source/, not in Source/WebCore/. However, I believe this is 
currently incompatible with Apple’s internal build infrastructure. If that’s 
true, then this issue is decided.
Namespace of PAL symbols: Sounds like everyone agrees there should just be a 
top-level namespace PAL (and not WebCore::PAL).
#include style of PAL headers: Sounds like everyone agrees this should be the 
 style. There are two ways to achieve this:
Add WebCore/ to the search path, and put PAL files in WebCore/pal/. This has a 
problem where it is easy to include other files inside WebCore but outside of 
PAL, since they are in the search path. This is the approach Don and I took in 
our patch, and solved this problem by using the Python script to check the 
#include lines.
Put PAL files in WebCore/PAL/pal/, and add WebCore/PAL/ to the search path. 
This has the same problem WTF has where there is a nested folder with the same 
name.
Presence of an Xcode project: Sounds like this is possible and the best way 
forward. Does this work back to the earliest OS we build on?
Static library or shared library: I was under the impression that using a 
shared library could potentially have performance problems, which would not 
occur with a static library. However, a shared library would enforce layering 
naturally, whereas a static library would need either
An application to link to it and not to WebCore, such as a unit test suite, or
Some out-of-band layering enforcement, like a Python script.
I’m a little hesitant to rely on a testing application to 
enforce layering in shipping code because some ports may choose not to build 
those tests.




So, here are the items which need to be solved:
Do Xcode cross-project references work going back to the oldest Xcode we build 
on?
Regarding issue #2 above, should I put source files in WebCore/pal or 
WebCore/PAL/pal?
How do people feel about relying on a non-shipping application to enforce 
laying in shipping code?


Also (note to self): I need to figure out the ForwardingHeaders story.

—Myles

> On Jan 14, 2017, at 10:47 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 14.01.2017, 17:16, "Fujii Hironori" :
>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev  
>> wrote:
>>>  Static library is just an (indexed) archive of object files, symbol 
>>> dependencies are not resolved when it is created. Instead this happens when 
>>> static library is linked into shared library or executable.
>>> 
>>>  If PAL is static and uses symbol from WebCore, link failure may happen 
>>> only[*] if that symbol is not used anywhere in WebCore itself (provided 
>>> that PAL stays after WebCore in linker command line and options like 
>>> --start-group/--end-group are not used).
>>> 
>>>  [*] Assuming linker behavior similar to ELF linkers
>> 
>> You can check unresolved symbols of the static library by creating a
>> unit test executable of PAL.
> 
> Actually, it enough just to avoid adding WebCore to include directories of 
> PAL, and code with layering violation won't compile.
> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> 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] WebCore/platform standalone library

[Myles C. Maxfield]

On Jan 10, 2017, at 9:28 PM, Darin Adler <da...@apple.com> wrote:

>> On Jan 10, 2017, at 9:24 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote:
>> 
>> We opted for WebCore to include files using “#include ” instead 
>> of just including Foo.h.
> 
> Will this work without ForwardingHeaders on macOS and iOS?

I think this requires more investigation to answer. 

> 
> Given that WTF chose , what is the reasoning for PAL choosing the 
> all capital ?

Beauty. Do you think this was a bad call?

> 
>> Similarly, we are putting symbols inside the PAL namespace, which is a child 
>> of the WebCore namespace. Therefore, inside WebCore, you use PAL things by 
>> specifying “PAL::Foo”.
> 
> Given that WebCore is built on top of PAL, it seems a little strange to put 
> PAL “inside” WebCore, but I guess OK.

Yeah, this was driven by the decision to make it a target rather than a 
project. Putting a target of a project outside the project itself seems worse 
than putting a dependency inside the project.

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

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

> On Jan 10, 2017, at 11:08 PM, Carlos Garcia Campos <carlo...@webkit.org> 
> wrote:
> 
>> El mar, 10-01-2017 a las 21:24 -0800, Myles C. Maxfield escribió:
>> After 18 months of no progress, Don Olmstead and I are getting the
>> band back together!
> 
> Great news. 
> 
>> We’ve uploaded a patch
>> to https://bugs.webkit.org/show_bug.cgi?id=143358 which incorporates
>> feedback from many different stakeholders (and as such, the direction
>> is a little different than where I was going with this in the
>> beginning).
>> 
>> First of all, this isn’t a new project; instead, it’s a new target
>> inside the WebCore project. The target creates a static library which
>> gets linked into WebCore, which means that the enforcement mechanism
>> can’t be done by the linker. Instead, the layering will be enforced
>> by a Python script, triggered as an extra build step, which checks
>> the symbol names inside the .a file as well as #include directives in
>> source code.
> 
> So, will it be possible to link to PAL but not the rest of WebCore?

Yes. This is the testing strategy. A goal is to be able to unit-test PAL 
without a layout test.

> 
>> We opted for WebCore to include files using “#include ”
>> instead of just including Foo.h. Similarly, we are putting symbols
>> inside the PAL namespace, which is a child of the WebCore namespace.
>> Therefore, inside WebCore, you use PAL things by specifying
>> “PAL::Foo”.
> 
> And WebCore::PAL::Foo when used outside WebCore namespace, right?

✅

> 
>> The first thing to move into PAL is the “crypto” subfolder, which is
>> a good candidate because it’s small, simple, yet also has platform-
>> dependent implementations.
>> 
>> We would love your feedback on this approach to help make the dream a
>> reality!
> 
> I'm not sure I agree with the approach because I don't know the reasons
> to make it a target inside WebCore, could you elaborate more on that,
> please?

Build systems are already very complicated; we want fewer projects, not more of 
them. Also there's so complexity with ForwardingHeaders, which I'd like to 
avoid. We can achieve our objectives in the most simple way possible; no 
project is necessary. If, one day, we want PAL to be promoted to a project, we 
can do that then.

> 
>> Thanks,
>> Myles and Don
>> 
>>> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclough@apple.c
>>> om> wrote:
>>> 
>>>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <m...@apple.com>
>>>> wrote:
>>>> 
>>>> Web Abstraction Toolbox (it’s hard to tell the difference between
>>>> wat and WTF sometimes…)
>>> 
>>> +1
>>> 
>>> 
>>> ___
>>> 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] WebCore/platform standalone library

[Myles C. Maxfield]

After 18 months of no progress, Don Olmstead and I are getting the band back 
together!

We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
 which incorporates feedback 
from many different stakeholders (and as such, the direction is a little 
different than where I was going with this in the beginning).

First of all, this isn’t a new project; instead, it’s a new target inside the 
WebCore project. The target creates a static library which gets linked into 
WebCore, which means that the enforcement mechanism can’t be done by the 
linker. Instead, the layering will be enforced by a Python script, triggered as 
an extra build step, which checks the symbol names inside the .a file as well 
as #include directives in source code.

We opted for WebCore to include files using “#include ” instead of 
just including Foo.h. Similarly, we are putting symbols inside the PAL 
namespace, which is a child of the WebCore namespace. Therefore, inside 
WebCore, you use PAL things by specifying “PAL::Foo”.

The first thing to move into PAL is the “crypto” subfolder, which is a good 
candidate because it’s small, simple, yet also has platform-dependent 
implementations.

We would love your feedback on this approach to help make the dream a reality!

Thanks,
Myles and Don

> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough  > wrote:
> 
>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak > > wrote:
>> 
>> Web Abstraction Toolbox (it’s hard to tell the difference between wat and 
>> WTF sometimes…)
> 
> +1
> 
> 
> ___
> 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] WebKit GPU rendering possibility

[Myles C. Maxfield]

> On Nov 3, 2016, at 12:34 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 03.11.2016, 22:18, "Rogovin, Kevin" <kevin.rogo...@intel.com 
> <mailto:kevin.rogo...@intel.com>>:
>> 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.
> 
> I would suggest you to do prototype implementation of GraphicsContext (e.g. 
> by replacing code in GraphicsContextCairo) and run those browser performance 
> benchmarks. If there is substantial improvement, there will be community 
> enthusiasm.
> 

As Konstantin says, browser-based benchmarks would be best, but I assumed you 
didn’t want to implement GraphicsContext before running benchmarks. If you do 
implement GraphicsContext in a branch of WebKit, there are a few browser-based 
performance tests which may be insightful:
CanvasMark http://www.kevs3d.co.uk/dev/canvasmark/ 
<http://www.kevs3d.co.uk/dev/canvasmark/>
Mozilla has a list of benchmarks https://wiki.mozilla.org/Benchmarks 
<https://wiki.mozilla.org/Benchmarks>
Canvas Performance Test http://www.smashcat.org/av/canvas_test/ 
<http://www.smashcat.org/av/canvas_test/>
Perhaps some of these could even be ported to native code so you could get up 
and running sooner.

—Myles

>> 
>> -Kevin
>> 
>> -Original Message-
>> From: mmaxfi...@apple.com [mailto:mmaxfi...@apple.com]
>> Sent: Thursday, November 3, 2016 9:07 PM
>> To: Rogovin, Kevin <kevin.rogo...@intel.com>
>> Cc: Carlos Garcia Campos <carlo...@webkit.org>; 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 <kevin.rogo...@intel.com> 
>>> 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 <kevin.rogo...@intel.com>; Myles C. Maxfield
>>>  <mmaxfi...@apple.com>
>>>  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
>>

Re: [webkit-dev] WebKit GPU rendering possibility

[Myles C. Maxfield]

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 <kevin.rogo...@intel.com> 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 <kevin.rogo...@intel.com>; Myles C. Maxfield 
> <mmaxfi...@apple.com>
> 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 <kevin.rogo...@intel.com>; 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) and ported that demo to Fast UI Draw, Cairo, Qt’s 
>>> QPainter and SKIA. The diffs between the ports is almost trivial (it 
>>> really is just using those different rendering API’s).
>> 
>> That makes me wonder, would it be possible to add a new cairo backend 
>> based on FastUIDraw? That would make very easy to try it out with the 
>> current GraphicsContext cairo backend.
>> 
>>> 3.  There are a few areas:
>>> a.  Reduce some render to offscreen buffers. When I worked

Re: [webkit-dev] WebKit GPU rendering possibility

[Myles C. Maxfield]

Hello,

This is certainly interesting work! I have a few questions about the approach 
of this renderer.

1. What API is this on top of? OpenGL? Metal? Vulkan? Raw GPU commands[1]?
2. You mention in your video that you have already migrated Cairo on top of 
your new tech. Traditionally, a web engine is divorced from a 2D rendering 
engine such as Cairo. Why can’t the ports of WebKit which use Cairo get this 
new tech without any change?
3. What sort of API changes do you have in mind to make GraphicsContext adopt?
4. Out of curiosity, does the renderer implement 3D transforms? Did you have to 
implement 3-D triangle subdivision along intersections (perhaps for 
order-independent transparency)?
5. Which algorithm did you choose to draw text?

Historically, the WebKit team has hesitated to allow experiments in the 
OpenSource repository. Traditionally, this sort of exploratory work is done in 
a branch, and only after it has proved to be an improvement, the work is 
adopted on trunk.

Thanks,
Myles

[1] https://01.org/linuxgraphics/documentation/hardware-specification-prms 


> On Nov 2, 2016, at 9:35 AM, Rogovin, Kevin  wrote:
> 
> Hi,
>  
> I was directed here by some colleagues as this is the place to post the 
> following to get started on the following proposal.
>  
> I have been working on an experimental 2D renderer that requires a GPU, the 
> project is open sourced on github at https://github.com/01org/fastuidraw 
> . I gave a talk at the X Developers 
> Conference this year which can be seen from 
> https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ 
>  .
>  
> I made a benchmark which makes heavy use of rotations and clipping and ported 
> to SKIA, Qt’s QPainter and Cairo. The benchmark and its ports are in the git 
> repo linked above under the branch with_ports_of_painter-cells. It's 
> performance advantage of FastUIDraw against the other renderers was quite 
> severe (against Cairo and Qt's QPainter over 9 times and against SKIA about 5 
> times faster).
>  
> I would like to explore the option of using FastUIDraw to implement a 
> WebCore::GraphicsContext backend for the purpose of making drawing faster and 
> more efficient on Intel devices that are equipped with a GPU. I also think 
> that some minor modifications to WebKit’s use of GraphicsContext will also 
> give some benefits. I have worked on WebKit a few years ago and knew/know my 
> way around the rendering code very well (atleast at that time).
>  
> Looking forward to collaboration,
> -Kevin Rogovin
>  
> ___
> 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] High web process CPU usage

[Myles C. Maxfield]

>  I figured I'd `clearInterval` all the timers


I assume you also stopped all the setTimeout() timers and the 
requestAnimationFrame() timers too?

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

Re: [webkit-dev] Rounded dots in dotted border

[Myles C. Maxfield]

I have interest in fixing this :)

(Unless you want to first, of course! Please go right ahead if you are thinking 
of fixing this)

--Myles

> On Jul 14, 2016, at 6:21 AM, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> Document [1] says defines "dotted" style as "a series of round dots", however 
> CG and Cairo implementations draw dots as squares.
> 
> Are there any plans to implement rounded dots?
> 
> 
> [1] https://www.w3.org/TR/css3-background/#border-style
> 
> -
> 
> P.S. Some context in case anyone is interested:
> 
> I was rewriting drawLine() implementation in Qt port which was broken by 
> r177686 (remember skewed border in Bugzilla with Cairo? That thing), and 
> found that implementations of drawLine() share the same logic and differ in 
> minor details only. However, out old code was drawing rounded dots, and I 
> feel it would be more appropriate to implement this logic in shared code, or 
> drop it completely if other ports are not planning to do this.
> 
> -- 
> 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] migrating from webkitgtk-1.0 to webkit2gtk

[Myles C. Maxfield]

Hello,
This list is for the development of WebKit itself. You are probably looking for 
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Thanks,
Myles

> On Jun 30, 2016, at 5:12 PM, Herminio Hernandez Jr 
>  wrote:
> 
> Hello,
> 
> I am in the process to migrating a web browser named luakit from 
> webkitgtk-1.0 to webkit2gtk. I am wondering if there is any documentation 
> about migrating.
> 
> I am already looking over the documentation at webkitgtk.org and also working 
> on how to best migrate the code. Any advice would be appreciated.
> 
> Thanks
> Herminio
> ___
> 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] getComputedStyle does not handle over-constrained properties correctly

[Myles C. Maxfield]

The spec has been updated.

https://github.com/w3c/csswg-drafts/commit/c996510d75544786a5361127e69c71a5fc725785

—Myles
> On Jun 20, 2016, at 2:26 PM, Myles C. Maxfield <mmaxfi...@apple.com> wrote:
> 
> All stable and nightly browsers that I could find[1] agree on the return of 
> getComputedStyle() in this situation. Therefore, I opened this issue[2] to 
> update the spec to match the implementations.
> 
> —Myles
> 
> [1] - Microsoft Edge 25.10586.0.0 / Microsoft EdgeHTML 13.10586
> - Firefox 50.0a1 (2016-06-20)
> - Firefox 47.0
> - Chrome 53.0.2773.0 canary
> - Chrome 51.0.2704.103
> - Safari 9.1.1
> - WebKit r202242
> 
> [2] https://github.com/w3c/csswg-drafts/issues/203 
> <https://github.com/w3c/csswg-drafts/issues/203>
> 
>> On Jun 16, 2016, at 7:38 AM, Deokjin Kim <dj0...@gmail.com 
>> <mailto:dj0...@gmail.com>> wrote:
>> 
>> Hello,
>> 
>> I asked this issue and W3C WG said that it means "used value". 
>> (https://github.com/w3c/csswg-drafts/issues/190 
>> <https://github.com/w3c/csswg-drafts/issues/190>)
>> 
>> When I checked spec for getComputedStyle(), some properties('bottom', 
>> 'left', 'right', 'top')'s resolved value is the used value if the property 
>> applies to a positioned element. 
>> (https://drafts.csswg.org/cssom/#resolved-values 
>> <https://drafts.csswg.org/cssom/#resolved-values>)
>> 
>> Therefore, I think my 
>> implementation(https://bugs.chromium.org/p/chromium/issues/detail?id=601118 
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=601118>) is correct. 
>> In this test case(http://jsfiddle.net/xu5b7rLq/6/ 
>> <http://jsfiddle.net/xu5b7rLq/6/>), bottom and right should be negative.
>> 
>> What do you think about this issue?
>> 
>> Thank you,
>> Deokjin Kim
>> 
>> 2016-06-01 15:03 GMT+09:00 Myles C. Maxfield <mmaxfi...@apple.com 
>> <mailto:mmaxfi...@apple.com>>:
>> It looks like WebKit visually renders the result correctly according to the 
>> spec text. Therefore, we are only interested here with the computed style of 
>> the over-specified element.
>> 
>> The spec text uses the verb “becomes.” I don’t know if this means that 
>> either 1) the rendering and the computed style should reflect this, or 2) 
>> just the rendering should reflect this.
>> 
>> Do you know if this issue has been discussed in the W3C?
>> 
>> Thanks,
>> Myles
>>> On May 27, 2016, at 5:59 AM, 김덕진 <dj0...@gmail.com 
>>> <mailto:dj0...@gmail.com>> wrote:
>>> 
>>> Hello, 
>>> 
>>> I'm working on blink engine as deokjin81@samsung.com 
>>> <mailto:deokjin81@samsung.com>.
>>> And I have a question about implementation plan for getComputedStyle.
>>> As I know, getComputedStyle does not handle over-constrained properties 
>>> correctly.
>>> So I implemented 
>>> it(https://bugs.chromium.org/p/chromium/issues/detail?id=601118 
>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=601118>) according 
>>> to 
>>> spec(https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning
>>>  
>>> <https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning>)
>>>  on blink engine.
>>> 
>>> Below paragraphs(from spec) describe detail operation to handle 
>>> over-constrained properties.
>>> 
>>> If neither 'left' nor 'right' is 'auto', the position is over-constrained, 
>>> and one of them has to be ignored. If the 'direction' property of the 
>>> containing block is 'ltr', the value of 'left' wins and 'right' becomes 
>>> -'left'. If 'direction' of the containing block is 'rtl', 'right' wins and 
>>> 'left' is ignored.
>>> 
>>> The 'top' and 'bottom' properties move relatively positioned element(s) up 
>>> or down without changing their size. 'Top' moves the boxes down, and 
>>> 'bottom' moves them up. Since boxes are not split or stretched as a result 
>>> of 'top' or 'bottom', the used values are always: top = -bottom. If both 
>>> are 'auto', their used values are both '0'. If one of them is 'auto', it 
>>> becomes the negative of the other. If neither is 'auto', 'bottom' is 
>>> ignored (i.e., the used value of 'bottom' will be minus the value of 'top').
>>> 
>>> I would like to know Webkit  have any plan for this.
>>> 
>>> Thank you in advance,
>>> Deokjin Kim
>>> 
>>> 
>>> 
>>> ___
>>> 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] getComputedStyle does not handle over-constrained properties correctly

[Myles C. Maxfield]

All stable and nightly browsers that I could find[1] agree on the return of 
getComputedStyle() in this situation. Therefore, I opened this issue[2] to 
update the spec to match the implementations.

—Myles

[1] - Microsoft Edge 25.10586.0.0 / Microsoft EdgeHTML 13.10586
- Firefox 50.0a1 (2016-06-20)
- Firefox 47.0
- Chrome 53.0.2773.0 canary
- Chrome 51.0.2704.103
- Safari 9.1.1
- WebKit r202242

[2] https://github.com/w3c/csswg-drafts/issues/203 
<https://github.com/w3c/csswg-drafts/issues/203>

> On Jun 16, 2016, at 7:38 AM, Deokjin Kim <dj0...@gmail.com> wrote:
> 
> Hello,
> 
> I asked this issue and W3C WG said that it means "used value". 
> (https://github.com/w3c/csswg-drafts/issues/190 
> <https://github.com/w3c/csswg-drafts/issues/190>)
> 
> When I checked spec for getComputedStyle(), some properties('bottom', 'left', 
> 'right', 'top')'s resolved value is the used value if the property applies to 
> a positioned element. (https://drafts.csswg.org/cssom/#resolved-values 
> <https://drafts.csswg.org/cssom/#resolved-values>)
> 
> Therefore, I think my 
> implementation(https://bugs.chromium.org/p/chromium/issues/detail?id=601118 
> <https://bugs.chromium.org/p/chromium/issues/detail?id=601118>) is correct. 
> In this test case(http://jsfiddle.net/xu5b7rLq/6/ 
> <http://jsfiddle.net/xu5b7rLq/6/>), bottom and right should be negative.
> 
> What do you think about this issue?
> 
> Thank you,
> Deokjin Kim
> 
> 2016-06-01 15:03 GMT+09:00 Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>>:
> It looks like WebKit visually renders the result correctly according to the 
> spec text. Therefore, we are only interested here with the computed style of 
> the over-specified element.
> 
> The spec text uses the verb “becomes.” I don’t know if this means that either 
> 1) the rendering and the computed style should reflect this, or 2) just the 
> rendering should reflect this.
> 
> Do you know if this issue has been discussed in the W3C?
> 
> Thanks,
> Myles
>> On May 27, 2016, at 5:59 AM, 김덕진 <dj0...@gmail.com 
>> <mailto:dj0...@gmail.com>> wrote:
>> 
>> Hello, 
>> 
>> I'm working on blink engine as deokjin81@samsung.com 
>> <mailto:deokjin81@samsung.com>.
>> And I have a question about implementation plan for getComputedStyle.
>> As I know, getComputedStyle does not handle over-constrained properties 
>> correctly.
>> So I implemented 
>> it(https://bugs.chromium.org/p/chromium/issues/detail?id=601118 
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=601118>) according to 
>> spec(https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning
>>  
>> <https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning>)
>>  on blink engine.
>> 
>> Below paragraphs(from spec) describe detail operation to handle 
>> over-constrained properties.
>> 
>> If neither 'left' nor 'right' is 'auto', the position is over-constrained, 
>> and one of them has to be ignored. If the 'direction' property of the 
>> containing block is 'ltr', the value of 'left' wins and 'right' becomes 
>> -'left'. If 'direction' of the containing block is 'rtl', 'right' wins and 
>> 'left' is ignored.
>> 
>> The 'top' and 'bottom' properties move relatively positioned element(s) up 
>> or down without changing their size. 'Top' moves the boxes down, and 
>> 'bottom' moves them up. Since boxes are not split or stretched as a result 
>> of 'top' or 'bottom', the used values are always: top = -bottom. If both are 
>> 'auto', their used values are both '0'. If one of them is 'auto', it becomes 
>> the negative of the other. If neither is 'auto', 'bottom' is ignored (i.e., 
>> the used value of 'bottom' will be minus the value of 'top').
>> 
>> I would like to know Webkit  have any plan for this.
>> 
>> Thank you in advance,
>> Deokjin Kim
>> 
>> 
>> 
>> ___
>> 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] WebKit render tree

[Myles C. Maxfield]

From the description, it sounds like you have some native code which needs to 
be able to modify the DOM and you need events from the DOM to be able to call 
code from your library. You can do this today without modifying WebKit.

The way for native code to modify the DOM is for the native code to generate a 
JavaScript string and submit the string to be run inside the JavaScript context 
of the page. You can do this in WK1 by JSEvaluateScript(), the WebScriptObject, 
or by stringByEvaluatingJavaScriptFromString. In WebKit2, WKWebView has a 
method evaluateJavaScript (Or from C you can run 
WKPageRunJavaScriptInMainFrame, but this isn’t considered API)

You can also use Objective-C DOM bindings to manipulate the DOM directly from 
native code, this approach is discouraged.

One way for DOM events to call code from your library is to create a JavaScript 
object or method which is backed by native code. Then, the JavaScript event 
handler can call the functions on this object, which causes your native code to 
run. This can be done with the functions listed inside 
Source/JavaScriptCore/API/JSObjectRef.h.

In WebKit2, this native-backed-object can still be made, but it must be done 
inside the Web process (not the UI process), and therefore must be done with 
the InjectedBundle. Inside the InjectedBundle, you can run native code in the 
web process, and there are facilities to send messages between the Web process 
& UI process. You can find out more if you search for “InjectedBundle” inside 
Source/WebKit2/UIProcess/API. Note, however, that use of the InjectedBundle is 
not considered API.

We rely on the above mechanisms heavily in our testing infrastructure. Our 
Tools/DumpRenderTree and Tools/WebKitTestRunner projects use the techniques 
described above.

The Windows port currently doesn’t support WebKit2, so you’ll have to use the 
WebKit1 approach on Windows.


> On Jun 1, 2016, at 11:49 AM, Andy Somogyi <somog...@umail.iu.edu> wrote:
> 
> 
>> On Jun 1, 2016, at 1:37 PM, Myles C. Maxfield <mmaxfi...@apple.com 
>> <mailto:mmaxfi...@apple.com>> wrote:
>> 
>> Replies inline.
> 
>> Generating a DOM is usually done in JavaScript. I'm curious about the 
>> problem you are trying to solve where JavaScript is not sufficient.
>> 
>> Drawing into an existing window is usually done by inserting a WebView into 
>> the view 
>> reallyhierarchy of the window. Yet again, I'm interested in why this is not 
>> sufficient.
> 
> I have the source code of the new language, and a parser/compiler for it 
> written in C++. I’d hate to have to introduce a new set of languages into the 
> mix. 
> 
> The new programming language is designed to be visually edited, hence the 
> need for hit detection. So, a component may be dragged from one region to 
> another. This would trigger an event which would cause one branch of the AST 
> to be pruned, modified and re-attached to another branch. This in turn would 
> trigger a re-gen of the render tree, and eventually a repaint. I've done 
> something very similar in the past where I created a visual computer algebra 
> system. The entire runtime, including AST are written in C++, and it would be 
> nice to connect it to an existing rendering/layout engine, and be able to 
> respond to user events directly in my C++ code. 
> 
> I see this as a very dynamic application, and all of the internal logic which 
> is a mix of C and JIT compiled code from the new language needs to interact 
> with both the visual representation, and the physics engine (the Lang is 
> designed for real-time physics simulation). Ideally, I'd like to be able to 
> render a visual representation of a language element to an OpenGL texture, 
> and have this exist in the physics engine. 
> 
> However, being as the DOM is publicly available from WebKit in C++ (I think 
> they’re all exposed publicly as pure virtual interfaces), it would be 
> relatively straightforward for me to to compile the new language to target 
> the C++ v-table ABI. 
> 
> 
>>> Do you think this would be possible using WebCore as a library and have 
>>> these custom render tree / dom tree derived objects live in my own library 
>>> (this is really, really the way I’d prefer to do things), or do you think 
>>> it would be better to add these objects directly into the WebCore library. 
>>> 
>> 
>> Are you planning on committing any changes to trunk?
>> 
>> Of course it is ::possible:: to do something like this - it's all software. 
>> Are you asking if it's easy to do it? Or the best way to do it
> 
> On OSX, I don’t think I’ll have to do any changes at all to WebKit. I’ve got 
> proof of concept working where I create a new RenderElement derived object, 
> and give it a new Gr

Re: [webkit-dev] WebKit render tree

[Myles C. Maxfield]

Replies inline.

> On May 31, 2016, at 11:19 PM, Andy Somogyi  wrote:
> 
> Hi,
> 
> I’m a programming language researcher, and we are working on a new visual 
> programming language. 
> 
> I’m investigating using WebCore as the rendering component of our language 
> editing/visualization system. 
> 
> Essentially what I’d like to be able to do is to programmatically (C++) 
> generate 1: a DOM tree of a new family of Element derived object, 2: 
> rendering tree, 3: layout the tree, 4: attach a GraphicsContext to an 
> existing window or bitmapped resource, and 5: use WebCore’s GraphicsContext 
> to render the custom rendering tree. I’d also like to create a family of 
> custom Element derived objects that would be attached to the rendering tree 
> and use the rendering tree. I’d also like to respond to the standard events, 
> i.e. mouse, keyboard, etc…

Generating a DOM is usually done in JavaScript. I'm curious about the problem 
you are trying to solve where JavaScript is not sufficient.

Drawing into an existing window is usually done by inserting a WebView into the 
view hierarchy of the window. Yet again, I'm interested in why this is not 
sufficient.

> 
> Do you think this would be possible using WebCore as a library and have these 
> custom render tree / dom tree derived objects live in my own library (this is 
> really, really the way I’d prefer to do things), or do you think it would be 
> better to add these objects directly into the WebCore library. 
> 

Are you planning on committing any changes to trunk?

Of course it is ::possible:: to do something like this - it's all software. Are 
you asking if it's easy to do it? Or the best way to do it?

> I don’t think accessing any of the render tree objects in webcore would cause 
> any issues on Mac/Unix, however, Windows sadly requires those EXPORT macros 
> on each class def. If I added these, what would be the WebKit policy of 
> accepting these changes? 
> 
> What is the, for lack of a better word, the “viability” of WebKit on Windows? 
> Our project fundamentally has to be cross-platform, and currently, I’m not 
> aware of any webkit based browsers on Windows. I’m currently looking into 
> using webkit, firefox or blink. I’ve essentially eliminated blink because 
> their code is very hard to follow, much harder than webkit or firefox, and I 
> think the webkit code is the easiest to understand and use. Webkit is 
> currently my first choice, but my only hesitation is will webkit continued to 
> be supported on Windows. 

Windows is an official port, just like iOS / Mac / EFL / GTK.

> 
> thanks
> 
> -- Andy Somogyi PhD
> School of Informatics and Computing
> Indiana University
> ___
> 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] getComputedStyle does not handle over-constrained properties correctly

[Myles C. Maxfield]

It looks like WebKit visually renders the result correctly according to the 
spec text. Therefore, we are only interested here with the computed style of 
the over-specified element.

The spec text uses the verb “becomes.” I don’t know if this means that either 
1) the rendering and the computed style should reflect this, or 2) just the 
rendering should reflect this.

Do you know if this issue has been discussed in the W3C?

Thanks,
Myles
> On May 27, 2016, at 5:59 AM, 김덕진  wrote:
> 
> Hello, 
> 
> I'm working on blink engine as deokjin81@samsung.com 
> .
> And I have a question about implementation plan for getComputedStyle.
> As I know, getComputedStyle does not handle over-constrained properties 
> correctly.
> So I implemented 
> it(https://bugs.chromium.org/p/chromium/issues/detail?id=601118 
> ) according to 
> spec(https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#relative-positioning
>  
> )
>  on blink engine.
> 
> Below paragraphs(from spec) describe detail operation to handle 
> over-constrained properties.
> 
> If neither 'left' nor 'right' is 'auto', the position is over-constrained, 
> and one of them has to be ignored. If the 'direction' property of the 
> containing block is 'ltr', the value of 'left' wins and 'right' becomes 
> -'left'. If 'direction' of the containing block is 'rtl', 'right' wins and 
> 'left' is ignored.
> 
> The 'top' and 'bottom' properties move relatively positioned element(s) up or 
> down without changing their size. 'Top' moves the boxes down, and 'bottom' 
> moves them up. Since boxes are not split or stretched as a result of 'top' or 
> 'bottom', the used values are always: top = -bottom. If both are 'auto', 
> their used values are both '0'. If one of them is 'auto', it becomes the 
> negative of the other. If neither is 'auto', 'bottom' is ignored (i.e., the 
> used value of 'bottom' will be minus the value of 'top').
> 
> I would like to know Webkit  have any plan for this.
> 
> Thank you in advance,
> Deokjin Kim
> 
> 
> 
> ___
> 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] Event listeners of the same type in DOM Level 0 event handling,

[Myles C. Maxfield]

Given that both Mozilla Firefox and Microsoft Edge both agree with WebKit, it 
is unlikely we would accept a change to this behavior.

—Myles

> On May 10, 2016, at 7:31 PM, jongdeok.kim  wrote:
> 
> Hi Everyone,
>  
> A web page that I'm testing with webkit, uses two event listeners about load 
> event.
> It registered those by assigning to window.onload and setting as an 'onload' 
> attribute of body element.
>  
> On webkit, last registered one replaces previous one, in this case 'onload' 
> attribute wins.
> I checked other browsers, but only chrome permits two listeners on same event 
> type.
>  
> I googled and found out that it's DOM Level 0 event handling.
> And I'm wondering this is a webkit bug when using a mix of traditional model 
> and inline model (as referred to below), or implementor dependent.
>  
> https://en.wikipedia.org/wiki/DOM_events#DOM_Level_0 
>  
>  
>  
>  
> onloadload 
>  
> function load() {
> alert("body.onload");
> }
> window.onload = function () { // traditional model
> alert("window.onload");
> };
>  
>  
>  
> onload. 
>  
>  
>  
> Thanks in advance.
> jongdeok.
>  
> ___
> 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] Fonts for WebKit tests on OS X?

[Myles C. Maxfield]

Replies inline.
> On Mar 11, 2016, at 1:50 PM, Frédéric WANG <fred.w...@free.fr> wrote:
> 
> Le 11/03/2016 22:12, Myles C. Maxfield a écrit :
>> Just to clarify: you want tests to use some specific fonts, but don’t
>> want to check the fonts into the repository?
> Yes. To test some specific OpenType MATH feature we already use our own
> small fonts (a few kilobytes) loaded as Web fonts. However, for all the
> other tests with real math fonts (where we want to get reliable
> rendering and independent of which of these math fonts are installed or
> not), it's not clear whether the license (compatibility with WebKit's?)
> or the size (several hundreds of kilobytes) make that
> possible/judicious. For WebKitGTK+ we have the separate repository of
> fonts [3] mentioned in my previous mail that ensures Latin Modern Math
> is available when running GTK tests.
>> The downside to 1 is that it adds a new (non-obvious) step that all
>> developers will have to perform every time they install a new
>> operating system (in addition to any time we bring up a new buildbot).
>> I would object to making the development environment even more
>> complicated than it already is.
> I agree with that. I'd just like to note that:
> 
> a) From my experience, installing user font in the Apple Font Book does
> not even seem enough. For some reason, only the pre-installed font are
> used when running tests…

This is because we whitelist an explicit list of fonts which the tests are 
allowed to use. We don’t want tests to start failing just because the user has 
some unexpected font installed on their system.

See allowedFontFamilySet() in Tools/DumpRenderTree/mac/DumpRenderTree.mm, 
Tools/WebKitTestRunner/InjectedBundle/cocoa/ActivateFontsCocoa.mm, and 
Tools/WebKitTestRunner/mac/TestControllerMac.mm

> 
> b) As said above, WebKitGTK+ has a special mechanism to setup a jhbuild
> environment and automate installation of dependencies ; I was wondering
> if something similar exists for the Apple ports, but apparently that's
> not the case...
> 
>> I’m not sure if I’m allowed to publicly discuss my opinions about 2
>> (since it is technically an internal matter) but I would expect its
>> success to be dubious.
> Yes, I expected that. However, some years ago Apple accepted to install
> the STIX font version 1.0. So I was hoping that maybe an upgrade to
> version 2 when it is released would not be asking too much... at least
> compared to the burden of managing a jhbuild-like mechanism in Apple
> ports or bundling big fonts into the repo...
> 
>> Given this, I think the best solution is to check the fonts into the
>> repository. Layout tests could target these as web fonts using
>> @font-face, or they could use the same mechanism that we use for
>> WebKitWeightWatcher (which is a font) to view the font as if it is
>> preinstalled (without actually preinstalling it). 
> Can you elaborate on what is done for WebKitWeightWatcher?

We call CTFontManagerRegisterFontsForURLs(… kCTFontManasgerScopeProcess …) to 
make the fonts look like they are installed for just the local process.

On iOS, we use the -sectcreate linker flag to place the font data directly 
inside the DumpRenderTree binary. We then create an in-memory CGFontRef backed 
by these bytes (the loader will put them in memory for us at process creation) 
we use CTFontManagerRegisterGraphicsFont() to make it look like it is 
installed. See activateTestingFonts() and activateFontIOS() in 
Tools/DumpRenderTree/mac/DumpRenderTree.mm.

> 
> Thanks,
> 
> Frédéric
> 

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

Re: [webkit-dev] Fonts for WebKit tests on OS X?

[Myles C. Maxfield]

Replies inline.
> On Mar 11, 2016, at 6:30 AM, Frédéric WANG  wrote:
> 
> *TL;DR: Can you please indicate how to add fonts to use for WebKit tests
> on OS X? This is is needed for existing and future MathML tests (and
> actually pre-installing them on Mac/iOS would improve user experience).*
> 
> Dear all,
> 
> In the context of the MathML refactoring [1], I've recently been
> reviewing test results on OS X. Unfortunately, many of existing tests or
> tests that will be added by the current set of MathML refactoring
> patches require a math font with an OpenType MATH table to work
> properly. This is not the case of the obsolete STIXGeneral font families
> that have been installed by default since OS X Lion [2]. Hence for now
> those tests are just skipped or have incorrect text/PNG expectations. As
> a comparison, the GTK port uses the Latin Modern Math font to ensure
> consistent results [3].
> 
> I'm attaching a simple test-fonts.html page and I'm providing the
> screenshots obtained when I use run-safari or run-webkit-tests with a
> WebKit build integrating the MathML refactoring patches. From this
> experiment, it seems that run-webkit-tests only use the pre-installed
> system fonts (STIXGeneral) but not the fonts I installed manually on my
> Mac. However, the latter are correctly selected with run-safari and then
> you can see that the rendering of math equations is much better and
> closer to the TeX references from the MathML torture test [4].
> 
> So my question: is there a way to ensure that WebKit tests are executed
> with specific fonts on OS X without polluting the WebKit repo with big
> math Web fonts?

Just to clarify: you want tests to use some specific fonts, but don’t want to 
check the fonts into the repository?

I can only think of two ways to do this:
1. Require anyone who wants to run layout tests to install a handful of fonts. 
Ask the user to download them from a known place. This is currently how the 
Apple Windows port works.
2. Petition for the fonts to be preinstalled on all future releases of OS X, 
and mark the tests as expected to fail on all current versions of OS X.

Both of these options have huge downsides. The downside to 1 is that it adds a 
new (non-obvious) step that all developers will have to perform every time they 
install a new operating system (in addition to any time we bring up a new 
buildbot). I would object to making the development environment even more 
complicated than it already is.

I’m not sure if I’m allowed to publicly discuss my opinions about 2 (since it 
is technically an internal matter) but I would expect its success to be dubious.

Given this, I think the best solution is to check the fonts into the 
repository. Layout tests could target these as web fonts using @font-face, or 
they could use the same mechanism that we use for WebKitWeightWatcher (which is 
a font) to view the font as if it is preinstalled (without actually 
preinstalling it).

> 
> If the solution is to have these math fonts pre-installed on OS X, then
> that would also be great to enhance Safari user experience, as shown by
> the attached screenshots. In that case, this is probably not the
> business of WebKit developers but I'd like to suggest two math fonts
> (also reported to Apple some years ago as problems number 16841023 and
> 17021145):
> 
> 1) STIX Math [5], which has very good coverage for unicode symbols, is
> supported by some tech companies, is released under SIL OFL and is the
> next version of the STIXGeneral font families currently pre-installed on
> OS X. Unfortunately the current 1.1 release has too many bugs and so is
> not really usable for math layout, but version 2 will solve them and is
> claimed to be released "soon".
> 
> 2) Latin Modern Math [6], which has the Computer Modern style used by
> default by TeX rendering engines and is used for WebKitGTK+ tests. This
> font uses the LaTeX Project Public License + a Reserved Font Name clause
> but the authors expressed their will to release it under SIL OFL, if
> that can help.
> 
> Thank you,
> 
> Frédéric
> 
> [1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html
> [2] https://bugs.webkit.org/show_bug.cgi?id=41961
> [3] https://github.com/mrobinson/webkitgtk-test-fonts
> [4]
> https://developer.mozilla.org/en-US/docs/Mozilla_MathML_Project/MathML_Torture_Test
> [5] http://stixfonts.org/
> [6] http://www.gust.org.pl/projects/e-foundry/lm-math
> 
> ___
> 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 enable the SVG -> OTF Font Converter on your port!

[Myles C. Maxfield]

Hello!

As of r197145, the SVG -> OTF Font Converter is enabled on the OS X, iOS, and 
Apple Windows ports. This converter replaces our old, invasive, error-prone, 
and security-hole-ridden SVG font support in WebKit. The converter is much 
faster (read: at least 3 orders of magnitude) and produces much better results 
(subpixel-antialiased text) than the old code path, as well as having 
significantly fewer security vulnerabilities.

As soon as we get all the ports on the converter, I’d love to be able to delete 
all the old code. However, GTK and EFL are still using the old code path. 
Turning the converter on should be simple: I’ve posted patches for GTK [1] and 
EFL [2] to flip the switch. Note that some tests may need to be rebaselined; 
the underlying graphics system will likely provide differently quantized glyph 
metrics than the existing code path. There are also some known bugs; if you 
want to learn more about them, please feel free to reach out to me.

Please reply by Tuesday, March 15 so I can go ahead with this project!

Thanks!

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

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


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

Re: [webkit-dev] Building Webkit on Windows

[Myles C. Maxfield]

What is the error you are seeing?

> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu  wrote:
> 
> Hello ,
> I am trying to build webkit on Windows .
> I am following  steps from https://webkit.org/building-webkit-on-windows/
> However I am unable to find a way to build webkit using MSVS2015 or  Cygwin .
> Can anyone guide here please?
> regards
> RSadhu
> ___
> 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] MathML layout refactor proposal

[Myles C. Maxfield]

I can't comment for the rest of the team, but I am very excited to see this! 

-- Myles

> On Dec 9, 2015, at 3:35 AM, Alejandro Garcia Castro  wrote:
> 
> 
> Hi,
> 
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
> 
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
> 
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
> 
>   - Reduce code complexity: Adapting FlexBox layout (which is already
> complex) in order to create the MahtML layout made the code too
> complex, a big technical debt that made the improvement of MathML
> more difficult every day.
> 
>   - Avoid just another FlexBox dependent code: When we had to add
> general layout alignment support we had a lot of problems trying
> to solve some the MathML issues because it was not clear how it
> worked with the FlexBox.
> 
>   - Improve performance: We do not need all the features FlexBox
> layout adds for most of the MathML blocks but we are executing
> all that code. We also can simplify the render tree structures
> that were created to make the FlexBox layout work.
> 
>   - Make easier to improve the MathML implementation: Using
> independent renderer classes gives more flexibility to get exact
> positioning and spacing required to get high-quality math
> rendering based on TeX rules and the OpenType MATH table.  (cf
> http://www.mathml-association.org/MathMLinHTML5/)
> 
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
> 
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
> 
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
> 
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>   keep the RenderTree structure. This is basically done, and we just
>   need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>   created to make FlexBox work and all the code that it was
>   required. We already have the Fractions and Underover implemented
>   and the code is much clearer. This will break the tests relying on
>   a PNG image or a render tree reference. Hence we will do it also
>   per renderer and rebasing the tests after each commit.
> 
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
> 
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
> 
> Greetings,
> 
> Alex
> ___
> 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] How to deal with 1-pixel differences in reftests ?

[Myles C. Maxfield]

I believe that any way to specify fuzziness should not treat the following 
cases the same:

- 1 pixel being 100% wrong
- All pixels being 1% wrong

There are certain cases where one of those should cause a failure, but the 
other shouldn't.

--Myles
> On Nov 18, 2015, at 10:44 PM, Alexey Proskuryakov  wrote:
> 
> 
>> 18 нояб. 2015 г., в 11:50, Simon Fraser > > написал(а):
>> 
>> There are some well-understood reasons why a test might not exactly match 
>> its reference. One is that the test uses compositing layers to do clipping, 
>> but the reference just clips with drawing, and these are not expected to 
>> give a pixel-perfect match.
>> 
>> I proposed a way to allow a test to specify a custom tolerance in 
>> https://bugs.webkit.org/show_bug.cgi?id=149828 
>> . If we had this, it would 
>> allow me to fix 142258  and 
>> 146523 .
> 
> Bug 142258 also serves as an example for why we shouldn't do this. Both known 
> reasons for it are actual bugs that needed to be discovered, and need to be 
> fixed.
> 
> What are the causes for flakiness in bug 146523?
> 
> - Alexey
> 
> ___
> 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] Memory leak tracking in WebKit

[Myles C. Maxfield]

I've got a few questions/statements about this:

1. What makes you think that CSSParser::parseFontFaceSource() is the culprit? 
Which memory instrumentation tools are you using?
2. Font::platformInit() is the function where we start populating all our 
internal font caches. For example, we start creating and populating GlyphPages 
here. It makes sense that it should allocate some memory.
3. Platform fonts are quite heavyweight objects; I would expect these to cost 
more than the work being done in Font::platformInit(). These are allocated in 
FontCache::createFontPlatformData().

If you are able; it might be insightful to take a stack snapshot at every 
memory allocation and aggregate based on the allocation size and the top few 
frames of the stack. With this information, we can try to figure out what the 
memory is being used for, and where it should be released. Then we could try to 
debug why it isn't being released.

> On Nov 30, 2015, at 5:10 PM, Vienneau, Christopher  wrote:
> 
> Hi,
>  
> I’ve still been tracking memory leaks in our application, and I think I have 
> a good test scenario to share. 
>  
> In our application we found that a lot of memory would be held onto when 
> visiting this particular site:
> http://answers.ea.com 
> In a loop we visit this site, and a simple html page that consists of a list 
> of test urls found on the local hard drive.
> Our in built memory tools suggest a leak is coming largely from  
> CSSParser::parseFontFaceSrc(), though admittedly I’ve changed my top suspects 
> from time to time.  I think this item is showing as a large leak due to the 
> inclusion of the font in the css on the answers.ea.com 
>  page, but perhaps there are more smaller items being 
> leaked which is just less obvious (the font is large).
>  
> I’ve reproduce the scenario in the WinCairo test application, based on 
> 188436.  I built in a quick and hacky soak mechanism to conduct the test, 
> perhaps there are better tools I’m not aware of.  I’ve attached the source 
> changes to this mail:
> Source/WebKit/win/WebKitMessageLoop.cpp
> Tools/WinLauncher/Common.cpp
>  
> I can see the memory of the WinLauncher process grow over time, here is an 
> example of the memory usage as seen from the windows task manager over time:
> DurationMemory (reported by windows)
> 0m  155MB
> 13m   178MB
> 23m   199MB
> 36m   219MB  
> 53m   247MB
> 1h4m 259MB
> 1h23m  277MB
> After about an 1h30m, WinLauncher crashes, at the end of the mail is the 
> basic debug data that was available. 
>  
> I’m not sure if the crash is related to the memory leak I’m experiencing, or 
> if it’s an unrelated issue.  Since we’re a few months older from tip I’m 
> wondering if anyone has any recent insights to share on this memory leak 
> scenario? I haven’t identified anything in the change logs, but perhaps there 
> is there something already addressing this?  Does the same issue occur at tip?
>  
> Any feedback is appreciated,
>  
> Thanks
>  
> Chris Vienneau
>  
>  
>  
>  
> + this 0x784be130 
> {m_fontMetrics={m_unitsPerEm=1000 m_ascent=0.0 m_descent=0.0 
> ...} ...} WebCore::Font *
> ascent   0.0   float
> dc   Variable is optimized away and 
> not available. 
> + extents {x_bearing=0.0 
> y_bearing=2.840573810841e-316#DEN width=1.197610077640e-309#DEN ...} 
> cairo_text_extents_t
> metricsMultiplier 
> 0.031250  const double
> faceName   Variable is optimized away 
> and not available. 
> descent52852716.0  
> float
> xHeight Variable is optimized away and not 
> available. 
> + textMetrics{tmHeight=0 tmAscent=0 
> tmDescent=1691286912 ...} tagTEXTMETRICW
> lineGap 63069964.0  float
> scaledFont  0x6477fc00 {...}  
>  _cairo_scaled_font *
> faceLength 0  int
>  
>  
> > WebKit.dll!WebCore::Font::platformInit() Line 82 C++
>WebKit.dll!WebCore::Font::Font(const WebCore::FontPlatformData 
> & platformData, bool isCustomFont, bool isLoading, bool 
> isTextOrientationFallback) Line 80   C++
>WebKit.dll!WebCore::CachedFont::createFont(const 
> WebCore::FontDescription & fontDescription, const WTF::AtomicString & 
> __formal, bool syntheticBold, bool syntheticItalic, bool __formal) Line 126   

Re: [webkit-dev] OSX: Linking to custom build resorts to system version...

[Myles C. Maxfield]

> On Nov 11, 2015, at 2:06 AM, Nikolay Tsenkov  wrote:
> 
> Hello,
> 
> First of all, thanks for the awesome OSS software that WebKit is!
> 
> I need some help with linking to a fresh build of WebKit.framework on OS X:
>  - I am building a modified version of WebKit.framework (my changes are in 
> WebCore and WebKit projects) on OS X 10.11, but I am not able to use that 
> framework in another project - somehow the project always resorts to the 
> default system WebKit.framework.
> 
> Setup:
>  - OS X 10.11.0 (just saw there is 10.11.1 available, but haven’t installed 
> it yet)
>  - System Integrity Protection (SIP) disabled (I couldn’t build when ON)

Do the nightly builds appear to use the system version? Maybe there was a 
problem with this step.

> 
> Changes:
>  - (Gist) I am making a version of the WebView (the legacy one, the 
> single-process model) which can be used in DAW plugin, exposing API for 
> rendering the audio, settings the sampling rate, not rendering to the audio 
> hardware directly, etc.
>  - (Specific)
>- (WebCore) -Replaced- AudioDestinationMac with AudioDestinationDaw;
>- (WebCore) -Add- DawStateSingleton which exposes the custom 
> destination node to the WebView;
>- (WebKit) -Modify- WebView to include a new constructor and couple of 
> new methods:
> - (instancetype)initWithFrame:(NSRect)frame samplingRate:(float)samplingRate 
> frameName:(NSString *)frameName groupName:(NSString *)groupName;
> - (void)setDawSamplingRate:(float)samplingRate;
> - (void)renderAudio:(int) numberOfFrames bufferList:(AudioBufferList*) 
> bufferList;
> 
> In a new project, I am trying to use the new WebView. If I don’t link to 
> WebKit.framework, of course, the build fails because it can’t find the 
> framework. But if I link to the custom build (the WebView header is the new 
> one, I’ve checked) in run time the app breaks with “-[WebView 
> initWithFrame:samplingRate:frameName:groupName:]: unrecognized selector sent 
> to instance” from which I infer it’s using the system version of the WebView.
> 
> I’ve tried to inspect how the MiniBrowser project correctly is referring to 
> the new build, but I don’t see how the linking is happening…
> 
> Could someone help me out with this?
> 
> Please, accept my apologies, if there is something simple that I’ve missed.
> 
> 
> Regards,
> Nikolay Tsenkov
> ___
> 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] Problem with -webkit-gradient css option on MIPS platform.

[Myles C. Maxfield]

Are you sure that the two versions of webkit are exactly the same? Same 
operating system, same port, same SVN revision?

AFAIK, WebKit itself has no concept of "1.10." That version number belongs to 
whichever project you are getting WebKit from. That project may have built 
WebKit on the two different platforms differently. (Someone else on the team: 
Please correct me if I'm wrong.)

--Myles

> On Sep 29, 2015, at 8:35 AM, Pushkin Andrei  
> wrote:
> 
> Hi. I have embedded Linux MIPS board with webkit 1.10.
> This code does not work on my MIPS board (-webkit-gradient is ignored):
> ABC
> But work in my x86 PC on same version of webkit.
> 
> This code work fine in all platforms:
> ABC
> 
> Andrei Pushkin
> ___
> 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] border-radius lost when applying -webkit-filter

[Myles C. Maxfield]

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 
 mailto: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 1960C++
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 investigation it appears that this data is 
 not used by anything.  Looking at other ports it seems that 
 GraphicsLayerCA.cpp may be making use of this data in its clipping technique.
  
 Looking for fixes that might already be available I found the two below 
 interesting, however note that I already have these in the change that we 
 last took.  They just sounds extremely similar

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

[Myles C. Maxfield]

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 1960C++
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 investigation it appears that this data is 
 not used by anything.  Looking at other ports it seems that 
 GraphicsLayerCA.cpp may be making use of this data in its clipping technique.
  
 Looking for fixes that might already be available I found the two below 
 interesting, however note that I already have these in the change that we 
 last took.  They just sounds extremely similar to what I’m describing.
 http://trac.webkit.org/changeset/179147 
 http://trac.webkit.org/changeset/179147
 http://trac.webkit.org/changeset/175794 
 http://trac.webkit.org/changeset/175794
  
  
 I’m wondering if it can be confirmed that this issue has been a problem for 
 other ports as well?  Are there any fixes that address my problem that I may 
 have overlooked?  What if anything needs to be done to support this (is 
 something like what is done in the CA port a requirement?)  Any advice on 
 implementing the minimal changes, CA’s changes appear extensive.
  
 Thanks for any advice
  
 Chris  Vienneau
 ___
 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
___

Re: [webkit-dev] Please enable the SVG - OTF Font converter!

[Myles C. Maxfield]

Hello,

As of r182423, this converter is now enabled by default on Mac, iOS, and 
Windows ports. I intend to start removing the old codepath soon, so if your 
port is not using the converter, please enable it!

Thanks,
Myles
 On Jan 28, 2015, at 11:17 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 Hello,
 
 I’ve been working on a cross-platform converter to translate SVG fonts into 
 OpenType fonts, with the goal of eventually replacing WebKit support of SVG 
 fonts with platform support of OpenType fonts. This work has reached a point 
 where we have turned it on in the Mac port.
 
 It would be useful for this feature to hear about the level of support that 
 other platforms have of the generated OpenType files that this converter 
 outputs. Given that this is the direction that we will be heading in general, 
 now would be an excellent time for all the ports/platforms to turn on the 
 ENABLE(SVG_OTF_CONVERTER) flag and provide feedback and bug reports!
 
 Thanks,
 Myles C. Maxfield
 ___
 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] Modern image formats for WebKit

[Myles C. Maxfield]

Sorry, I think we are misunderstanding each other. Let me try to be more 
explicit:

There are two conceptual pieces that are required to support image formats:
1) the image decoder itself
2) scaffolding around the API of a decoder to correctly hook it up to the rest 
of WebKit.

First of all, the code in 2) is required no matter what.

I am discussing the code in 1). It seems to me that an image decoder itself 
should come from an external library, rather than be compiled directly from 
WebKit sources.

Assuming that we are linking with external decoding libraries, I do not have 
any strong opinion as to which image decoding libraries that we build 
scaffolding in order to link with.

-Myles

 On Mar 20, 2015, at 6:16 PM, ChangSeok Oh changseok...@collabora.com wrote:
 
 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?
 
 Maybe the latter one. I’m not sure what you meant other libraries here if 
 they are not libwebp nor libjxr. 
 I found webp has been supported by gtk  elf ports already. At least 
 WebPImageDecoder.cpp is a build target for those ports. JXR support would be 
 a same shape with webp support, i. e adding a glue layer 
 JPEGXRImageDecoder.cpp/h and linking libjxr.so.  
 
 ChangSeok
 
 On Mar 21, 2015, at 6:39 AM, Darin Adler da...@apple.com wrote:
 
 We should consider whether to keep the image format decoders in the WebKit 
 tree or not.
 
 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?
 
 — 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] WebCore/platform standalone library

[Myles C. Maxfield]

I think we have a winner!

 If I suggest one.. how about WAFL? WebCore Abstraction Framework Layer
 It should sound sweet like waffle =)
___
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

[Myles C. Maxfield]

Are there no existing libraries that can be conditionally linked with for 
supporting these formats? In the long term, it seems like bad design to have 
WebKit have its own custom decoders.

If that isn't an option, it seems fine to me provided that the decoders' 
sources are all close together (for some definition of close) and not peppered 
throughout WebKit.

 On Mar 19, 2015, at 9:38 PM, ChangSeok Oh changseok...@collabora.com wrote:
 
 Hi WebKittens.
 
 I just saw apng support landed on webkit main stream. [1] (even it works for 
 gtk port only now)
 So I suddenly wonder if webkit community is getting interested in bringing 
 other modern image formats like webp or jpeg-xr into webkit.
 If so, I can lend my hands for it.
 
 For webp support, as you know, we can reuse blink's codebase. [2]
 For jpeg-xr supprot, I have a rough sketch for it [3] (it might be outdated 
 or not fit tot of webkit though, bringing it to webkit is just a piece of 
 cake. ;))
 
 My intention is not to argue which format is better, just to ask community's 
 thoughts, preferences  or like that.
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=17022
 [2] 
 https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cppq=webpimasq=package:chromiuml=1
 [3] 
 http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-supportid=2ac58312a5aae502aacc1c55c0bfdff767ab82a2
 
 BR.
 
 -- 
 ChangSeok
 
 ___
 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] WebCore/platform standalone library

[Myles C. Maxfield]

I do not intend on changing any interfaces or semantics. I only intend to 
change where code lives and library boundaries. There is no need to increase 
the scope of this project.

Also, I do not intend on making up a comical name.

--Myles

 On Mar 19, 2015, at 3:03 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
 
 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. This 
 will involve creating a “Platform top-level directory and moving source 
 files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform 
 into its own target/directory can guarantee that nothing inside it knows 
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its own 
 implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?
 
 I don’t think we need a model like the WebCore/WebKit interface. WTF is 
 essentially like the proposed Platform library already, and it just exposes 
 normal C++ headers and implementation files. I think the main benefit here 
 is cleaning up the layering, as opposed to adding more abstraction. In fact, 
 you could sort of think of WTF and Platform as logically the same library, 
 with WTF being only the parts needed by JavaScriptCore, plus things that are 
 logically at the same level (so basically non-GUI and no networking code).
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 Have you seen the clean interface of ResourceHandle? :)
 
 The client layers tend to get cleaner over time while the lower layers tends 
 to become messier.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Myles C. Maxfield]

Sorry, I missed some of this thread before sending my reply. 

First, I'm going to try to get as far as I can by only moving over the 
non-layer-violating code. Therefore, for the interim, we will have both old and 
new directories. Then I will work on removing layering violations, one by one. 
These things will be taken on a case by case basis.

--Myles

 On Mar 19, 2015, at 10:07 PM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 I do not intend on changing any interfaces or semantics. I only intend to 
 change where code lives and library boundaries. There is no need to increase 
 the scope of this project.
 
 Also, I do not intend on making up a comical name.
 
 --Myles
 
 On Mar 19, 2015, at 3:03 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
 
 On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 3/18/15 9:43 PM, Myles C. Maxfield wrote:
 Hello, all,
 
 I’d like to announce that I intend to create a standalone static library 
 from the current contents of WebCore/platform over the coming months. 
 This will involve creating a “Platform top-level directory and moving 
 source files into it, one by one.
 
 There are a few reasons for this:
 
 1. Enforcing the layering between Platform and WebCore. Moving Platform 
 into its own target/directory can guarantee that nothing inside it knows 
 about anything in WebCore.
 2. Being able to test code in the Platform directory with TestWebKitAPI 
 (without exporting Platform symbols from the WebCore library)
 3. Managing conceptual complexity.
 
 Does anyone have any thoughts or feedback?
 
 That's an awesome project. That's gonna be a lot of work.
 
 How do you plan to do the interface between WebCore and Platform?
 
 Between WebCore and WebKit, we use interfaces with pure virtual functions 
 that are implemented by the clients.
 Between WebCore and the platform, we have headers and each port has its 
 own implementation of that interface.
 
 Do you plan to move Platform behind a public interface or keep the current 
 model?
 
 I don’t think we need a model like the WebCore/WebKit interface. WTF is 
 essentially like the proposed Platform library already, and it just exposes 
 normal C++ headers and implementation files. I think the main benefit here 
 is cleaning up the layering, as opposed to adding more abstraction. In 
 fact, you could sort of think of WTF and Platform as logically the same 
 library, with WTF being only the parts needed by JavaScriptCore, plus 
 things that are logically at the same level (so basically non-GUI and no 
 networking code).
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.
 
 Have you seen the clean interface of ResourceHandle? :)
 
 The client layers tend to get cleaner over time while the lower layers tends 
 to become messier.
 ___
 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] WebCore/platform standalone library

[Myles C. Maxfield]

Hello, all,

I’d like to announce that I intend to create a standalone static library from 
the current contents of WebCore/platform over the coming months. This will 
involve creating a “Platform top-level directory and moving source files into 
it, one by one. 

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?

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

Re: [webkit-dev] Event firing and repainting of saved Images in webkit

[Myles C. Maxfield]

You might want to look at how the onLoad JavaScript event gets fired as well as 
how ImageLoader updates the contents of images as more bytes are downloaded. 
Investigating how animated gifs cause repaints might also be helpful.

As far as the control of reacting to page load and setting up timers, you might 
want to investigate doing that part in script, and implementing only the image 
manipulation algorithm itself in native code.

 On Mar 4, 2015, at 12:44 AM, ankit srivastav ank@gmail.com wrote:
 
 Hi All,
 
 We are working on manipulation of images(falling under a certain criteria) on 
 a web page, but the algorithms being used for the purpose are a bit slow.
 
 So, the idea is to save the images/renderImage objects and continue to 
 render/paint the entire page  and once the page has been loaded/rendered we 
 will trigger an event which will read the saved images one by one, apply the 
 algorithm on them, and then finally repaint them. 
 
 For this mechanism to work correctly we need :
 1) An event after the whole page will get rendered.
 2) A procedure by which we can trigger the repainting of the saved images.
 
 Will it be possible to achieve this using events? If yes, what could be the 
 possible approach? 
 
 Thanks and Regards
 Ankit
 ___
 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] Event firing and repainting of saved Images in webkit

[Myles C. Maxfield]

It might also be worth investigating if you can implement your entire algorithm 
in JavaScript using canvas. The performance might be acceptable. That would 
greatly simplify your code.

 On Mar 4, 2015, at 6:50 AM, Myles C. Maxfield mmaxfi...@apple.com wrote:
 
 You might want to look at how the onLoad JavaScript event gets fired as well 
 as how ImageLoader updates the contents of images as more bytes are 
 downloaded. Investigating how animated gifs cause repaints might also be 
 helpful.
 
 As far as the control of reacting to page load and setting up timers, you 
 might want to investigate doing that part in script, and implementing only 
 the image manipulation algorithm itself in native code.
 
 On Mar 4, 2015, at 12:44 AM, ankit srivastav ank@gmail.com wrote:
 
 Hi All,
 
 We are working on manipulation of images(falling under a certain criteria) 
 on a web page, but the algorithms being used for the purpose are a bit slow.
 
 So, the idea is to save the images/renderImage objects and continue to 
 render/paint the entire page  and once the page has been loaded/rendered we 
 will trigger an event which will read the saved images one by one, apply the 
 algorithm on them, and then finally repaint them. 
 
 For this mechanism to work correctly we need :
 1) An event after the whole page will get rendered.
 2) A procedure by which we can trigger the repainting of the saved images.
 
 Will it be possible to achieve this using events? If yes, what could be the 
 possible approach? 
 
 Thanks and Regards
 Ankit
 ___
 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] Painting /Drawing mechanism in webkit

[Myles C. Maxfield]

Take a look at the ImageLoader class. This is involved when new bytes of an 
image are downloaded, and thus eventually ends up triggering the update of the 
relevant portion of the screen. You can use this class as a model for updating 
the screen once your algorithm is complete.

—Myles
 On Jan 30, 2015, at 8:58 PM, ankit srivastav ank@gmail.com wrote:
 
 Hi All,
 
 I'm new to webkit in context of Painting/Drawing.
 
 I'm trying to use my own algo instead of Webkit defaults Bilenear 
 Interpolation algo for interpolation of images on a webpage.
 That is if destImage Size is greater then SrcImage Size my algo will also 
 come into picture alongside Webkit Bilinear.
 
 But the problem is my algo take lots of time to do the interpolation, hence 
 the page load becomes slow.
 Specially for large images it takes too much time to load the image and hence 
 the webpage.
 
 I have tried to use my algo in PlatformGraphicsContext.cpp along with 
 Bilinear.
 
 If I'm using a separate thread to for my algo.
 I'm not getting the exact result i.e. once the images are drawn by Bilinear 
 it is not been drawn after my algo.
 
 It means I need to fire an event after interpolation is done by my algo, so 
 that images will be drawn using the data from my algo.
 
 Please if someone can tell me the Painting/Drawing mechanism of webkit it 
 would be great.
 
 Regards,
 Ank
 ___
 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] Abandoned Tests

[Myles C. Maxfield]

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] Test result updates today

[Myles C. Maxfield]

Let me update everyone on where I am:

1. I landed http://trac.webkit.org/changeset/14 which flips the switch in 
our tests and updates mac test results.
2. The Windows test results are in such a bad state that it’s difficult to know 
what to rebase and what was already failing. I think I’ll take a look at these 
again after the break and ask Brent to help me.
3. Part of http://trac.webkit.org/changeset/14 adds a bunch of tests to 
TestExpectations that I need to look into. These are tests that started failing 
because of this patch but don’t seem like they should be rebased. For an 
example, see https://bugs.webkit.org/show_bug.cgi?id=139975
4. I haven’t touched iOS tests yet. Similarly to Windows tests, a lot of these 
seem to have been already failing.
5. I haven’t created -expected.png files yet.

I’m not sure how much of this I’m going to get done this week (because I am 
technically on vacation!).

—Myles

 On Dec 27, 2014, at 11:19 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Just a note: the Windows bot exits early long long time ago
 due to too many crashes and timeouts. Additionally there
 many failures too, for example almost all regions tests
 fail with minor pixel differences.
 
 Myles C. Maxfield írta:
 Whoops - this time from the right email address.
 Thanks,
 Myles
 On Dec 27, 2014, at 10:26 AM, litherum lithe...@gmail.com wrote:
 Hello all! I will be rebasing results for all of our Mac + iOS + Windows 
 tests today. The tree might be red for part of the day. I will post in this 
 thread to keep everyone updated with this large update.
 
 The goal of this project is to turn on kerning, ligatures, and printer 
 fonts in our tests for these platforms.
 
 Thanks,
 Myles
 ___
 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] Test result updates today

[Myles C. Maxfield]

Whoops - this time from the right email address.

Thanks,
Myles

On Dec 27, 2014, at 10:26 AM, litherum lithe...@gmail.com wrote:

 Hello all! I will be rebasing results for all of our Mac + iOS + Windows 
 tests today. The tree might be red for part of the day. I will post in this 
 thread to keep everyone updated with this large update.
 
 The goal of this project is to turn on kerning, ligatures, and printer fonts 
 in our tests for these platforms.
 
 Thanks,
 Myles
 ___
 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] Memory Manager

[Myles C. Maxfield]

“Manager” is a vague term. Do you mean a replacement for malloc() / free()?

Is there any documentation or explanation of your implementation?

Why are you confident that WebKit would see speed improvements using this 
library?

What about your memory manager indicates that WebKit would be a good choice of 
user of it?

Are there any other libraries that use it? Which version(s) of Boost is/will 
this be included in?

Thanks,
Myles
 On Dec 21, 2014, at 8:53 PM, Phil Bouchard pboucha...@gmail.com wrote:
 
 Greetings,
 
 I wrote a deterministic memory manager in C++ and I was wondering if their is 
 any interests introducing it into Webkit, thus speeding up Webkit.
 
 The memory manager is located here:
 https://svn.boost.org/svn/boost/sandbox/block_ptr/
 
 
 Sincerely yours,
 -Phil
 
 ___
 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] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU

[Myles C. Maxfield]

This is quite interesting, but I have a bunch of questions regarding this.

What makes the 2D drawing code WebKit-specific? Is it possible to package up 
the rendering code into a self-contained standalone library?

Regarding text, do you have a strategy for instancing geometry or using a glyph 
atlas? Did you implement the Loop Blinn path algorithm?

Did you experiment with attempting to re-order independent drawing commands to 
achieve high GPU occupancy?

Are you measuring power use in addition to time-based performance?

It sounds like OpenGL is doing the drawing itself; I would imagine there are 
many many draw calls per webpage. Does the OpenGL driver introduce significant 
overhead?

Are you thinking of publishing your findings? I would be very interested to 
read about design decisions you encountered along the way.

Thanks,
Myles

 On Nov 13, 2014, at 12:40 AM, Benjamin Poulain benja...@webkit.org wrote:
 
 How does TyGL perform compared to the other rasterizers?
 
 What benchmarks do you use to guide the performance work?
 
 On 11/12/14, 11:12 PM, Zoltan Herczeg wrote:
 Hi All,
 
 We are proud to announce the TyGL port (link:
 http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced
 as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on
 embedded systems. The engine is purely GPU based. It has been developed on
 and tested against ARM-Mali GPU, but it is designed to work on any GPU
 conforming to OpenGL ES 2.0 or higher.
 
 The GPU involvement on future graphics is inevitable considering the pixel
 growth rate of displays, but harnessing the GPU power requires a different
 approach than CPU-based optimizations. 2D graphics is traditionally
 software-based however, and 2D APIs are interfaces to these CPU-based
 algorithms. WebKit GraphicsContext API is no different, so the key
 challenge of our project was and is producing the expected output in a GPU
 friendly way.
 
 Key features:
 
 Batching pipeline:
 
 GPU provides the highest performance when a large number of triangles are
 drawn with a single draw command without any OpenGL state changes. The
 GraphicsContext API in WebKit provides draw operations for single shapes
 however, which can result frequent state changes if implemented naively.
 TyGL was designed to group these commands to reduce the number of draw
 calls.
 
 Automatic shader generator:
 
 TyGL can generate complex shaders from multiple shader fragments, which
 allows efficient batching but it also takes care to make them fit into the
 shader cache of the GPU.
 
 Trapezoid based path rendering:
 
 TyGL uses trapezoid-based tesselation of shapes and the GPU renders them
 with high anti-aliasing quality. We are continuously improving this part
 of the engine and look forward to make use of new GPU capabilities (like
 Pixel Local Storage) to squeeze more performance out of it.
 
 No software fallback:
 
 The whole engine is optimized for GPU without legacy software fallback.
 Hence we don't need to sacrifice optimizations for compatibility. There
 are enough software based 2D libraries which can be used when GPU is not
 available.
 
 TyGL is already capable of rendering many web-sites correctly, but some
 features have not been implemented yet. We continue this work and we are
 open to contributions from the community. Contact to us if you want more
 information about the project.
 
 Regards,
 U-Szeged's web browser team.
 
 
 ___
 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] Port-specific OpenType support

[Myles C. Maxfield]

Sorry for all the confusion on this. Let me clarify the proposal:

I am not proposing dropping support for SVG fonts. I am proposing transcoding 
SVG fonts on-the-fly, at page-load time, to OpenType fonts, then delivering the 
OpenType fonts to the underlying platform (just as if the original page was 
using a web OTF font in the first place).

100% of this work is platform-agnostic.

Once this converter is in place, it will mean that we can remove all of our 
custom SVG-font-rendering code in WebCore (because the platform will be 
responsible for drawing the text instead of WebCore), which would be a very 
good thing for the many reasons listed earlier.

With this in mind, my original question should make more sense - are there any 
ports who want support for SVG fonts but whose platforms don’t support 
OpenType? It sounds like the GTK platform supports OTF, which means they are 
likely okay with this proposal. mrobinson: is that correct?

Thanks,
Myles

 On Sep 15, 2014, at 10:30 AM, Martin Robinson mrobin...@webkit.org wrote:
 
 On Sun, Sep 14, 2014 at 11:22 AM, Tim Horton thor...@apple.com wrote:
 On 2014.09.14, at 01:11, Dirk Schulze k...@webkit.org wrote:
 On Sep 11, 2014, at 11:03 PM, Martin Robinson mrobin...@webkit.org wrote:
 WebKitGTK+ supports OpenType natively and I as far as I know we have
 no problems dropping support for SVG fonts. If SVG fonts are supported
 by the Mac port though, we will probably still want to maintain
 support for our own port, if possible.
 
 SVG Fonts live in the non-platform WebCore space. Dropping support for one 
 platform but keeping the code around for another wouldn’t be of any benefit 
 for WebCore as a whole.
 
 Agreed (but I don’t think the original email was suggesting that; pretty 
 sure Myles was just gauging whether there were any ports that don’t have OT 
 support but need SVG fonts, which would preclude switching over to the 
 translation approach).
 
 Sorry. I probably should have been less obscure about this, but this
 was a gentle request that the work be done using cross-platform
 abstractions, so that it can be shared. If that's difficult or
 impossible, we'll figure something else out. :)
 
 --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

[webkit-dev] Port-specific OpenType support

[Myles C. Maxfield]

Hello, Webkittens!

I have started work on an SVG font - OpenType converter [1] with the intent of 
eventually getting rid of our code path which lays out and draws text using SVG 
fonts. The motivation is fourfold:

1) Performance: on OS X the native text libraries are over 1000x faster than 
our SVG code path.
2) Security: There have been numerous security bugs in the SVG font code path.
3) Code clarity: This would greatly simplify the text rendering code.
4) The next version of SVG is removing SVG fonts completely [2]. Chrome has 
recently dropped support for SVG fonts [3] and Firefox/IE never had it [4] [5].

My question to WebKit-Dev is: Are there any ports who:
1) Want continued support for SVG fonts, and
2) Whose platforms do not support OpenType fonts natively?

Thanks,
Myles C. Maxfield

[1] http://trac.webkit.org/changeset/173521 
http://trac.webkit.org/changeset/173521
[2] http://www.w3.org/TR/SVG2/fonts.html http://www.w3.org/TR/SVG2/fonts.html
[3] 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pYbbUcYvlYY/LQvFvM8KZZEJ
 
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pYbbUcYvlYY/LQvFvM8KZZEJ
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=119490 
https://bugzilla.mozilla.org/show_bug.cgi?id=119490
[5] http://caniuse.com/#feat=svg-fonts http://caniuse.com/#feat=svg-fonts
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Updating and Enabling the CSS Font Loading Spec

[Myles C. Maxfield]

Excellent! I would love to help out in this effort, Bear!

Thanks,
Myles

 On Jul 29, 2014, at 3:45 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 7/29/14, 3:33 PM, Bear Travis wrote:
 On 7/29/14, 12:26 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 On 7/29/14, 11:38 AM, Dirk Schulze wrote:
 
 On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote:
 
 Hi All,
 
 WebKit has support for an older version of the CSS Font Loading
 Specification [1], implemented back in 2013 [2]. I would like to bring
 this work in line with the current version of the specification, and
 enable it by default in the nightlies. The specification provides
 support for coordinating font loading: querying if fonts have loaded,
 requesting specific fonts to load, and providing notifications as fonts
 are loading.
 
 Other browsers have a positive outlook on the feature. Chrome has
 already shipped it [3], and Mozilla is in the process of implementing
 it [4].
 
 Do you want to implement it behind a compile time flag? IMO it is an
 important and great API. However, Cameron filed a lot of specifications
 but reports while implementing it [1]. So there might still be some
 issues to discover.
 
 I strongly support the implementation though.
 
 +1.
 
 
 Yep, the implementation will be behind a compile time flag (the old
 implementation already is). That said, I would like to have it enabled by
 default in dev builds and the nightlies, both to get it into users’ hands
 for testing and to keep the bots running the tests.
 
 That's okay.
 
 The flags are useful to disable unfinished features when shipping (until they 
 are ready). You can enable a flag in nightly if the code is stable and has 
 good test coverage, the feature does not need to be complete.
 
 Successful examples are CSS Grid Layout and the Picture Element. Both are 
 work in progress, they are enabled in Nightly, but none of that code is 
 compiled into the released WebKit.
 
 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] Pratik Solanki is now a WebKit reviewer

[Myles C. Maxfield]

Congrats, Pratik!
On Jun 27, 2014, at 11:44 AM, Andreas Kling akl...@apple.com wrote:

 Hi WebKittens!
 
 I’m happy to announce that Pratik is now a WebKit reviewer. He’s been with 
 the project for a long time, though he spent most of his time hacking on 
 Apple’s internal iOS branch of WebKit. Now that iOS WebKit lives on trunk, so 
 does Pratik! He’s forgotten more than I know about iOS and can finally help 
 review your patches.
 
 Please join me in congratulating Pratik!
 
 -Kling
 ___
 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] WebCore GPU module

[Myles C. Maxfield]

This code was removed in r170208.

—Myles
 On Jun 18, 2014, at 4:23 PM, Dean Jackson d...@apple.com wrote:
 
 The Loop-Blinn code is dead and should be removed from WebKit. I believe Ken 
 Russell implemented it to help with some Chrome/Skia drawing performance, but 
 since then Skia itself updated to use a similar GPU-accelerated approach.
 
 Dean
 
 On 18 Jun 2014, at 6:07 pm, Michael IV explomas...@gmail.com wrote:
 
 Hi All.I have been investigating into WebKit text rendering details and I 
 found Loop-Blinn implementation in GPU directory of WebCore.I have tested it 
 and it kind of works ok for convex shapes rendering which probably should be 
 ok for text glyphs outline as well.
 But I have got a couple of question regarding this module:
 1)Is it used by the browsers to render text or 2d shapes?
 2)Is it actually ready for real-life usage?
 3)How anti  aliasing is handled?I mean ,I found that only curves are 
 anti-aliased(internally by the shader) but the straight line outlines need 
 proper MSAA which can be pretty expensive or even unavailable  on some 
 platforms.
 
 Also I found a bug: when drawing a path with two overlapping convex shapes 
 ,the hole created on the overlap region which is aliased.
 -- 
 
 ___
 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] WebCore GPU module

[Myles C. Maxfield]

I can’t comment on the other ports, but the Mac and iOS ports don’t use it for 
text rendering. Instead, they use CoreText.

Thanks,
Myles
 On Jun 18, 2014, at 1:07 AM, Michael IV explomas...@gmail.com wrote:
 
 Hi All.I have been investigating into WebKit text rendering details and I 
 found Loop-Blinn implementation in GPU directory of WebCore.I have tested it 
 and it kind of works ok for convex shapes rendering which probably should be 
 ok for text glyphs outline as well.
 But I have got a couple of question regarding this module:
 1)Is it used by the browsers to render text or 2d shapes?
 2)Is it actually ready for real-life usage?
 3)How anti  aliasing is handled?I mean ,I found that only curves are 
 anti-aliased(internally by the shader) but the straight line outlines need 
 proper MSAA which can be pretty expensive or even unavailable  on some 
 platforms.
 
 Also I found a bug: when drawing a path with two overlapping convex shapes 
 ,the hole created on the overlap region which is aliased.
 -- 
  
 ___
 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] Runtime flag for -webkit-sticky CSS Value

[Myles C. Maxfield]

Hello, WebKittens!

I’m investigating the possibility of removing the runtime flag for the 
-webkit-sticky CSS value, which will turn on support for this for all ports. 
Are there any ports who depend on this runtime flag?

The WebKit bug that introduced this runtime flag is 
https://bugs.webkit.org/show_bug.cgi?id=96827

Thanks,
Myles
___
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?

[Myles C. Maxfield]

Support here!
On Jan 6, 2014, at 12:51 PM, Lucas Forschler lforsch...@apple.com wrote:

 Happy near year!
 
 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.
 
 Please let me know your thoughts :)
 Lucas
 
 
 
 ___
 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] Announcement: CSS3_TEXT_DECORATION flag

[Myles C. Maxfield]

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

Re: [webkit-dev] Can we disable control reaches end of non-void function warning on Qt?

[Myles C. Maxfield]

I can't speak for Qt, but this warning has been helpful for me in the past.


On Thu, Sep 12, 2013 at 2:07 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi,

 http://trac.webkit.org/changeset/155643 broke Qt build with an error
 saying:

 Source/JavaScriptCore/dfg/DFGGPRInfo.h:169:5: error: control reaches end
 of non-void function [-Werror=return-type]
 cc1plus: all warnings being treated as errors

 because of the following code:

 GPRReg gpr(WhichValueWord which) const
 {
 switch (which) {
 case TagWord:
 return tagGPR();
 case PayloadWord:
 return payloadGPR();
 }
 }

 But the code works just fine as is because WhichValueWord only takes two
 values (TagWord and PayloadWord) and they're all handled in the switch
 statement.

 Can we disable this warning so that we don't have to add a bogus code like
 the one I had to add in
 http://trac.webkit.org/changeset/155649/trunk/Source/JavaScriptCore/dfg/DFGGPRInfo.h?

 - 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] When should I use AtomicString vs String?

[Myles C. Maxfield]

+1 :-)

On Friday, May 31, 2013, Glenn Adams wrote:


 On Fri, May 31, 2013 at 6:14 PM, Rafael Brandao 
 rafael.l...@openbossa.orgjavascript:_e({}, 'cvml', 
 'rafael.l...@openbossa.org');
  wrote:

 This thread contains really useful information, so I've created a new
 topic on https://trac.webkit.org/wiki/EfficientStrings and pointed to
 here.


 One thing that always threw me was the term Atomic in the class name. I
 wonder if the term InternedString would make it usage more apparent.



 Best regards,
 Rafael


 On Fri, May 31, 2013 at 8:32 PM, Ryosuke Niwa 
 rn...@webkit.orgjavascript:_e({}, 'cvml', 'rn...@webkit.org');
  wrote:

 We shouldn't use AtomicString if the string we're about to create
 doesn't get shared across multiple AtomicStrings.

 For example, if we had used AtomicString for the strings inside Text
 nodes, then we may end up filling up the atomic string table with all these
 really long strings that don't typically appear more than once.  It also
 slows down the hash map look up for all other atomic strings.

 On Fri, May 31, 2013 at 3:00 PM, Brendan Long 
 s...@brendanlong.comjavascript:_e({}, 'cvml', 's...@brendanlong.com');
  wrote:

  So should I just never use String and always use AtomicString?


 On 05/31/2013 03:14 PM, Daker Pinheiro wrote:

 It is faster to compare and hash AtomicString than regular Strings.


 On Fri, May 31, 2013 at 5:57 PM, Brendan Long 
 s...@brendanlong.comjavascript:_e({}, 'cvml', 's...@brendanlong.com');
  wrote:

 I hope this isn't a stupid question, but I can't find any references to
 what the difference between AtomicString and String is. It looks like
 AtomicString is generally preferred, but I don't know why. Can someone
 fill me in on this? Is there any refences for the classes in WTF?


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org javascript:_e({}, 'cvml',
 'webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev




  --
 Daker Fernandes Pinheiro
 http://codecereal.blogspot.com



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org javascript:_e({}, 'cvml',
 'webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org javascript:_e({}, 'cvml',
 'webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev




 --
 Rafael Brandao @ INdT

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org javascript:_e({}, 'cvml',
 '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] Slide deck: How WebKit Works

[Myles C. Maxfield]

Thanks so much for this!

--Myles
On Oct 31, 2012 11:39 AM, Zoltan Horvath zol...@webkit.org wrote:

 It's a nice and well understandable overview!

 Thanks for sharing!
 Zoltan

 On Wed, Oct 31, 2012 at 11:30 AM, Adam Barth aba...@webkit.org wrote:

 Below are some slides I presented yesterday that give a high-level
 overview of how WebKit works:


 https://docs.google.com/presentation/pub?id=1ZRIQbUKw9Tf077odCh66OrrwRIVNLvI_nhLm2Gi__F0

 Unfortunately, the talk was not recorded, but I wanted to share the
 slide deck in case they're useful to you.  I've also added the link to
 http://www.webkit.org/coding/technical-articles.html.

 Thanks!
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



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


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

Re: [webkit-dev] malloc(0)

[Myles C. Maxfield]

http://sourceforge.net/mailarchive/message.php?msg_id=29406824
http://bugs.icu-project.org/trac/ticket/9396

There was a fair amount of activity on my WebKit patch (thanks everyone!) (
https://bugs.webkit.org/show_bug.cgi?id=88936) but it seems to have
stopped. Did I do something wrong?

Thanks,
Myles

On Wed, Jun 13, 2012 at 3:53 PM, Myles C. Maxfield myles.maxfi...@gmail.com
 wrote:

 I started a thread on icu-design (mailing list) about it. As soon as it
 appears in the archives, I'll post a permalink to the thread.

 The null pointer check shouldn't matter - if the pointer isn't null, then
 it's valid anyway :-)

 --Myles


 On Wed, Jun 13, 2012 at 3:37 PM, Benjamin Poulain benja...@webkit.orgwrote:

 On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler da...@apple.com wrote:
   There is still the question of if I can upstream this to ICU, which
 I'm
   checking on.
 
  I was not proposing changing ICU.

 I did.
 In addition to changing WebKit, not using the pointer when the length
 is zero does not necessarily seem like a bad idea to me.

 Benjamin



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

Re: [webkit-dev] malloc(0)

[Myles C. Maxfield]

Thanks for the quick responses and the bug link about fastMalloc(0).

In comment 11 https://bugs.webkit.org/show_bug.cgi?id=55097#c11, Eric
Seidel says that he was going to start a discussion on webkit-dev, but I
haven't been able to find such a conversation (by looking both on gmane and
on google). All I've been able to find is this
threadhttps://lists.webkit.org/pipermail/webkit-dev/2011-June/016967.html,
which is only a single post. Does anyone know where this conversation takes
place?

That being said, Darin Adler is right; the original patch was intended to
improve performance, not because something was breaking. It seems like most
of the conversation regarding that patch is about any possible performance
increase. In addition, Eric Seidel's patch was to guarantee that no one
tries to call fastMalloc with a size of 0; I'm merely concerned about the
value of the pointer returned when someone does call that.

I think the fact that ICU thinks that a null pointer is an invalid string
isn't necessarily an incorrect one. It's just a quirk of an interface to a
library. I don't think that a good solution is to change the interface of
ICU and try to upstream a patch to ICU - I think a better solution would be
to work around this requirement of ICU inside WebKit.

I see two different solutions:
1) Document the fact that, in order to use webkit, you need an
implementation of malloc(0) that doesn't return null pointers. This way,
the burden of solving this problem is pushed downstream.
2) Find some place along the every pipeline from malloc(0) to ICU, and
arbitrarily modify the pointer to a non-zero value. This is probably the
best solution, but a real fix of this nature requires finding all the
places where pointers can be passed into ICU.

If I solve (via option 2) just my one particular occurrence of this
problem, I see three different places to arbitrarily modify the pointer
given to ICU:
1) change the m_copyData16 pointer in StringImpl to an arbitrary value, and
check for that arbitrary value on destruction
2) change the characters() accessor to check if m_copyData16 is null, and
return an arbitrary value if it is. This works because callers of
characters() shouldn't ever delete the pointer nor dereference the pointer
(since the string's length is 0)
3) check for null at the call site of the ICU function.

I (perhaps prematurely) uploaded a CL
implementinghttps://bugs.webkit.org/show_bug.cgi?id=88936option 2.
What do you think?

--Myles

On Wed, Jun 13, 2012 at 2:09 AM, Zoltan Horvath zol...@webkit.org wrote:

 Hi,

 The bug report about fastMalloc(0):
 https://bugs.webkit.org/show_bug.cgi?id=55097

 Brewmp had conditions for fastMalloc(0) earlier, but it was removed in:

http://trac.webkit.org/changeset/9/trunk/Source/JavaScriptCore/wtf/FastMalloc.cpp

 Cheers,
 Zoltan


 On Wed, 13 Jun 2012 00:08:48 +0200, Adam Barth aba...@webkit.org wrote:

 There was some discussion about how to handle malloc(0) a year or so
 ago.  I don't remember if it was on webkit-dev, but you might want to
 check the archives.  Eric Seidel might remember what conclusions (if
 any) we came to.

 Adam


 On Tue, Jun 12, 2012 at 3:03 PM, Myles C. Maxfield
 myles.maxfi...@gmail.com wrote:

 Hello,
 I'm compiling WebKit with a malloc() implementation that returns NULL
 for malloc(0). According to C99, this is valid: If the size of the
 space requested is zero, the behavior is implementation- defined:
 either a null pointer is returned, or the behavior is as if the size
 were some nonzero value, except that the returned pointer shall not be
 used to access an object.

 I noticed that this caused a problem in one particular place
 (WTF::StringImpl::getData16SlowCase()) where the code allocates
 (constant * length) bytes for an (empty) string, and provides an
 accessor that exposes this pointer. This pointer was being passed to
 ICU, which didn't perform the requested function because it looked
 like one of the arguments was invalid, even though it was just empty.

 I have worked around this one particular occurrence in my local
 version of WebKit fork, but I'm wondering how often this pattern
 occurs. Is my fix worth upstreaming?  Is it worth trying to find,
 fix, and upstream every occurrence of this pattern? Or is this
 particular behavior of malloc() an unstated requirement of building
 WebKit? If the latter is true, perhaps it's worth explicitly stating
 this somewhere? What is the opinion of the community?

 Thanks,
 Myles
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

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

Re: [webkit-dev] malloc(0)

[Myles C. Maxfield]

There is still the question of if I can upstream this to ICU, which I'm
checking on.

In the meantime, Ryosuke Niwa has a good argument for option 3) above. I
have uploaded a new patch to
https://bugs.webkit.org/show_bug.cgi?id=88936that moves the NULL
pointer check to inside the ICU-specific collator class.

On Wed, Jun 13, 2012 at 1:14 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Jun 13, 2012 at 12:48 PM, Myles C. Maxfield 
 myles.maxfi...@gmail.com wrote:

 I think the fact that ICU thinks that a null pointer is an invalid string
 isn't necessarily an incorrect one. It's just a quirk of an interface to a
 library. I don't think that a good solution is to change the interface of
 ICU and try to upstream a patch to ICU


 Certainly not since not all browsers ship with their own ICU embedded
 inside.

 I see two different solutions:
 1) Document the fact that, in order to use webkit, you need an
 implementation of malloc(0) that doesn't return null pointers. This way,
 the burden of solving this problem is pushed downstream.


 I don't think we should impose arbitrary requirements like this.


  2) Find some place along the every pipeline from malloc(0) to ICU, and
 arbitrarily modify the pointer to a non-zero value. This is probably the
 best solution, but a real fix of this nature requires finding all the
 places where pointers can be passed into ICU.


 We already have an abstraction layer for all ICU functions in WTF and
 WebCore/platform because not all ports use ICU (e.g. Qt port). It should be
 fairly easy to add an extra code there to check whether a null pointer is
 passed in or not and bail out as appropriate.

 If I solve (via option 2) just my one particular occurrence of this
 problem, I see three different places to arbitrarily modify the pointer
 given to ICU:
 1) change the m_copyData16 pointer in StringImpl to an arbitrary value,
 and check for that arbitrary value on destruction
 2) change the characters() accessor to check if m_copyData16 is null, and
 return an arbitrary value if it is. This works because callers of
 characters() shouldn't ever delete the pointer nor dereference the pointer
 (since the string's length is 0)
 3) check for null at the call site of the ICU function.

 I (perhaps prematurely) uploaded a CL 
 implementinghttps://bugs.webkit.org/show_bug.cgi?id=88936option 2. What do 
 you think?


 Adding any code to characters() will likely impact performance because it
 tends to be used in hot code paths so I'd rather avoid that.

 - Ryosuke


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

Re: [webkit-dev] malloc(0)

[Myles C. Maxfield]

I started a thread on icu-design (mailing list) about it. As soon as it
appears in the archives, I'll post a permalink to the thread.

The null pointer check shouldn't matter - if the pointer isn't null, then
it's valid anyway :-)

--Myles

On Wed, Jun 13, 2012 at 3:37 PM, Benjamin Poulain benja...@webkit.orgwrote:

 On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler da...@apple.com wrote:
   There is still the question of if I can upstream this to ICU, which I'm
   checking on.
 
  I was not proposing changing ICU.

 I did.
 In addition to changing WebKit, not using the pointer when the length
 is zero does not necessarily seem like a bad idea to me.

 Benjamin

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

[webkit-dev] malloc(0)

[Myles C. Maxfield]

Hello,
I'm compiling WebKit with a malloc() implementation that returns NULL
for malloc(0). According to C99, this is valid: If the size of the
space requested is zero, the behavior is implementation- defined:
either a null pointer is returned, or the behavior is as if the size
were some nonzero value, except that the returned pointer shall not be
used to access an object.

I noticed that this caused a problem in one particular place
(WTF::StringImpl::getData16SlowCase()) where the code allocates
(constant * length) bytes for an (empty) string, and provides an
accessor that exposes this pointer. This pointer was being passed to
ICU, which didn't perform the requested function because it looked
like one of the arguments was invalid, even though it was just empty.

I have worked around this one particular occurrence in my local
version of WebKit fork, but I'm wondering how often this pattern
occurs. Is my fix worth upstreaming?  Is it worth trying to find,
fix, and upstream every occurrence of this pattern? Or is this
particular behavior of malloc() an unstated requirement of building
WebKit? If the latter is true, perhaps it's worth explicitly stating
this somewhere? What is the opinion of the community?

Thanks,
Myles
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev