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] Proposal: Remove ENABLE(MATHML)

[Myles C. Maxfield]

I’d like to clarify my previous email.

Everyone wants to see high quality math rendering on the Web. MathML is a web 
standard, has two implementations (WebKit and Gecko), and is one of the most 
requested features in Chromium 
<https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary>
 and Edge 
<https://developer.microsoft.com/en-us/microsoft-edge/platform/status/?q=sort:Votes>.
 Chromium is even in talks to add support. Clearly, MathML is part of the Web 
Platform.

I was not proposing that we pull MathML support from WebKit. Native support for 
MathML, rather than polyfilled support, leads to better experiences for our 
users for many reasons, among them performance and accessibility. Bugs (or even 
“quite a few bugs”) is not sufficient evidence to pull a feature like this.

Instead, I was pointing out that MathML doesn’t seem to be getting the love it 
deserves. I hope we can improve our support for MathML to make our 
implementation the best it can possibly be.

Thanks,
Myles

> On Oct 27, 2017, at 2:15 PM, Myles C. Maxfield  wrote:
> 
> 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

___
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  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 
>>> 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  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  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  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 > <mailto:annu...@yandex.ru>> wrote:
>> 
>> 
>> 
>> 14.01.2017, 17:16, "Fujii Hironori" > <mailto:fujii.hiron...@gmail.com>>:
>>> On Sat, Jan 14, 2017 at 1:34 AM, Konstantin Tokarev >> <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.
>> 
>>> ___
>>> webkit-dev mailing list
>>>

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  wrote:
> 
>> On Jan 14, 2017, at 12:39 PM, Myles C. Maxfield  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  wrote:

>> On Jan 10, 2017, at 9:24 PM, Myles C. Maxfield  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  
> 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 >> om> 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
___
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  wrote:
> 
> 
> 
> 03.11.2016, 22:18, "Rogovin, Kevin"  <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 
>> Cc: Carlos Garcia Campos ; webkit-dev@lists.webkit.org
>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>> 
>> It sounds like the primary focus of your work is improving performance. It 
>> also sounds like the only benchmark you’ve run is an artificial one that you 
>> constructed yourself.
>> 
>> Given these two things, I would strongly hesitate to call our interest 
>> "significant community enthusiasm.”
>> 
>> Why don’t you start by running some of the many existing graphics benchmarks 
>> with your library?
>> 
>> Please correct me if my assumptions are mistaken.
>> 
>> Thanks,
>> Myles
>> 
>>>  On Nov 3, 2016, at 12:50 AM, Rogovin, Kevin  
>>> wrote:
>>> 
>>>  Adding a new GraphicsContext is what I want to do as it seems the path of 
>>> least pain and suffering. However, all the other things of a backend I do 
>>> not need to do. I do not know how to add a GraphicsContext backend in terms 
>>> of makefile magicks and configuration. I also do not know the plumbing for 
>>> making it active. In theory, FastUIDraw's GraphicsContext will work on any 
>>> platform that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do 
>>> this? Years ago I remember that the build configuration is what governed 
>>> what backend was built... and I usually just piggy packed onto another... 
>>> years ago I remember there was like an SDL style backend that did not 
>>> require a large toolkit, just SDL.. is that still alive? where is it? I 
>>> could piggy back the work there if it still is alive...
>>> 
>>>  Also, to get permission to do this work, I need significant community 
>>> enthusiasm otherwise I will not be able to justify the large amount of work 
>>> needed. This is another area where I need a great deal of help.
>>> 
>>>  Best Regards,
>>>  -Kevin Rogovin
>>> 
>>>  -Original Message-
>>>  From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
>>>  Sent: Thursday, November 3, 2016 9:43 AM
>>>  To: Rogovin, Kevin ; Myles C. Maxfield
>>>  
>>>  Cc: webkit-dev@lists.webkit.org
>>>  Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>> 
>>>  El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
>>>>  Hi,
>>>> 
>>>>   The main issue of making a Cairo backend to FastUIDraw is clipping.
>>>>  Cairo tracks the clipping region in CPU and does things that are fine
>>>>  for CPU-based rendering (i.e. span based rendering) but are
>>>>  absolutely awful for GPU rendering (from my slides, one sees that GL
>>>>  backed QPainter and Cairo do much worse than CPU backed). FastUIDraw
>>>>  only supports clipIn and clipOut and pushes all the clipping work to
>>>>  the GPU with almost no CPU work. It does NOT track the clipping
>>>>  region at all. I can 

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

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  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 > <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 > <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, 김덕진 >> <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  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  <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, 김덕진 > <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  wrote:
> 
> 
>> On Jun 1, 2016, at 1:37 PM, Myles C. Maxfield > <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 GraphicsContext. 
> 
> Howe

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] Building Webkit on Windows

[Myles C. Maxfield]

Which part of WebKit are you interested in working on?

> On Mar 30, 2016, at 7:14 AM, Antonio Gomes  wrote:
> 
> Hi Rakesh.
> 
> See "GoodFirstBugs" or "EasyFix" classes of bugs in bugs.webkit.org,
> e.g. https://bugs.webkit.org/buglist.cgi?quicksearch=EasyFix&list_id=1643027
> .
> 
>> On Wed, Mar 30, 2016 at 4:39 AM, Rakesh Sadhu  
>> wrote:
>> 
>> Hi Alex  and all Friends here  ,
>> Its finally build .
>> I have a question, I wanna contribute and i would like to start with easy
>> and baby steps kinda bugs.
>> Any suggestions ?
>> 
>> 
>> regards
>> RSadhu
>> 
>> 
>> 
>> Subject: Re: [webkit-dev] Building Webkit on Windows
>> From: achristen...@apple.com
>> Date: Mon, 29 Feb 2016 10:26:00 -0800
>> CC: thomas.br...@porabo.ch; bfulg...@apple.com; mmaxfi...@apple.com;
>> webkit-dev@lists.webkit.org
>> To: rakeshsa...@hotmail.com
>> 
>> 
>> Rakesh, you are building the AppleWin port of WebKit, which only has 32-bit
>> binaries available, but you probably want to use the WinCairo port because
>> the license of WebKitSupportLibrary.zip says you’re not allowed to
>> redistribute it.  To build the WinCairo port, you will need to run
>> update-webkit --wincairo and build-webkit --wincairo --64-bit.
>> 
>> This is not the source of your build failure, though.  It looks like you
>> have your gperf executable inside of C:\Program Files… somewhere, and I
>> believe we have never had anyone build WebKit with a configuration like
>> this.  I think the solution is to put quotes around the %s at the very end
>> of Source/WebCore/platform/network/create-http-header-name-table.  There
>> might be a few more places where this is needed.  Could you please file a
>> bug a bugs.webkit.org with a patch if you get it working?
>> 
>> On Feb 27, 2016, at 2:01 AM, Rakesh Sadhu  wrote:
>> 
>> 
>> Hi Thomas,
>> Thank for your  answer .
>> However my build suddenly fails and I notice , its creating 32 bit binaries
>> .
>> I am attaching a build log file here .
>> 
>> regards
>> RSadhu
>> 
>> 
>> 
>> To: achristen...@apple.com
>> From: thomas.brodt.li...@porabo.ch
>> Date: Fri, 26 Feb 2016 09:15:06 +0100
>> CC: webkit-dev@lists.webkit.org
>> Subject: Re: [webkit-dev] Building Webkit on Windows
>> 
>> Hi Alex
>> 
>> thank you for your prompt answer. That is good news because in the past I
>> had different difficulties in setting up a functional environment with
>> several trial and error steps inbetween, although I tried to exactly follow
>> the installation guide. I tend to create a virtual machine for a reliable
>> building environment, so with my next one I will try without the cygwin
>> installation.
>> 
>> We use Webkit via COM interface on Windows in our application here, so I
>> build rather infrequently, and with a working build, we then can live for
>> some time. But for our use we would need 32bit dependencies, and if I
>> understood correctly, there are currently only 64bit available. That doesn't
>> matter at the moment, but when I am ready for our next build, I would ask
>> again if you don't mind.
>> 
>> Thanks for your help!
>> 
>> Thomas
>> 
>> Am 25.02.2016 um 19:17 schrieb Alex Christensen:
>> 
>> That also applies to the WinCairo port.  I don’t think you’ll need GNU Make
>> any more now that we use CMake for Windows.  You also shouldn’t need to
>> install iTunes to build and run WinCairo.  With WinCairo, you will also need
>> the WinCairoDependencies.zip which you can get by running
>> Tools/Scripts/update-webkit-wincairo-libs.  Right now, only the 64-bit
>> dependencies are included in that zip, but let me know if you need 32-bit
>> dependencies.  They are from https://github.com/peavo/WinCairoRequirements
>> Then you should be able to build with Tools/Scripts/build-webkit --wincairo
>> --64-bit
>> 
>> We really should update the instructions on webkit.org
>> 
>> On Feb 25, 2016, at 12:17 AM, Thomas Brodt 
>> wrote:
>> 
>> Does this also apply for the WinCairo port? Or does this port still require
>> cygwin?
>> 
>> Thomas
>> 
>> Am 24.02.2016 um 20:32 schrieb Alex Christensen:
>> 
>> Those instructions are out of date.  The most up-to-date instructions about
>> building on Windows are http://trac.webkit.org/wiki/WindowsWithoutCygwin
>> 
>> On Feb 24, 2016, at 9:57 AM, 

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  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] 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   
>  C+

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] 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  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  <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:
> 
>  
> 
> Basic CSS Filters
> Basic CSS Filters
>  
> 
> #pic {
>   border-radius: 10px;
>   -webkit-filter: sepia(0.8);
> }
> 
>  
> 
> 
>   
> 
> 
> 
>  
> 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::Vector & 
> 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::Vector & 
> 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 

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  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:
> 
>  
> 
> Basic CSS Filters
> Basic CSS Filters
>  
> 
> #pic {
>   border-radius: 10px;
>   -webkit-filter: sepia(0.8);
> }
> 
>  
> 
> 
>   
> 
> 
> 
>  
> 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::Vector & 
> 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::Vector & 
> 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/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 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https:

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  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] 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]

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  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  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] 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  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.cpp&q=webpima&sq=package:chromium&l=1
> [3] 
> http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-support&id=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]

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  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  wrote:
>>> 
>>>> On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
>>>> 
>>>> On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  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

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  wrote:
> 
>> On 3/19/15 2:49 PM, Maciej Stachowiak wrote:
>> 
>>> On Mar 19, 2015, at 1:47 PM, Benjamin Poulain  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] 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]

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  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  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] 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  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] 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  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

[webkit-dev] Please try out the SVG -> OTF Font converter!

[Myles C. Maxfield]

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

Re: [webkit-dev] Abandoned Tests

[Myles C. Maxfield]

That's what I mean. What happens when we actually run them?

> On Jan 21, 2015, at 9:29 PM, Brent Fulgham  wrote:
> 
> Hi Myles,
> 
> These tests don’t fail — they are all skipped on mac, win, gtk, and efl.
> 
> -Brent
> 
>> On Jan 21, 2015, at 9:24 PM, Myles C. Maxfield  wrote:
>> 
>> On which platforms do they fail?
>> 
>> —Myles
>>> On Jan 21, 2015, at 8:48 PM, Brent Fulgham  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] Abandoned Tests

[Myles C. Maxfield]

On which platforms do they fail?

—Myles
> On Jan 21, 2015, at 8:48 PM, Brent Fulgham  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  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  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  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  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  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  wrote:
> 
> On Sun, Sep 14, 2014 at 11:22 AM, Tim Horton  wrote:
>> On 2014.09.14, at 01:11, Dirk Schulze  wrote:
>>> On Sep 11, 2014, at 11:03 PM, Martin Robinson  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  wrote:
> 
> On 7/29/14, 3:33 PM, Bear Travis wrote:
>> On 7/29/14, 12:26 PM, "Benjamin Poulain"  wrote:
>> 
>>> On 7/29/14, 11:38 AM, Dirk Schulze wrote:
 
 On Jul 29, 2014, at 7:42 PM, Bear Travis  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  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  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  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  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

Re: [webkit-dev] Enable build for CSS3_TEXT

[Myles C. Maxfield]

I agree with Dirk about not enabling flags that don’t actually change rendering.

I’m not sure if waiting until CR, specifically, is absolutely necessary, 
though. For example, the Mac port has CSS3 text decorations enabled.

—Myles
> On May 21, 2014, at 9:49 AM, Dirk Schulze  wrote:
> 
> 
> On May 21, 2014, at 6:32 PM, Zoltan Horvath  wrote:
> 
>> 
>> Hi there, 
>> 
>> We have 2 properties under CSS3_TEXT macro: 
>> 
>> -webkit-text-align-last (http://trac.webkit.org/changeset/162213)
>> -> parsing&rendering are implemented
>> 
>> -webkit-text-justify (https://bugs.webkit.org/show_bug.cgi?id=99945)
>> -> only parsing is implemented
>> 
>> Spec : http://dev.w3.org/csswg/css-text-3/
>> 
>> CSS3_TEXT is disabled by default for our builds. Since we've got the proper 
>> testing for the existing code, I'd like to enable the flag by default.
> 
> I object to enable -webkit-text-justify if it doesn’t actually have any 
> functionality. This is poor behavior for authors since they can not feature 
> test.
> 
> It would be great to wait for CR of the spec and enable 
> -webkit-text-align-last unprefixed. (Assuming that is isn't shipped in Safari 
> yet.)
> 
> So in general, I would vote for not enabling the flag at this point.
> 
> Greetings,
> Dirk
> 
>> 
>> Let me know if you have any objections.
>> 
>> Cheers,
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] 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  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  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.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 
>> 
>> > 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 
>>> 
>>> > 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 
 
 > 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  '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 >>> 'webkit-dev@lists.webkit.org');>
 https://lists.webkit.org/mailman/listinfo/webkit-dev


>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org >> '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 > '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"  wrote:

> It's a nice and well understandable overview!
>
> Thanks for sharing!
> 
>
> On Wed, Oct 31, 2012 at 11:30 AM, Adam Barth  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
>> .
>>
>> 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  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 wrote:
>
>> On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler  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]

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 wrote:

> On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler  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]

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  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 
>> implementing<https://bugs.webkit.org/show_bug.cgi?id=88936>option 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]

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
thread<https://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
implementing<https://bugs.webkit.org/show_bug.cgi?id=88936>option 2.
What do you think?

--Myles

On Wed, Jun 13, 2012 at 2:09 AM, Zoltan Horvath  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,
> 
>
>
> On Wed, 13 Jun 2012 00:08:48 +0200, Adam Barth  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
>>  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,
>>

[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