[webkit-dev] Replacing Cairo in WebKit with Skia

[Carlos Garcia Campos via webkit-dev]

Hi WebKittens,

At Igalia we have spent some time exploring different options to
replace the Cairo 2D rendering library in the GTK and WPE ports (we
even tried rolling our own library). Recently we decided to try Skia
and we have successfully integrated it in the WPE port. Right now we
can compile WebKit with Skia linked statically, as part of the CMake
build, and run a number benchmarks. This has allowed us to compare the
Skia GPU and CPU renderers with the existing Cairo one in different
devices.

The results are very promising: benchmarks are faster than Cairo's CPU
rendering, specially with Skia's GPU renderer. The improvement varies
for each device, but in any case it is already clear that the change is
a net positive on every configuration we have tested. Additionally, the
integration in the build system is well isolated: importing Skia under
Source/ThirdParty there is no need for any additional dependencies,
patching Skia has not been needed, and the changes in WebKit are
limited to code from the WPE port.

After talking to teams from Google, Sony, Apple and RedHat during this
week, everyone thinks using Skia will be a great improvement for the
GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
start upstreaming what we have to the WebKit repository and continue
the work there.

Points we need to consider:

- Skia is licensed under the BSD 3-Clause “New” license, which
should be compatible with WebKit's.

- The Skia source tree would add about 170MiB to the repository
under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
367MiB and ANGLE 73MiB.

- We plan to update Skia frequently following Google's
recommendation. We have already agreed with the Skia maintainers to
stay in contact and will explore integrating an automated system to
test updates. We have also discussed Skia's security policy with
Google, and we will have a procedure in place to incorporate security
fixes, the latest when we start making releases using Skia.

- We cannot promise a timeline at the moment but expect refactors
in the GTK and WPE ports after the initial integration. We have big
plans for rearchitecting the rendering pipeline to better take
advantage of GPUs, and we hope we can get rid of some complex code
while at it.

Please let us know if you have any questions, we plan to do this job
sooner rather than later if there are no objections. We are very
excited about this move since we really think it will be a great step
ahead for the non Apple ports of WebKit, allowing the project to grow
even bigger and stronger.

Best regards,

- The Igalia team

-- 
Carlos Garcia Campos


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] InjectedBundle deprecation

[Carlos Garcia Campos via webkit-dev]

Here is the list of features in GTK and WPE ports exposed using
injected bundle.

JavaScript extensions
-

Used by apps to expose current JavaScript APIs using the JSC API. This
includes:

 - WebKitScriptWorld: The window-object-cleared signal is the initial
point for injecting JavaScript. It allows allows to create isolated
worlds.
 - WebKitFrame: To get the JS context. It also allows to get the JS
value for a node handle.
 - WebKitDOMNode: To associate a DOM node to its JSCValue.

We still need a way to run code in the JavaScript process.


Requests handling
-

This is send-request signal to expose willSendRequest. It allows to
modify every request before it's sent or even cancel it. This was used
by epiphany to implement the adblocker before the content filter api
existed. Other apps still use it to modify the uri of requests before
being sent.

This is not easy to migrate because going to the UI process for every
load would be too much.


Context Menu


This is the same API we have in the UI process to provide more
information and be able to build the menu based on the DOM node. For
example epiphany uses it to determine if the context menu was opened
over a node that is editable or a password input field. It's also used
to get the currently selected text. All that info is set as user data
that is passed to the context menu signal in the UI process.

I think nowadays most of this information is already in
WebHitTestResultData and we can add whatever is missing, so this should
be easy to migrate.


Form autofilling


We expose a signal to notify when form controls are associated to a
frame. This is used by epiphany to auto fill password fields.

This could probably be moved to the UI process or implemented entirely
using JavaScript.


Password manager


Related with previous one we have a signal to notify when a form is
going to be submitted. Used by epiphany to remember the passwords.

This could probably be moved to the UI process or implemented entirely
using JavaScript.


Console messages


API to notify the user when a console message is sent.

This could be easily moved to the UI process, but I think nobody is
currently using this API so it can be just removed instead.


Editor
--

Expose the selection changed signal.

This could be implemented with JavaScript. I'm not sure this is
currently used by any application.


Resources load
--

This is internal implementation used to implement the UI process API
for resources.

There's APIResourceLoadClient now, so we could probably switch to use
that or add whatever is missing.


Page snapshot
-

This is also internal implementation for the UI process API for page
snapshots.

We could expose this without using injected bundle at all.


User messages
-

API to send custom messages between UI and web process.

We might need this depending on how we migrate other features.




El dom, 14-08-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit-
dev escribió:
> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
> escribió:
> > Hello WebKit developers! We are ramping up to do some serious work
> > on
> > Site Isolation which includes putting cross-origin iframes in a
> > different process than the parent frame. Similar efforts have been
> > done in other browser engines and some related work has already
> > been
> > done in WebKit, but not enough.
> > 
> > This will do strange things to the InjectedBundle APIs, which have
> > fundamental assumptions that the whole DOM is in one process and
> > that
> > communication only happens with one process at a time. We have
> > never
> > exposed InjectedBundle APIs as public API, but some other
> > distributors of WebKit have. As we make progress on this project,
> > we
> > anticipate that anything in
> > Source/WebKit/WebProcess/InjectedBundle/API is subject to
> > deprecation
> > and removal.  This will also allow us to tighten the sandbox on the
> > web process, resolve security and performance issues, and have
> > cleaner code.
> > 
> > Would the maintainers of the GTK and WPE APIs be willing to assist
> > in
> > migrating from those APIs and designing replacements in the UI
> > process?
> > 
> 
> Sure. I think the most important feature we expose from injected
> bundle
> is JavaScript extensibility using the JSC API.
> 
> Next week I can write a summary of the features we currently expose
> from injected bundle and  possible alternatives.
> 
> > Alex Christensen
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >

Re: [webkit-dev] InjectedBundle deprecation

[Carlos Garcia Campos via webkit-dev]

El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
escribió:
> Hello WebKit developers! We are ramping up to do some serious work on
> Site Isolation which includes putting cross-origin iframes in a
> different process than the parent frame. Similar efforts have been
> done in other browser engines and some related work has already been
> done in WebKit, but not enough.
> 
> This will do strange things to the InjectedBundle APIs, which have
> fundamental assumptions that the whole DOM is in one process and that
> communication only happens with one process at a time. We have never
> exposed InjectedBundle APIs as public API, but some other
> distributors of WebKit have. As we make progress on this project, we
> anticipate that anything in
> Source/WebKit/WebProcess/InjectedBundle/API is subject to deprecation
> and removal.  This will also allow us to tighten the sandbox on the
> web process, resolve security and performance issues, and have
> cleaner code.
> 
> Would the maintainers of the GTK and WPE APIs be willing to assist in
> migrating from those APIs and designing replacements in the UI
> process?
> 

Sure. I think the most important feature we expose from injected bundle
is JavaScript extensibility using the JSC API.

Next week I can write a summary of the features we currently expose
from injected bundle and  possible alternatives.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get=0xF3D322D0EC4582C3



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 7 Days Until Retiring Subversion

[Carlos Garcia Campos via webkit-dev]

El jue, 16-06-2022 a las 16:11 -0700, Jonathan Bedard via webkit-dev
escribió:
> Hey folks,
> 
> The time has come! On Thursday, June 23rd, we are planning on
> stopping all commits to the Subversion repository hosted
> on https://svn.webkit.org, all future commits will at that point be
> made on https://github.com/WebKit/WebKit. If the following is true
> about your development workflow:
> 

We still depend on svn for the stable branches of GTK and WPE ports.
Would it be possible to migrate our branches to github before removing
svn?

> - You use github.com/WebKit/WebKit as the remote for your git
> checkout of WebKit
> - You commit with Commit-Queue, Merge-Queue or Unsafe-Merge-Queue
> 
> Then you do not need to change anything about your workflow. Changes
> which are being processed during the transition will be routed to the
> correct place by Commit and Merge Queue. I would like to specifically
> note that `webkit-patch` and the patch workflow in general will
> continue to work after Subversion is frozen. You can check which
> remote your checkout uses with ‘git remote -v’. Please see the
> migration guide below for details.
> 
> If you are still reliant off of git.webkit.org remotes (either
> WebKit-https.git or WebKit.git), or if you still have a checkout
> based on https://svn.webkit.org, it’s time to migrate those
> checkouts. See https://github.com/WebKit/WebKit/wiki/Migration for
> details on how to migrate from an existing checkout
> or https://github.com/WebKit/WebKit/wiki/Contributing#checking-out-We
> bKit for starting fresh. We intend to keep our defunct remotes
> available for a few weeks to ease the transitions, but starting
> Thursday, these 3 remotes will not be receiving new commits.
> 
> Please reach out if you have any issues,
> 
> Jonathan Bedard
> WebKit Continuous Integration
> ___
> 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] Miguel Gomez is now WebKit reviewer

[Carlos Garcia Campos via webkit-dev]

Hi,

I'm happy to announce that Miguel Gomez is now WebKit reviewer. Miguel
has a lot of experience in WebKitGTK and WPE graphics, so he is the
perfect reviewer now for graphics related patches for GTK/WPE.

Please join me in congratulating Miguel!

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

Re: [webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Carlos Garcia Campos]

El mar, 14-01-2020 a las 05:06 +1100, Dean Jackson escribió:
> 
> 
> > On 13 Jan 2020, at 20:14, Carlos Garcia Campos  > > wrote:
> > 
> > El lun, 13-01-2020 a las 05:30 +1100, Dean Jackson escribió:
> > > Dear Non-Apple ports,
> > > 
> > > Running Flash has been more difficult over the past few years as
> > > part
> > > of a (semi-) coordinated effort by browsers and Adobe. The plan
> > > is to
> > > remove support for Flash + NPAPI by the end of this year. See the
> > > links below. 
> > > 
> > > I'd like to remove our NPAPI code soon, but I want to make sure
> > > the
> > > other ports are ok with this. Please speak up if you have a
> > > reason to
> > > keep it in.
> > 
> > WPE has never supported NPAPI plugins and the GTK port removed the
> > support for GTK2 plugins (flash) already in our current stable
> > version.
> > Plugins not using GTK at all (or using GTK3) are still supported by
> > GTK
> > port (some of them only under X11, though). I'm ok with removing
> > the
> > NPAPI plugins support in the GTk port, but we are at the end of the
> > release cycle, so I prefer if we remove the feature right after we
> > branch for the next stable version (scheduled for the 1st
> > February). I
> > could even branch earlier if needed.
> 
> Waiting until February is totally ok with me. Good luck with your
> release.

We have already branched, so we can start removing NPAPI plugins from
trunk :-)

> Dean
> 
> > > [Note that we will still have some plugin code e.g. our internal
> > > PDFPlugin, just no support for externally installed plugins]
> > > 
> > > Dean
> > > 
> > > * Adobe's end of life for Flash - 
> > > https://theblog.adobe.com/adobe-flash-update/
> > > * Chrome removing Flash support by end of 2020 - 
> > > https://sites.google.com/a/chromium.org/dev/flash-roadmap
> > > * Google removing support for Flash by end of 2020 - 
> > > https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
> > > * Mozilla removing NPAPI by end of 2020 - 
> > > https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
> > > * Mozilla only uses NPAPI for Flash - 
> > > https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
> > > 
> > 
> > Thanks!
> > 
> > ___
> > 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] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Carlos Garcia Campos]

El lun, 13-01-2020 a las 05:30 +1100, Dean Jackson escribió:
> Dear Non-Apple ports,
> 
> Running Flash has been more difficult over the past few years as part
> of a (semi-) coordinated effort by browsers and Adobe. The plan is to
> remove support for Flash + NPAPI by the end of this year. See the
> links below. 
> 
> I'd like to remove our NPAPI code soon, but I want to make sure the
> other ports are ok with this. Please speak up if you have a reason to
> keep it in.

WPE has never supported NPAPI plugins and the GTK port removed the
support for GTK2 plugins (flash) already in our current stable version.
Plugins not using GTK at all (or using GTK3) are still supported by GTK
port (some of them only under X11, though). I'm ok with removing the
NPAPI plugins support in the GTk port, but we are at the end of the
release cycle, so I prefer if we remove the feature right after we
branch for the next stable version (scheduled for the 1st February). I
could even branch earlier if needed.

> [Note that we will still have some plugin code e.g. our internal
> PDFPlugin, just no support for externally installed plugins]
> 
> Dean
> 
> * Adobe's end of life for Flash - 
> https://theblog.adobe.com/adobe-flash-update/
> * Chrome removing Flash support by end of 2020 - 
> https://sites.google.com/a/chromium.org/dev/flash-roadmap
> * Google removing support for Flash by end of 2020 - 
> https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
> * Mozilla removing NPAPI by end of 2020 - 
> https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
> * Mozilla only uses NPAPI for Flash - 
> https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
> 

Thanks!

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

[webkit-dev] WebKit2 owners help for GTK and WPE

[Carlos Garcia Campos]

Hi, 

this week we reach our feature/API freeze in both GTK+ and WPE release
schedules, and we have a few bug adding new features/API blocked on
WebKit2 owner approval for several weeks. We would appreciate if some
WebKit2 owner could take a look at the patches to review the cross-
platform changes. 

[GTK][WPE] Add content extensions support in WKTR and unskip layout tests
https://bugs.webkit.org/show_bug.cgi?id=193622

[WPE] Add API for webview background color configuration
https://bugs.webkit.org/show_bug.cgi?id=192305

[GTK][WPE] Need a function to convert internal URI to display ("pretty") URI
https://bugs.webkit.org/show_bug.cgi?id=174816

[GTK][WPE] Add web extensions API to whitelist access to a security origin
https://bugs.webkit.org/show_bug.cgi?id=193489

Thanks!

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

Re: [webkit-dev] OWNERS policy

[Carlos Garcia Campos]

El jue, 22-02-2018 a las 00:19 -0800, Maciej Stachowiak escribió:
> > On Feb 21, 2018, at 11:06 PM, Carlos Garcia Campos <carlosgc@webkit
> > .org> wrote:
> > 
> > El mié, 21-02-2018 a las 13:49 -0800, Ryosuke Niwa escribió:
> > > If there was any confusion, WebKit2 Owner's policy is still
> > > active
> > > and in effect.
> > 
> > And maybe it's time to get rid of it? I never liked the idea, but I
> > have to admit it made sense at the time it was done. The WebKit2
> > development was on fire and wk2 developers couldn't spend time
> > dealing
> > with build failures on other ports that would slow down the
> > development
> > pace. Nowadays, WebKit2 doesn't really exist, it's WebKit again,
> > and
> > the old WebKit is considered legacy. We no longer need a policy.
> > Removing the policy doesn't mean not owners will do any kind of
> > changes, I think we all know when to ask other developers for a
> > second
> > review or approval. The same we have always done in other
> > components
> > jsc, WebCore, WTF that don't have an owners policy.
> 
> Some of us at Apple have discussed changing it, but nothing to
> announce yet.
> 
> I do think we have problems with people reviewing things that they
> aren't fully qualified to review, but that happens throughout the
> whole tree. So that logically leads to the conclusion of either no
> OWNERS or OWNERS everywhere.

Well, I don't think the current owners policy is about being qualified
to review patches, because non-apple developer are not allowed to be
there. That would mean there aren't non-apple reviewers qualified to
review patches under WebKit directory. Who is better qualified than
Brian, Joe or me to review Automation patches? None of us are WebKit2
owners, though.

I don't think an owners policy would solve the problem of people
reviewing patches without being fully qualified. If we actually have a
problem with that, I guess they are very few cases, so we should be
able to handle them individually. We could simply rollout the offending
commit and discuss the situation with the reviewer in the reviewers
list. Common sense is the best policy here. If needed we could even set
a procedure to remove reviewer status to someone if we think he/she is
not behaving as expected by a WebKit reviewer.

> > 
> > > In the case you aren't sure of the right reviewer, you can send a
> > > bulk email to all of us. I get cc'ed on every WebKit bug with Mac
> > > EWS/CQ failure, and as such, I ignore all WebKit bugs I'm cc'ed
> > > unless the bug title is of my interest.
> > > 
> > > - R. Niwa
> > > 
> > > On Wed, Feb 21, 2018 at 1:27 PM, youenn fablet <youe...@gmail.com
> > > >
> > > wrote:
> > > > Hi Don,
> > > > 
> > > > I am not sure there is a well defined policy.
> > > > If we want to continue with owners, it would indeed be good to
> > > > make
> > > > it clearer and more functional.
> > > > 
> > > > Here is my current understanding.
> > > > The multi-process architecture is now well in place so things
> > > > like
> > > > updating IPC encoders/decoders might no longer require a
> > > > dedicated
> > > > owner scrutiny.
> > > > Exposing the right WK2 APIs is more sensitive on the other
> > > > hand.
> > > > 
> > > >   Y
> > > > 
> > > > Le mer. 21 févr. 2018 à 12:52, <don.olmst...@sony.com> a écrit
> > > > :
> > > > > Hi WebKittens,
> > > > > 
> > > > > As you know we're working on getting WinCairo running on
> > > > > modern
> > > > > WebKit. We're working through a backlog of patches we have to
> > > > > upstream and are sometimes running into issues where we can't
> > > > > find reviewers for our code.
> > > > > 
> > > > > Here are some bugs with attachments that have been hanging
> > > > > out
> > > > > for over 5 days.
> > > > > 
> > > > > https://bugs.webkit.org/show_bug.cgi?id=182870
> > > > > https://bugs.webkit.org/show_bug.cgi?id=182869
> > > > > https://bugs.webkit.org/show_bug.cgi?id=182751
> > > > > 
> > > > > One thing we're unclear on is the OWNERS policy. The list
> > > > > itself
> > > > > is pretty small and has no guidance on who might be the right
> > > > > person(s) to assign a bug to when touching shared code. It
> > > > >

Re: [webkit-dev] Move to NavigationClient

[Carlos Garcia Campos]

El vie, 20-10-2017 a las 13:30 -0700, Alex Christensen escribió:
> Right now we have an API::LoaderClient, API::PolicyClient and an
> API::NavigationClient.  We intend to remove the first two in the
> future in favor of the API::NavigationClient.  I have been working to
> add calls to the NavigationClient to make it a replacement for the
> LoaderClient and PolicyClient.  The linux ports, however, have
> WebKitPolicyClient and WebKitLoaderClient.  Could someone working on
> Linux replace these with an implementation of API::NavigationClient?

WIP patch and questions in:
https://bugs.webkit.org/show_bug.cgi?id=178720


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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Carlos Garcia Campos]

El mar, 27-06-2017 a las 18:19 +0200, Carlos Garcia Campos escribió:
> El vie, 16-06-2017 a las 09:43 -0700, Brady Eidson escribió:
> [...]
> > > > If not, I can get rid of it right now
> > > > 
> > > > If so, then I need a GTK maintainer to come up with a plan
> > > > soon.
> > > 
> > > How soon is soon? :-) We are approaching the end of our release
> > > cycle,
> > > it would be good for us if we could do any changes related to
> > > this
> > > after we branch for 2.18. Of course I can branch earlier if
> > > needed.
> > > According to our schedule we should branch the first week of
> > > August. Is
> > > that late?
> > 
> > That’s much later than the soon I was targeting.
> > 
> > Hoping to do this by the end of June.
> 
> Ok, I've found time today to work on this. I don't have time to re-
> implement WebKitFaviconDatabase using a different database model, so
> I've copied IconDatabase from WebCore to WebKit and used it directly
> from WebKitFaviconDatabase. I've switched the client implementation
> to
> API::IconLoadingClient too. So, I think you can just remove all the
> WebCore and WebKit2 code after the patch lands.
> 
> https://bugs.webkit.org/show_bug.cgi?id=173877

I forgot to say that copying IconDatabase is just a temporary solution,
because I don't have time for a proper solution now, so during our next
release cycle I'll try to either improve or replace it with a new
implementation that allows to store multiple icons and sizes for the
same page, etc.

> 
> Regards, 
> ___
> 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] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Carlos Garcia Campos]

El vie, 16-06-2017 a las 09:43 -0700, Brady Eidson escribió:
[...]
> > > If not, I can get rid of it right now
> > > 
> > > If so, then I need a GTK maintainer to come up with a plan soon.
> > 
> > How soon is soon? :-) We are approaching the end of our release
> > cycle,
> > it would be good for us if we could do any changes related to this
> > after we branch for 2.18. Of course I can branch earlier if needed.
> > According to our schedule we should branch the first week of
> > August. Is
> > that late?
> 
> That’s much later than the soon I was targeting.
> 
> Hoping to do this by the end of June.

Ok, I've found time today to work on this. I don't have time to re-
implement WebKitFaviconDatabase using a different database model, so
I've copied IconDatabase from WebCore to WebKit and used it directly
from WebKitFaviconDatabase. I've switched the client implementation to
API::IconLoadingClient too. So, I think you can just remove all the
WebCore and WebKit2 code after the patch lands.

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


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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Carlos Garcia Campos]

El jue, 15-06-2017 a las 17:11 -0700, Brady Eidson escribió:
> Hi all,
> 
> The IconDatabase in WebCore is the source of crashes, spins, and
> complexity. Additionally it’s not flexible enough to acknowledge that
> there’s multiple types of site icons in use on the modern web, nor to
> adapt to the embedding client’s need for customization.
> 
> I recently introduced the “_WKIconLoadingDelegate” model to
> WebKit2Cocoa.
> 
> WebCore gathers all of the candidate icon URLs and asks the embedding
> app for each one whether or not it wants to load them.
> If the app says yes, the icon will be loaded as a subresource in the
> current document and the data will be handed off to the client.

Do we have any cache here? would we use the disk cache like with any
other subresource?

> From Apple’s perspective:
> 
> The new model is powerful and flexible enough that Safari has adopted
> it.
> In WebKit1, the “WebIconDatabase” class was never API and is
> currently unused.
> In WebKit2, the C-API support was never API and is currently unused.
> 
> Therefore we intend to remove the current WebCore IconDatabase from
> the project soon.

This is great news.

> Starting in on this task, I of course noticed GTK’s API has exposed
> “WebKitFaviconDatabase”
> 
> Is that something that’s published API and that is used?

Yes, it is part of our public API, so we need to keep backwards
compatibility.

> If not, I can get rid of it right now
> 
> If so, then I need a GTK maintainer to come up with a plan soon.

How soon is soon? :-) We are approaching the end of our release cycle,
it would be good for us if we could do any changes related to this
after we branch for 2.18. Of course I can branch earlier if needed.
According to our schedule we should branch the first week of August. Is
that late?

> The icon load delegate mechanism is powerful enough to rebuild an
> IconDatabase on top of, so if GTK needs to keep this API functional
> they can do so - maintaining the actual IconDatabase code themselves
> up in their API layer.

I have to look at it in detail. If I can use the new mechanism to
reimplement WebKitFaviconDatabase, I'll definitely do that. But if
there's no longer a database of favicons, I wouldn't mind to deprecate
it and provide a new better API. But in any case, I need to keep
WebKitFaviconDatabase working, whether using new way or moving the
current IconDatabase to wk2gtk.

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

Re: [webkit-dev] Commits in branches triggering build in the bots now

[Carlos Garcia Campos]

El jue, 04-05-2017 a las 09:51 -0700, Alexey Proskuryakov escribió:
> Hi Carlos,
> 
> Could you please file a bug, and include the relevant links to
> investigate the issue?

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

> - Alexey
> 
> 
> > 4 мая 2017 г., в 0:46, Carlos Garcia Campos <carlo...@webkit.org>
> > написал(а):
> > 
> > I don't know what have changed, but now, commits in other branches
> > are
> > triggering builds in the bots. I have just realized after merging a
> > couple of commits in GTK+ stable branch. This didn't happen before,
> > those commits didn't show in the bots at all. 
> > 
> > Any idea why is this happening now? I don't see any relevant change
> > in
> > the buildbot config. For now I'll stop merging commits because I
> > don't
> > want the bots to waste the time building and running tests when
> > nothing
> > has actually changed.
> > 
> > Thanks, 
> > Carlos Garcia Campos
> > ___
> > 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] Commits in branches triggering build in the bots now

[Carlos Garcia Campos]

I don't know what have changed, but now, commits in other branches are
triggering builds in the bots. I have just realized after merging a
couple of commits in GTK+ stable branch. This didn't happen before,
those commits didn't show in the bots at all. 

Any idea why is this happening now? I don't see any relevant change in
the buildbot config. For now I'll stop merging commits because I don't
want the bots to waste the time building and running tests when nothing
has actually changed.

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

Re: [webkit-dev] !!Tests for equality comparison

[Carlos Garcia Campos]

El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
> Hello C++ fans!
> 
> The C++ style check currently say:
> Tests for true/false, null/non-null, and zero/non-zero should all be
> done without equality comparisons
> 
> I totally agree for booleans and pointers… but not for integers. I
> know it’s pretty much the same thing, but I it takes me slightly
> longer to process code like this:
> 
> int numTestsForEqualityComparison = 0:
> // Count ‘em!
> // …
> if (!numTestsForEqualityComparison)
>   printf(“Good job!”);
> 
> I read it as “if not number of tests for equality comparison”. That's
> weird. It takes me every slightly longer to think about, and I’ve
> gotten it wrong a bunch of times already. I’m not trying to check for
> “notness", I’m trying to say “if there were zero tests for equality
> comparison”, a.k.a.:
> 
> if (numTestsForEqualityComparison == 0)
>   printf(“Good job!”);
> 
> So how about the C++ style let me just say that? I’m not suggesting
> we advise using that style for integers everywhere, I’m just saying
> it should be acceptable to check zero/non-zero using equality
> comparison.

I agree, it's also quite confusing when using strcmp, because !strcmp
means the strings are equal. It's not only more difficult to read, I've
seen patches with wrong strcmp checks because of that.

> 
> !!Thanks (i.e. many thanks),
> 
> JF
> 
> p.s.: With you I am, fans of Yoda comparison, but for another day
> this will be.
> ___
> 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: upstream the WPE port

[Carlos Garcia Campos]

El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:
> > On Apr 22, 2017, at 6:21 AM, Michael Catanzaro  > om> wrote:
> > 
> > I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
> > would be much better for us.
> 
> I as long as the GTK and WPE ports like this plan (it appears they
> both are) and are both committed to see it to fruition (it appears
> they both are), then I fully support this.
> 
> I do *not* support adding another client of the C API, even in the
> interim.

It would be easier for us to move to the new API after the port is
upstream, since it will require refactorings in both ports GTK+ and WPE
. So, we can simply remove from the current patch anything added to the
C API (except the web view implementation or whatever is needed by WTR)
and then work on moving to the new API in follow up patches.

Are you ok with that?

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

Re: [webkit-dev] Proposal: upstream the WPE port

[Carlos Garcia Campos]

El sáb, 22-04-2017 a las 08:09 -0500, Michael Catanzaro escribió:
> On Sat, Apr 22, 2017 at 1:14 AM, Carlos Garcia Campos 
> <carlo...@webkit.org> wrote:
> > The easiest way would be to reuse the GTK+ API. WPE has the same
> > dependencies than the GTK+ port except for GTK+ itself. The GTK+
> > API 
> > of
> > course depend on GTK+, but only for the WebView, and a few other
> > fallback implementations like the file chooser, color chooser,
> > printing, etc, that are, in any case, optional. So, we could move
> > 95%
> > of the GTK+ API to a common glib dir and reuse all that in WPE,
> > only
> > adding a WebView implementation for WPE.
> 
> I'm sure reimplementing WebKitWebView without GTK+ will be a lot of 
> work, and I'm pretty sure it's a lot more than 5% of the current
> API. 

I don't know why you are so sure. The idea is exactly the same to what
the C API was, a cross-platform API where ports only need to provide a
WebView implementation. WPE should already have one for the C API. Note
that I'm not proposing that WPE uses exactly the same WebKitWebView API
than the GTK+ port, but that they provide their own one. Only the
shared part of the API will be exactly the same, of course.

> But I like this plan. It will result in a dramatically better API
> for 
> WPE than what we have now. The cross-platform C API is not very
> good. 
> Our GObject-based GTK+ API is. Why didn't we consider this before? :)

Because everybody involved in WPE, devs and users, were/are happy with
the C API.

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

Re: [webkit-dev] Proposal: upstream the WPE port

[Carlos Garcia Campos]

El vie, 21-04-2017 a las 16:01 -0700, Geoffrey Garen escribió:
> I think the biggest consideration here is the problems we’ve noticed
> in the C API that have produced poor designs that we don’t intend to
> support going forward.
> 
> Does the WPE port’s API need to be backwards-compatible in a source
> or binary way?
> 
> Is it practical for the WPE port’s API to mirror the ObjC API?

The easiest way would be to reuse the GTK+ API. WPE has the same
dependencies than the GTK+ port except for GTK+ itself. The GTK+ API of
course depend on GTK+, but only for the WebView, and a few other
fallback implementations like the file chooser, color chooser,
printing, etc, that are, in any case, optional. So, we could move 95%
of the GTK+ API to a common glib dir and reuse all that in WPE, only
adding a WebView implementation for WPE.

> Thanks,
> Geoff
> 
> > On Apr 21, 2017, at 2:24 PM, Alex Christensen  > om> wrote:
> > 
> > This is exciting news, Zan!  I’m happy to see innovative new uses
> > of WebKit.
> > 
> > What kind of groups hope to use this new port?  What kind of groups
> > hope to maintain this new port?  Will it be beneficial to the
> > WebKit community to have their cooperative work?  I see having more
> > groups motivated to organize things in a supportable way as
> > positive.
> > 
> > I don’t think we should just use the C API as it is.  We want to
> > eventually remove it completely.  If we do upstream WPE, I propose
> > doing something like one of the following:
> > 1. We could make a new C API that more closely mirrors the Cocoa
> > API, to which we only add things we have committed to
> > support.  This should be done in collaboration with the existing
> > API owners.
> > 2. We could mark parts of the existing C API as part of the API we
> > have committed to maintaining.  There is a lot of messy stuff in
> > the existing C API we eventually want to remove even before we
> > remove the whole thing (old client versions, testing-only
> > functions, private functions that access things we want to
> > eventually organize differently, etc.).  For example, a lot of the
> > things in WKContextPrivate.h should be moved from a multi-process-
> > global approach to a WKWebView/WKPage-based organization.  The
> > basic concepts are here to stay, though.
> > 3. Have third parties who use the API just deal with whatever
> > changes we throw at them.  This could be viable if there were only
> > a few small groups using the API, but it would hinder innovative
> > use of the API.  We might want to reserve the right to make API
> > breaking changes anyway, though.
> > 
> > > On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote:
> > > 
> > > Hi,
> > > 
> > > the WebKit team at Igalia would like to propose upstreaming the
> > > WPE port
> > > of WebKit, taking on the duty to maintain it alongside the GTK+
> > > port.
> > > 
> > > The WPE port started in 2014 as the 'WebKit for Wayland' project
> > > inside
> > > Igalia [1].  The port was derived from the GTK+ port, but avoided
> > > dependency on any GUI toolkit.  It relied on the Wayland display
> > > protocol for on-screen presentation.  That dependency was later
> > > dropped
> > > in favor of using generic interfaces to adapt to different
> > > platform-specific presentation systems.  This allows any vendor
> > > to
> > > simply provide the necessary backend implementations that are
> > > tailored
> > > to their platform.
> > > 
> > > The port is intended to be the Web platform engine of choice for
> > > embedded Linux systems.  Since late 2014 Igalia has been
> > > sponsored by
> > > Metrological to further develop the WPE port, targeting primarily
> > > various set-top box platforms.  Miguel Gomez blogged about this
> > > effort
> > > back in December [2].  The port can also address other embedded
> > > use
> > > cases, for instance in-vehicle infotainment or digital signage.
> > > 
> > > The GTK+ and WPE ports mostly have the same dependencies except
> > > for the
> > > GTK+ toolkit library.  That enables the two ports to already
> > > share a lot
> > > of code.  The biggest difference between the two is that the WPE
> > > port
> > > exposes the WebKit2 C API, while the GTK+ port exposes a GObject-
> > > based
> > > API.  Apart from that, the maintainers' plan is to further align
> > > the two
> > > ports as much as possible, ideally simply stacking the GTK+ port
> > > on top
> > > of WPE, with only a few additional tweaks for GTK+
> > > integration.  This
> > > would lessen the maintenance burden for both ports and the
> > > project as a
> > > whole.
> > > 
> > > The WebKit team at Igalia thinks this port is on stable footing
> > > and has
> > > solid prospects for the future.  That's why we'd like to join the
> > > upstream community and continue our work there.
> > > 
> > > The patch with the port changes is in bug #171110 [3].  We have
> > > existing
> > > x86_64 buildbot configurations [4] that we would have to port
> > > over 

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

[Carlos Garcia Campos]

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?

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

> 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] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 07:50 +, Rogovin, Kevin escribió:
> 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.

The community enthusiasm will depend on how this performs in the end in
 web browser benchmarks, as others said in this thread. But to check
that you need to implement GraphicsContext first, so that's a bit
chicken-egg problem. 

What I can say as the GTK+ port maintainer is that we are very
interested in this. We are actually looking for a cairo replacement,
because unfortunately cairo is nowadays pretty much unmaintained. So,
if FastUIDraw can be used by the GTK+ port to replace cairo, and the
performance improvement is so impressive we would definitely switch.

You could start working on it on branch, we can help you with the
WebKit internal details (#webkitgtk+ on freenode, or webkit-gtk@lists.w
ebkit.org). And once you have something working we will also help you
to upstream your changes.

> Best Regards,
>  -Kevin Rogovin
> 
> -Original Message-
> From: Carlos Garcia Campos [mailto:carlo...@webkit.org] 
> Sent: Thursday, November 3, 2016 9:43 AM
> To: Rogovin, Kevin <kevin.rogo...@intel.com>; Myles C. Maxfield  fi...@apple.com>
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
> > Hi,
> > 
> >  The main issue of making a Cairo backend to FastUIDraw is
> > clipping.
> > Cairo tracks the clipping region in CPU and does things that are
> > fine 
> > for CPU-based rendering (i.e. span based rendering) but are
> > absolutely 
> > awful for GPU rendering (from my slides, one sees that GL backed 
> > QPainter and Cairo do much worse than CPU backed). FastUIDraw only 
> > supports clipIn and clipOut and pushes all the clipping work to
> > the 
> > GPU with almost no CPU work. It does NOT track the clipping region
> > at 
> > all. I can give more technical details how it works (and those
> > details 
> > are why FastUIDraw cannot be used a backend for Cairo).
> > For those interested in where the code is located for clipping in 
> > FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
> > methods clipInRect, clipOutPath and clipInPath. Their
> > implementations 
> > are very short and simple and are quite cheap on CPU.
> 
> I see. Then I guess adding a new GraphicsContext for FastUIDraw is
> the easiest and best way to try this out in WebKit. Would it be
> possible to  just add a new GraphicsContext implementation? or would
> you also need to change other parts of the graphics implementation or
> the GraphicsContext API itself?
> 
> > Best Regards,
> > -Kevin
> > 
> > -Original Message-
> > From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
> > Sent: Thursday, November 3, 2016 9:27 AM
> > To: Rogovin, Kevin <kevin.rogo...@intel.com>; Myles C. Maxfield
> > <mmax 
> > 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

Re: [webkit-dev] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
> Hi,
> 
>  The main issue of making a Cairo backend to FastUIDraw is clipping.
> Cairo tracks the clipping region in CPU and does things that are fine
> for CPU-based rendering (i.e. span based rendering) but are
> absolutely awful for GPU rendering (from my slides, one sees that GL
> backed QPainter and Cairo do much worse than CPU backed). FastUIDraw
> only supports clipIn and clipOut and pushes all the clipping work to
> the GPU with almost no CPU work. It does NOT track the clipping
> region at all. I can give more technical details how it works (and
> those details are why FastUIDraw cannot be used a backend for Cairo).
> For those interested in where the code is located for clipping in
> FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
> methods clipInRect, clipOutPath and clipInPath. Their implementations
> are very short and simple and are quite cheap on CPU.

I see. Then I guess adding a new GraphicsContext for FastUIDraw is the
easiest and best way to try this out in WebKit. Would it be possible to
 just add a new GraphicsContext implementation? or would you also need
to change other parts of the graphics implementation or the
GraphicsContext API itself?

> Best Regards,
> -Kevin
> 
> -Original Message-
> From: Carlos Garcia Campos [mailto:carlo...@webkit.org] 
> Sent: Thursday, November 3, 2016 9:27 AM
> To: Rogovin, Kevin <kevin.rogo...@intel.com>; Myles C. Maxfield  fi...@apple.com>
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> El jue, 03-11-2016 a las 06:58 +, Rogovin, Kevin escribió:
> > Hi!
> >  
> > Question answers:
> > 1.  Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL
> > ES 
> > 3.0. One of its design goals is to make it not terribly awful to
> > write 
> > a backend to different 3D API’s.
> > 2.  I think I was unclear in my video. I have NOT migrated ANY
> > UI 
> > rendering library to use Fast UI Draw. What I have done is made a
> > demo 
> > (painter-cells) and ported that demo to Fast UI Draw, Cairo, Qt’s 
> > QPainter and SKIA. The diffs between the ports is almost trivial
> > (it 
> > really is just using those different rendering API’s).
> 
> That makes me wonder, would it be possible to add a new cairo backend
> based on FastUIDraw? That would make very easy to try it out with the
> current GraphicsContext cairo backend.
> 
> > 3.  There are a few areas:
> > a.  Reduce some render to offscreen buffers. When I worked
> > with 
> > WebKit YEARS ago, I saw a few instances of rendering to texture
> > that 
> > are unnecessary and even harm performance for GPU rendering. The
> > first 
> > example was where a brush pattern with an image and/or gradient 
> > applied is to be drawn tiled across an area. WebKit (at that time) 
> > first drew a single instance of that pattern to an image, then
> > drew 
> > that image tiled. For GPU renderers we can (very easily) just do
> > the 
> > repeat pattern (of both original image and gradient) from a shader.
> > Another instance happens at RenderLayer where a new
> > GraphicsContext 
> > “layer” is started on a transformation that has rotation or 
> > perspective. For FastUIDraw, this is not necessary, though if a
> > layer 
> > is transparent, then it is.
> > b.  In addition, FastUIDraw has an interface so that if “what”
> > is 
> > drawn is unchanged but the “how” changes, then a caller can cache
> > the 
> > “what” to send to the GPU. To be explicit, “what” to draw is 
> > essentially attributes and indices and those values do NOT depend
> > on 
> > the state of “how” to draw. Examples of “how” to draw: current 
> > transformation, brush to apply, clipping applied, stroking
> > parameters 
> > (including dash pattern) and blending mode. I admit that I am
> > quite 
> > proud of being able to use the same attributes an indices even if 
> > stroking parameters (stroking width, miter limit and dash pattern) 
> > change. Text rendering “what” to draw does depend on what glyphs
> > one 
> > wants to use. Specifically, if drawing coverage font glyphs, then 
> > attributes and indices values change if one wants to draw the
> > glyph 
> > biffer, but for the GPU rendered glyphs they do not.
> > 4.  The renderer implements full 3x3 transformations. However,
> > the 
> > renderer does NOT implement out-of-order transparency. For a GPU,
> > a 
> > 3x3 transformation is cheap (naturally!). The renderer does
&g

Re: [webkit-dev] WebKit GPU rendering possibility

[Carlos Garcia Campos]

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 unnecessary and even harm performance for GPU rendering. The
> first example was where a brush pattern with an image and/or gradient
> applied is to be drawn tiled across an area. WebKit (at that time)
> first drew a single instance of that pattern to an image, then drew
> that image tiled. For GPU renderers we can (very easily) just do the
> repeat pattern (of both original image and gradient) from a shader.
> Another instance happens at RenderLayer where a new GraphicsContext
> “layer” is started on a transformation that has rotation or
> perspective. For FastUIDraw, this is not necessary, though if a layer
> is transparent, then it is.
> b.  In addition, FastUIDraw has an interface so that if “what” is
> drawn is unchanged but the “how” changes, then a caller can cache the
> “what” to send to the GPU. To be explicit, “what” to draw is
> essentially attributes and indices and those values do NOT depend on
> the state of “how” to draw. Examples of “how” to draw: current
> transformation, brush to apply, clipping applied, stroking parameters
> (including dash pattern) and blending mode. I admit that I am quite
> proud of being able to use the same attributes an indices even if
> stroking parameters (stroking width, miter limit and dash pattern)
> change. Text rendering “what” to draw does depend on what glyphs one
> wants to use. Specifically, if drawing coverage font glyphs, then
> attributes and indices values change if one wants to draw the glyph
> biffer, but for the GPU rendered glyphs they do not.
> 4.  The renderer implements full 3x3 transformations. However,
> the renderer does NOT implement out-of-order transparency. For a GPU,
> a 3x3 transformation is cheap (naturally!). The renderer does handle,
> with a very little additional overhead changing clipping even between
> nasty rotations or perspective changes. The demo painter-cells
> deliberately pushes and does lots of nasty clipping and the
> performance impact of it on FastUIDraw is very small.
> 5.  Drawing text is a right pain in the rear. Currently,
> FastUIDraw has 3 methods to draw text: coverage, distance field and
> an original GPU algorithm that I devised for another open sourced
> project years ago. Coverage is needed when glyphs are drawn small and
> hinting becomes important. The original GPU algorithm keeps corners
> sharps and does a computation in the fragment shader to compute a
> coverage value. Distance field is a fall back which has render
> quality issues (namely corners are rounded) but is very, very cheap.
> I want to write an additional glyph renderer that is much faster than
> the original GPU method and keeps corners sharp. This new one is to
> use the ideas found in https://github.com/Chlumsky/msdfgen but I have
> a way to make the distance field generation much, much faster and
> handle natively cubics (instead of breaking cubics into quadratics)
>  
> For convenience, below is a list of features FastUIDraw implements:
> 1.  3x3 transformation matrix
> 2.  path stroking with anti-aliasing
> a.  dashed stroking too
> b.  miter, rouned, bevel joins
> c.  flat, square and rounded caps
> 3.  path filling against an arbitrary fill rule
> 4.  “brush”
> a.  linear gradients
> b.  two point conical gradients (I call these radial gradients)
> c.  images
>     i. nearest,
> bilinear and bicubic filtering
> 5.  Clipping
> a.  clipIn against rect or filled path (with arbitrary fill rule)
> b.  clipOut against path (with arbitrary fill rule)
> 6.  Glyph rendering
> a.  coverage fonts
> b.  1-channel distance field
> c.  curve-pair analytic (original algorithm)
> 7.  all 12 Porter-Duff blend modes
>  
> However, I still have work to do:
> 1.  anti-alias path fills
> 2.  anti-alias clipping
> 3.  more glyph rendering work
> 4.  some optimizations related to culling on path-fills
> 5.  dash pattern adjustments from 

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

[Carlos Garcia Campos]

El mar, 20-09-2016 a las 10:39 -0500, Michael Catanzaro escribió:
> On Tue, 2016-09-20 at 18:35 +0900, Fujii Hironori wrote:
> > 
> > I'm interested in bumping cmake_minimum_required for
> > .
> > Which version of CMake is minimum version to be supported?
> 
> Hi,
> 
> WebKitGTK+ intends to continue supporting 2.8.12 until April, when we
> drop support for Ubuntu 14.04. So the new features you want to use
> should be used conditionally on the CMake version being high enough,
> without bumping the minimum requirement.

So, is our deps policy about build-time only dependencies too? I don't
think it should be. We want people to be able to *use* recent
WebKitGTK+ in older distros, mainly because sometimes full upgrade is
the only way to get security updates. But people *building* WebKitGTK+
can build also any dependency that is missing or not recent enough in
their distro. So, I think we should always allow to bump requirements
of build-only dependencies (CMake, GCC/clang, perl, python, ruby, etc.)
if it helps the project maintenance.

> 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] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 08:54 +0200, Carlos Garcia Campos escribió:
> El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > 
> > > 
> > > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos <carlosgc@webki
> > > t.
> > > org> wrote:
> > > 
> > > Does that mean than from the WebIDL point of view all methods can
> > > now
> > > raise a exception? If don't tell the code generator that a method
> > > can
> > > raise a exception, we assume all could return a Exception?
> > 
> > Correct.
> > 
> > Once the transition is done, the IDL will no longer indicate which
> > functions can raise exceptions; the return types of C++ member
> > functions will, instead. During the transition, exceptions can be
> > indicated in either way.
> > 
> > > 
> > > It actually depends on whether this is an exception or not.
> > 
> > I’m not sure exactly what you mean. But I expect us to keep driving
> > JavaScript DOM bindings forward in lots of ways. Here are a few:
> > 
> > - We will add support for more WebIDL features. There are many
> > still
> > to go. In some cases that means removing code that is currently in
> > the DOM that is doing part of the bindings work and using WebIDL to
> > implement this things. For example, translation of strings into
> > enum
> > values. WebIDL includes a specification of how all these features
> > are
> > reflected in JavaScript, but for non-JavaScript bindings we have to
> > define how to reflect each feature.
> > 
> > - We will add better exception messages, which means DOM code has
> > to
> > provide more than an exception code.
> > 
> > - We will update bindings with changes to move the web platform
> > forward, with JavaScript-specific strategies for backward
> > compatibility that won’t necessarily work for other languages such
> > as
> > Objective-C. For example, the latest specifications turn
> > DOMImplementation.hasFeature into a function that ignores its
> > arguments and always returns true. That’s easy to implement with
> > WebIDL for JavaScript, but for GObject and Objective-C we need code
> > somewhere that remembers what the old argument list was.
> > 
> > - We will update bindings with changes that have minimal observable
> > effect in the JavaScript type system but have effects on types of
> > arguments or return values in GObject bindings, such as making a
> > return type more specific (Attr instead of Node) or changing which
> > numeric type is used.
> > 
> > - We will move things currently done in the DOM itself into the
> > bindings.
> > 
> > - We would like to change the bindings generation scripts to run
> > more
> > quickly and so that fewer run when a given IDL source file is
> > changed.
> > 
> > > 
> > > If you really think that build is going to be broken often
> > > because
> > > of things very difficult to do in the GObject bindings, then we
> > > should indeed find a more general solution. Otherwise I prefer to
> > > solve this problem now, and keep the existing way of generating
> > > the
> > > bindings. We can add a rule that you can break the GObject DOM
> > > bindings build, to not block your work, and I'll try to fix it
> > > asap
> > > as we currently do with WebKit2.
> > 
> > Something like this might work. But coping with these changes is
> > going to be challenging.
> > 
> > I expect we are going to continue to run into many things we want
> > to
> > do for JavaScript that are difficult to do in the GObject bindings.
> > It’s taken many people hundreds of hours already to add these
> > various
> > WebIDL features for the JavaScript bindings, and each one involved
> > changing both the bindings and the underlying DOM implementation.
> > 
> > I think the 88 already existing #if statements in the IDL are one
> > indication that the IDL-based code generation strategy isn’t
> > working
> > very well; *many* features that are simply not supported outside
> > the
> > JavaScript code generator because they use one of the newer IDL
> > features are another.
> > 
> > If you read the latest WebIDL draft <https://heycam.github.io/webid
> > l/
> > > 
> > > you will see lots of features that are tricky to deal
> > with—dictionary types, enumeration types, callback function types,
> > promise types, union types, regular expressions, frozen arrays,
> > stringifiers,

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 19:00 +0200, Carlos Garcia Campos escribió:
[...]
> I just need some time, I'm very busy this week because I have to make
> a
> new branch for WebKitGTK+ 2.14 and prepare a new release. Good thing
> is
> that I made the branch today, so changes in trunk are less risky for
> us
> now, and I plan to make the release tomorrow. As soon as the release
> is
> out, I'll start working on the bindings freeze.

I've just attached a patch here:
https://bugs.webkit.org/show_bug.cgi?id=161438

For now I've copied all the generated code, as a first step, but I
think we can actually remove a lot of code from the unstable part that
nobody is using. But before removing anything, I need to check what
unstable APIs applications are using and ask the WebKitGTK+ community.
Then I'll move all that to the stable part and remove the rest of the
unstable API, since we can add any new API on demand if any
applications need it.

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

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 09:52 -0700, Darin Adler escribió:
> Thanks for the frank discussion, guys.
> 
> I do think we may be able to make the GObject bindings better and
> better over time even if they are hand written rather than generated.

Exactly.

> I understand that you want to keep them vital and up to date in a way
> that the Apple folks are not planning to do for the Objective-C
> bindings. Given the goal to have them be stable even while adding new
> capabilities with new ones, I hope it will be practical to make them
> great without using automatic generation.

We split the API long time ago and since then we have never added new
methods/properties to the stable part, and very few applications use
the unstable part (and they only use one or two methods). So, I don't
think it will be a problem at all to stop auto-generating them.

> I also think it’s worth further discussion with some of the folks at
> Apple who also want to make sure we have great API for use inside
> injected bundles. We might come up with some idea that is excellent
> both for Cocoa and GTK.
> 
> Can we plan how to do the transition off of automatic generation now,
> or is there anyone else we should consult?

I just need some time, I'm very busy this week because I have to make a
new branch for WebKitGTK+ 2.14 and prepare a new release. Good thing is
that I made the branch today, so changes in trunk are less risky for us
now, and I plan to make the release tomorrow. As soon as the release is
out, I'll start working on the bindings freeze.

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

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 06:10 -0500, Michael Catanzaro escribió:
> I'm OK with freezing the bindings. I'm disappointed in that these are
> a
> killer feature for us and they'll never get improved now, but
> generating them seems to be causing too many problems that we cannot
> easily solve.

why do you say they are never going to be improved? we haven't even
started to decide what we are going to do. The only change for now is
that they are not going to be auto-generated.

> On Tue, 2016-08-30 at 08:54 +0200, Carlos Garcia Campos wrote:
> > 
> > haha, no, of course I'm not, but I'm not Ok with the WebKit2 rules
> > either and I just live with that :-) Anyway, I think freezing the
> > GObject API is harmless and it's better for everybody.
> 
> The difference is that the GObject bindings are a seriously difficult
> issue for Apple that materially slows down their development (or at
> least appears to me to do so). It's impressive how much extra effort
> Apple devs (hi Chris) have spent trying to keep our bindings building
> (thanks!), but I don't think it's reasonable to expect them to do so.
> As much as we appreciate it, really nobody should be spending an
> afternoon uploading speculative patches to try to please our bindings
> generator. Anyway, if we freeze the API, this becomes a moot point.
> 
> WebKit2 is totally different. When WebKit2 breaks (which has
> fortunately become much rarer nowadays than it used to be) it's
> usually
> something very very easy to fix -- a function gains an extra
> parameter
> or a pointer becomes a reference or something -- and it just feels
> borderline spiteful to not spend five minutes with 'git grep' to
> avoid
> breaking us. It's not as if WebKit2 is somehow less important to us
> than WebCore

I guess you never had to deal with any failure.

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

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos <carlosgc@webkit.
> > org> wrote:
> > 
> > Does that mean than from the WebIDL point of view all methods can
> > now
> > raise a exception? If don't tell the code generator that a method
> > can
> > raise a exception, we assume all could return a Exception?
> 
> Correct.
> 
> Once the transition is done, the IDL will no longer indicate which
> functions can raise exceptions; the return types of C++ member
> functions will, instead. During the transition, exceptions can be
> indicated in either way.
> 
> > It actually depends on whether this is an exception or not.
> 
> I’m not sure exactly what you mean. But I expect us to keep driving
> JavaScript DOM bindings forward in lots of ways. Here are a few:
> 
> - We will add support for more WebIDL features. There are many still
> to go. In some cases that means removing code that is currently in
> the DOM that is doing part of the bindings work and using WebIDL to
> implement this things. For example, translation of strings into enum
> values. WebIDL includes a specification of how all these features are
> reflected in JavaScript, but for non-JavaScript bindings we have to
> define how to reflect each feature.
> 
> - We will add better exception messages, which means DOM code has to
> provide more than an exception code.
> 
> - We will update bindings with changes to move the web platform
> forward, with JavaScript-specific strategies for backward
> compatibility that won’t necessarily work for other languages such as
> Objective-C. For example, the latest specifications turn
> DOMImplementation.hasFeature into a function that ignores its
> arguments and always returns true. That’s easy to implement with
> WebIDL for JavaScript, but for GObject and Objective-C we need code
> somewhere that remembers what the old argument list was.
> 
> - We will update bindings with changes that have minimal observable
> effect in the JavaScript type system but have effects on types of
> arguments or return values in GObject bindings, such as making a
> return type more specific (Attr instead of Node) or changing which
> numeric type is used.
> 
> - We will move things currently done in the DOM itself into the
> bindings.
> 
> - We would like to change the bindings generation scripts to run more
> quickly and so that fewer run when a given IDL source file is
> changed.
> 
> > If you really think that build is going to be broken often because
> > of things very difficult to do in the GObject bindings, then we
> > should indeed find a more general solution. Otherwise I prefer to
> > solve this problem now, and keep the existing way of generating the
> > bindings. We can add a rule that you can break the GObject DOM
> > bindings build, to not block your work, and I'll try to fix it asap
> > as we currently do with WebKit2.
> 
> Something like this might work. But coping with these changes is
> going to be challenging.
> 
> I expect we are going to continue to run into many things we want to
> do for JavaScript that are difficult to do in the GObject bindings.
> It’s taken many people hundreds of hours already to add these various
> WebIDL features for the JavaScript bindings, and each one involved
> changing both the bindings and the underlying DOM implementation.
> 
> I think the 88 already existing #if statements in the IDL are one
> indication that the IDL-based code generation strategy isn’t working
> very well; *many* features that are simply not supported outside the
> JavaScript code generator because they use one of the newer IDL
> features are another.
> 
> If you read the latest WebIDL draft <https://heycam.github.io/webidl/
> > you will see lots of features that are tricky to deal
> with—dictionary types, enumeration types, callback function types,
> promise types, union types, regular expressions, frozen arrays,
> stringifiers, serializers, indexed properties, named properties,
> overloading, map like, setlike—the only reason this is not a crisis
> is that many web APIs are old and so not built on any of these new
> concepts. Over time, critical features are being built on them.

Ok, I think we can freeze the GObject bindings too, and then see how
things go and decide what to do. From the users point of view there
will be no difference, the current API will be available and working.
Then, you can add any new features to WebIDL without having to worry
about GObject bindings and we can take our time to discuss what to do.

> I am OK with the “it is OK to break the GObject bindings build”
> strategy, I guess, but are you sure you are 

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 07:54 -0500, Michael Catanzaro escribió:
> On Mon, 2016-08-29 at 14:45 +0200, Carlos Garcia Campos wrote:
> > 
> > I agree this is not ideal for a GObject API, but I really don't see
> > how
> > this is a major problem, to be honest.
> 
> The problem is that you would either have to check for errors on
> every
> function call, including the 95% of function calls that cannot throw
> errors, or just ignore all errors.

That's why I asked Darin if now all DOM methods can raise exceptions,
because that information is no longer in the idl. If we keep the GError
model, we would need to add a GError parameter to every public method,
so that would be the same problem. If we change the exception model and
we know which methods can raise exceptions we can simply document it.

I see a problem for gobject-instrospection bindings more than C
developers.

> I guess if most API users ignore errors, it's not such a big deal.
> 
> Michael
> 
-- 
Carlos Garcia Campos

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

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 07:21 -0500, Michael Catanzaro escribió:
> On Mon, 2016-08-29 at 10:16 +0200, Carlos Garcia Campos wrote:
> > 
> > We basically have a Exception member
> > in WebKitDOMObject base class that is reset for every method call,
> > and
> > set in case of exception. Then we add
> > webkit_dom_object_get_exception()
> > to query if there were a exception. That's not the GLib way, but
> > DOM
> > bindings is a special API anyway.
> 
> It would be a major usability regression for developers. :(
> 

I don't see why. Most of the code using DOM bindings simply ignores the
errors, and existing code is not going to change. I don't see any major
usability issue, neither any regression at all. Is it really a major
usability going from:

GError *error = NULL;
webkit_dom_foo_do_bar (foo, );
if (error) {
    handle_error();
    g_error_free (error);
}

to

webkit_dom_foo_do_bar (foo);
error = webkit_dom_foo_get_error (foo);
if (error)
    handle_error();

It even has advantages, for example if you are not interested in the
error details you can null-check the return value of get_error()
without having to worry about freeing the GError. 

I agree this is not ideal for a GObject API, but I really don't see how
this is a major problem, to be honest.

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

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

o on those and
> we are not easily able to make the gobject bindings come along. There
> are all sorts of new WebIDL features that we cannot easily implement
> for gobject without considerable effort, such as enum and union
> types, various types of overloading and default argument values,
> setlike, the list goes on and on and this has been going on for
> months at least already. There’s a good reason we did this “freezing”
> for Objective-C and it seems likely to be worthwhile for gobject too.
> This will also let us get rid of the 88 places in the IDL files where
> we have gobject-binding-specific #if statements, many of which were
> originally added for Objective-C and probably have not all been
> carefully audited.

That worked for Objective-C because the DOM bindings are no legacy
WebKit, but that's not the case of the GObject bindings. I never liked
the ifdefs in the idl files, maybe we can find a different way to move
that to the code generator itself to skip whatever.

> 
> Option 2) Express the list of which functions have a GError** out
> argument as an explicit list of function names inside the gobject
> bindings generator and generate code accordingly. This is not all
> that farfetched given we already have .symbols files to help keep the
> set of gobject bindings functions stay stable, and there is already a
> list inside the bindings generator of functions that used to raise
> exceptions and therefore have a GError** out argument that is never
> used, showing that this issue is not a new one. Compared to (1) this
> is just a stopgap measure. It can keep existing functions working,
> but does not give us a clear path for what to do as we add more and
> more DOM APIs that don’t fit in with what the gobject binding code
> generator can do.

Exceptions are indeed the main cause of API breaks in GObject DOM
bindings, methods that now raise exceptions or the other way around.
New WebIDL features that don't fit in GObject model are not a problem
at all, as long as they don't affect the existing stable API, are there
other features planned that you think can break existing stable API?

> 
> Option 3) Keep the extended attributes telling whether something
> raises exceptions in the IDL files as gobject-specific attributes
> that are ignored by the JavaScript bindings.
> 
> Are there other practical options?

Yes, I think so, at least for the exceptions issue. If there will
actually be more changes like this maybe we need to find another
solution more general. But for the particular case of extensions, I
think we can find a different way to handle exceptions in GObject API.
We are using the GError because it's the GLib way, but it's very
problematic for generated code like this. We are limited to C, so we
can probably move to a global way to ask for exception. this could even
be limited to a particular object. We basically have a Exception member
in WebKitDOMObject base class that is reset for every method call, and
set in case of exception. Then we add webkit_dom_object_get_exception()
to query if there were a exception. That's not the GLib way, but DOM
bindings is a special API anyway. That would allow to change the
methods that can raise exceptions without affecting the API anymore. To
not break the API, we would need to collect the current methods in the
stable API that have a GError parameter, and handle them manually.

> 
> I strongly prefer option 1, and I would like to hear from the people
> who are working to make the gobject bindings work well to get an idea
> of how they feel about this and how they’d like to proceed, before I
> decide what to do.

It actually depends on whether this is an exception or not. If you
really think that build is going to be broken often because of things
very difficult to do in the GObject bindings, then we should indeed
find a more general solution. Otherwise I prefer to solve this problem
now, and keep the existing way of generating the bindings. We can add a
rule that you can break the GObject DOM bindings build, to not block
your work, and I'll try to fix it asap as we currently do with WebKit2.

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

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Garcia Campos]

El sáb, 30-01-2016 a las 20:16 -0800, Filip Pizlo escribió:
> Michael,
> 
> As my original message said, I was wondering if there was any support
> for running some JavaScript tests *in browser*.  run-jsc-stress-tests 
> doesn’t support that because it doesn’t know what a browser is.
> 
> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
> require a browser to run (like JetStream and Speedometer) or have
> significantly different behavior in the browser than in their
> command-line harnesses (like Kraken and Octane).  If you did have a
> bot that ran these tests in some GTK+ or EFL browser, you’d probably
> catch bugs that testing the JSC shell cannot catch.

We should definitely do that. We are quite late already in our release
cycle, so if we are going to switch to B3 at this point, we really need
a lot more testing. 

> -Filip
> 
> 
> > On Jan 30, 2016, at 7:50 PM, Michael Catanzaro  > om> wrote:
> > 
> > On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> > > Do we have Linux bots that run Octane, Speedometer, JetStream and
> > > Kraken in browser?
> > > 
> > > We find that this catches a lot of bugs that none of the other
> > > tests
> > > catch. 
> > > 
> > > -Filip
> > 
> > This is the command that the bots run:
> > 
> > /usr/bin/env ruby Tools/Scripts/run-jsc-stress-tests -j
> > /home/slave/webkitgtk/gtk-linux-64-release-
> > tests/build/WebKitBuild/Release/bin/jsc -o
> > /home/slave/webkitgtk/gtk-
> > linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-
> > results 
> > PerformanceTests/SunSpider/tests/sunspider-1.0
> > PerformanceTests/JetStream/cdjs/cdjs-tests.yaml
> > Source/JavaScriptCore/tests/executableAllocationFuzz.yaml
> > Source/JavaScriptCore/tests/exceptionFuzz.yaml
> > PerformanceTests/SunSpider/no-architecture-specific-
> > optimizations.yaml
> > PerformanceTests/SunSpider/tests/v8-v6
> > Source/JavaScriptCore/tests/mozilla/mozilla-tests.yaml
> > Source/JavaScriptCore/tests/stress LayoutTests/js/regress/script-
> > tests
> > PerformanceTests/SunSpider/profiler-test.yaml LayoutTests/jsc-
> > layout-
> > tests.yaml Source/JavaScriptCore/tests/typeProfiler.yaml
> > Source/JavaScriptCore/tests/controlFlowProfiler.yaml
> > Source/JavaScriptCore/tests/es6.yaml
> > Source/JavaScriptCore/tests/modules.yaml --ftl-jit --
> > 
> > I see SunSpider and JetStream in there, but not the others
> > 
> > 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] Some text about the B3 compiler

[Carlos Garcia Campos]

El dom, 31-01-2016 a las 06:00 +0900, Yusuke SUZUKI escribió:
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and https://bugs.
> webkit.org/show_bug.cgi?id=153711 are landed.

Awesome, thanks for fixing those issues so quickly.

> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
> time to enable B3 in Linux x64 :D

Indeed!

> Regards,
> Yusuke Suzuki
> 
> On Sat, Jan 30, 2016 at 8:09 AM, Filip Pizlo 
> wrote:
> > Follow up on this:
> > 
> > > On Jan 29, 2016, at 11:38 AM, Filip Pizlo 
> > > wrote:
> > > 
> > > I started coverting the documentation to Markdown.  I don’t think
> > > this is a good idea.
> > > 
> > > - Markdown has no definition lists.  The entire IR document is a
> > > definition list.  I don’t want B3’s documentation to be blocked
> > > on this issue.
> > It turns out that it does have them, but they are very weak.  For
> > example, you can’t have code blocks or paragraphs inside them.  We
> > want to have code blocks inside opcode definitions, to show
> > examples.
> > 
> > > - Markdown’s conversion step makes the workflow awkward.  I’m not
> > > going to use some Markdown editing app - that will prevent me
> > > from being able to properly format code examples.  I need a code
> > > editor for that.
> > This was hard to get around.  This isn’t a problem with Markdown,
> > but rather, a problem with using Wordpress to render Markdown that
> > is in svn.  There is no way to preview the Markdown before
> > committing it.  That would lead to unusual problems, where after a
> > patch is landed, the patch author or someone else would have to do
> > a bunch of blind follow-up commits to fix any style issues, like
> > code blocks that don’t fit properly or whatever.
> > 
> > Considering that we will have to be hacking raw HTML inside those
> > Markdown files (due to definition lists), the lack of preview
> > basically means that you have no way of predicting what the your
> > HTML will render like.
> > 
> > > 
> > > I think that this documentation should be HTML.  I don’t think we
> > > should expend a lot of energy to formatting it nicely.  The point
> > > of this document is for it to be read by engineers while they
> > > hack code.
> > I landed raw HTML documentation: http://trac.webkit.org/changeset/1
> > 95841
> > 
> > I filed this bug about improving its style: https://bugs.webkit.org
> > /show_bug.cgi?id=153674
> > 
> > -Filip
> > 
> > 
> > > 
> > > -Filip
> > > 
> > > 
> > > > On Jan 29, 2016, at 10:12 AM, Timothy Hatcher  > > > m> wrote:
> > > > 
> > > > I also added:
> > > > 
> > > > https://webkit.org/documentation/b3/air/ loads /docs/b3/assembl
> > > > y-intermediate-representation.md
> > > > 
> > > > > On Jan 29, 2016, at 10:05 AM, Filip Pizło 
> > > > > wrote:
> > > > > 
> > > > > Thank you!  I'll convert them today. 
> > > > > 
> > > > > -Filip
> > > > > 
> > > > > On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  > > > > com> wrote:
> > > > > 
> > > > > > Markdown is pretty similar to the wiki formatting and very
> > > > > > simple.
> > > > > > 
> > > > > > You can look at a cheatsheet if you login to the blog: http
> > > > > > s://webkit.org/wp/wp-admin/post.php?post=4300=edit
> > > > > > 
> > > > > > I have also used this HTML to Markdown converter before: ht
> > > > > > tp://domchristie.github.io/to-markdown/
> > > > > > 
> > > > > > The pages are created:
> > > > > > 
> > > > > > https://webkit.org/documentation/b3/ loads /docs/b3/bare-bo
> > > > > > nes-backend.md
> > > > > > https://webkit.org/documentation/b3/intermediate-representa
> > > > > > tion/ loads /docs/b3/intermediate-representation.md
> > > > > > 
> > > > > > Once those files are added to SVN, they will get picked up
> > > > > > by the site. I can change those to point to other names if
> > > > > > you want something different.
> > > > > > 
> > > > > > — Timothy Hatcher
> > > > > > 
> > > > > > > On Jan 29, 2016, at 9:34 AM, saam barati  > > > > > > il.com> wrote:
> > > > > > > 
> > > > > > > I'm happy to convert the document to markdown. Can you
> > > > > > > send me your latest revision or post it to the website?
> > > > > > > 
> > > > > > > I usually look at:
> > > > > > > http://daringfireball.net/projects/markdown/syntax
> > > > > > > For a refresher on the syntax.
> > > > > > > 
> > > > > > > Tim, could you create a page that loads the markdown
> > > > > > > file?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Saam
> > > > > > > 
> > > > > > > On Jan 29, 2016, at 12:06 AM, Filip Pizło  > > > > > > om> wrote:
> > > > > > > 
> > > > > > > > I'm all for this but I don't know anything about
> > > > > > > > markdown. 
> > > > > > > > 
> > > > > > > > What's the best way to proceed?
> > > > > > > > 
> > > > > > > > -Filip
> > > > > > > > 
> > > > > > > > On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  > > > > > > > pple.com> wrote:
> > > > > > > > 
> > 

Re: [webkit-dev] NetworkSession

[Carlos Garcia Campos]

El mié, 18-11-2015 a las 15:58 -0800, Alex Christensen escribió:
> As part of this work, I’m also planning to remove the non-
> NetworkProcess code, both run time and compile time. Based on
> discussion at the WebKit contributors’ meeting I assume there is no
> objection to this.  See https://bugs.webkit.org/show_bug.cgi?id=15141
> 8

No objections for GTK port. I guess then the single process model will
become multiple model with max process limit = 1 internally, right?
 That's what we did in epiphany in preparation for this change. Or do
you plan to remove/deprecate the single process model?

> Alex
> 
> > On Nov 9, 2015, at 11:32 AM, Alex Christensen  > om> wrote:
> > 
> > I made new abstractions for loading in WebKit2: NetworkSession and
> > NetworkDataTask.  It is disabled by default right now, but if you
> > switch USE_NETWORK_SESSION to 1, it mostly works on Mac with
> > features like authentication challenges not implemented yet.  I
> > believe these new abstractions fit better with libsoup, but I’d
> > like feedback on what an actual libsoup implementation would need.
> >  I’m planning on removing the ResourceHandle use in WebKit2 and the
> > async/continue callbacks in ResourceHandleClient and ResourceHandle
> > once this work is done.
> > 
> > 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] HA: Problem with -webkit-gradient css option on MIPS platform.

[Carlos Garcia Campos]

El mié, 30-09-2015 a las 07:33 +, Pushkin Andrei escribió:
> A talk about webkitgtk (webkitgtk-1.10.0.tar.xz). Both version build
> from one sources with similar configure options. 
> Why webkit can not show -webkit-gradient on buttons? Is it bug or
> some webkit settings?

WebKitGTK+ 1.10 was released 3 years ago, I would try with a recent
version.

> Andrei Pushkin
> От: mmaxfi...@apple.com [mmaxfi...@apple.com]
> Отправлено: 29 сентября 2015 г. 23:37
> Кому: Pushkin Andrei
> Копия: webkit-dev@lists.webkit.org
> Тема: Re: [webkit-dev] Problem with -webkit-gradient css option on
> MIPS platform.
> 
> 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 <
> > andrei.push...@promwad.com> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows Build Now on VS2015

[Carlos Garcia Campos]

El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió:
 On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote:
  The days of supporting VS2013 are behind us, so if it works with 
  VS2015, go for it.  Not all c++14 features are supported, though. 
   See 
  https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table
   
  I’m not sure what the oldest gcc we support is.
  
 The oldest GCC we support is 4.7.0.

Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused
failures in the database process implementation (see bug #98932).
 
 GCC 5.0 supports all but one C++14 proposal (which covers allocation 
 optimizations and shouldn't be a blocker):
 https://gcc.gnu.org/projects/cxx1y.html

My main concern is how stable those features are in GCC, though.
 
 Clang has full C++14 coverage since version 3.4, but I'm not aware of 
 any incorporated check for a minimal Clang version.
  
   On Aug 14, 2015, at 5:49 AM, Antti Koivisto koivi...@iki.fi 
   wrote:

   Does this mean we can start using (most) C++14 features?


 antti


   On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham 
   bfulg...@apple.com wrote:
   Hi Floks,

   We’ve finished updating the various Windows builds to VS2015. 
   Full regression tests are now completing on these new builds, and 
   seem to be comparable in terms of stability and correctness.

   Please let me know if you encounter any new issues on Windows. I 
   know that EA encountered some JavaScript issues in a prior 
   revision, but I haven’t been able to replicate this problem (at 
   least yet).

   VS2015 is churning out a number of new build warnings, which I 
   hope to address over the coming weeks. It will also likely have 
   some useful static analysis results in the Windows-specific 
   portions of the code that we should evaluate.

   Thanks,

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

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

Re: [webkit-dev] Windows Build Now on VS2015

[Carlos Garcia Campos]

El mar, 25-08-2015 a las 14:29 +0200, z...@falconsigh.net escribió:
 On Tue, Aug 25, 2015, at 12:55 PM, Carlos Garcia Campos wrote:
  El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió:
   On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote:
The days of supporting VS2013 are behind us, so if it works 
with 
VS2015, go for it.  Not all c++14 features are supported, 
though. 
 See 
https://msdn.microsoft.com/en
-us/library/hh567368.aspx#cpp14table
 
I’m not sure what the oldest gcc we support is.

   The oldest GCC we support is 4.7.0.
  
  Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused
  failures in the database process implementation (see bug #98932).
   
 
 The EFL port didn't, to the best of my knowledge.

Ah!, I assumed that with we you meant the GTK+ port :-)

   GCC 5.0 supports all but one C++14 proposal (which covers 
   allocation 
   optimizations and shouldn't be a blocker):
   https://gcc.gnu.org/projects/cxx1y.html
  
  My main concern is how stable those features are in GCC, though.
   
   Clang has full C++14 coverage since version 3.4, but I'm not 
   aware of 
   any incorporated check for a minimal Clang version.

 On Aug 14, 2015, at 5:49 AM, Antti Koivisto koivi...@iki.fi 
 
 wrote:
  
 Does this mean we can start using (most) C++14 features?
  
  
   antti
  
  
 On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham 
 bfulg...@apple.com wrote:
 Hi Floks,
  
 We’ve finished updating the various Windows builds to VS2015. 
 
 Full regression tests are now completing on these new builds, 
 and 
 seem to be comparable in terms of stability and correctness.
  
 Please let me know if you encounter any new issues on 
 Windows. I 
 know that EA encountered some JavaScript issues in a prior 
 revision, but I haven’t been able to replicate this problem 
 (at 
 least yet).
  
 VS2015 is churning out a number of new build warnings, which 
 I 
 hope to address over the coming weeks. It will also likely 
 have 
 some useful static analysis results in the Windows-specific 
 portions of the code that we should evaluate.
  
 Thanks,
  
 -Brent
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
  
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Carlos Garcia Campos]

El mié, 18-03-2015 a las 21:43 -0700, Myles C. Maxfield escribió:
 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. 

Yes!

 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?

This has always been blocked by the existing layering violations, what
are your plans for that? I guess we will have WebCore/platform and
Platform at the same time for a while until all layering violations are
fixed?

See the tracking bug:
https://bugs.webkit.org/show_bug.cgi?id=21354

But there are more, I wrote a script to get the list of violations, it's
in Tools/Scripts/check-for-platform-layering-violations

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

[Carlos Garcia Campos]

El lun, 09-03-2015 a las 14:48 -0700, Maciej Stachowiak escribió:
 Is anyone actually shipping it or planning to ship it? I don’t have a problem 
 with it if it’s being used, but from the thread it didn’t sound like anyone 
 was actually using it.

Or people were using it in their forks and never contributed the build
fix back upstream :-/

  - Maciej
 
  On Mar 9, 2015, at 1:51 PM, Benjamin Poulain benja...@webkit.org wrote:
  
  This is quite different from legacy features we remove all the time. This 
  simple valuable code that happen to be untested because of the lack of 
  ARMv7 infrastructure on the public bots.
  
  Regarding maintenance, I'd be happy to fix bugs in that code.
  
  Benjamin
  
  On 3/9/15 11:34 AM, Maciej Stachowiak wrote:
  Requiring a perf bot to be set up before removing unmaintained code
  seems like a really high bar. What would it take to do a one-shot
  test of whether NEON_INTRINSICS is a perf benefit? Would it show up
  on PLT or on JS perf benchmarks if you compiled with it? If it’s not
  a speedup in its existing form, then it’s probably not worth keeping
  around. If it is, then that might be incentive for someone to get it
  production-ready and on by default for relevant platforms.
  
  Regards, Maciej
  
  On Mar 8, 2015, at 6:56 PM, Benjamin Poulain benja...@webkit.org
  wrote:
  
  That code looks straightforward, the maintenance cost is likely
  low. We just really need a test bot to run that code.
  
  I suggest we wait until we have a ARMv7 perf bot and re-evaluate
  NEON_INTRINSICS.
  
  On 05/03/2015 22:27, Carlos Garcia Campos wrote:
  Yesterday a patch was submitted to fix the build with
  NEON_INTRINSICS, and Ossy pointed out that the build has been
  broken since r170433, and nobody has noticed it until now. So
  that makes me wonder if anybody is actually using that and if it
  even works, because otherwise we should probably remove the
  NEON_INTRINSICS code.
  
  So, is there anybody actually using that (I guess patched
  downstream)?
  
  
  ___ webkit-dev
  mailing list webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
  
  ___ webkit-dev mailing
  list webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
  
  
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


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

[webkit-dev] NEON_INTRINSICS

[Carlos Garcia Campos]

Yesterday a patch was submitted to fix the build with NEON_INTRINSICS,
and Ossy pointed out that the build has been broken since r170433, and
nobody has noticed it until now. So that makes me wonder if anybody is
actually using that and if it even works, because otherwise we should
probably remove the NEON_INTRINSICS code. 

So, is there anybody actually using that (I guess patched downstream)?


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

Re: [webkit-dev] WebKit not rendering images of a local resource (from within Gedit)

[Carlos Garcia Campos]

El lun, 19-01-2015 a las 18:58 +0100, Peter Bittner escribió:
 Hi,
 
 I'm using WebKit to render HTML in a plugin of Gedit, the Gnome text
 editor. The source code is available from
 https://github.com/bittner/gedit-reST-plugin/blob/gedit-3.14/reST/restructuredtext.py#L56

This is the list for WebKit development, you can use
webkit-...@lists.webkit.org for questions about WebKitGTK+.

 Now it looks like WebKit is rendering images from remote resources
 (e.g. http://farm3.static.flickr.com/2256/2259897373_d47ecf0983_o_d.png)
 fine, but local images (e.g. docs/reStPlugin.png) just display as an
 empty box. Interestingly, the size of the box corresponds to the real
 size of the image, but the image itself is not displayed.

Sounds like local images fail to load, probably because they aren't
found (I guess you are not passing the right base URL to the load
method). I don't know much about the python bindings, and it seems you
are using the deprecated WebKit1 API.

 Some details and a screenshot are available from a bug report at
 https://github.com/bittner/gedit-reST-plugin/issues/7
 
 Does this problem sound familiar to someone?
 
 Thanks in advance for any hints,
 Peter
 ___
 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] Žan Doberšek is now WebKit reviewer

[Carlos Garcia Campos]

I'm happy to announce that Žan Doberšek is now a WebKit reviewer.

Žan has contributed to WebKit for more than 6 years working on almost
all areas of WebKit. Mainly focused on the GTk+ port he has also helped
a lot improving the whole codebase, fixing bugs,
cleaning up code, modernizing code using new C++ 11 features, etc. He is
currently leading the new WebKit for Wayland port.

Thank you Žan for all the work you have done so far for WebKit.

Congratulations!

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

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Carlos Garcia Campos]

El mié, 19-11-2014 a las 12:20 -0800, Chris Dumez escribió:
 Hi all,
 
 I recently started updating the WTF::Vector API to use unsigned types
 instead of size_t [1][2], because:
 - WTF::Vector is already using unsigned type for size/capacity
 internally to save memory on 64-bit, causing a mismatch between the
 API and the internal representation [3]
 - Some reviewers have asked me to use unsigned for loop counters
 iterating over vectors (which looks unsafe as the Vector API, e.g.
 size(), returns a size_t).
 - I heard from Joseph that this type mismatch is forcing us (and other
 projects using WTF) to disable some build time warnings
 - The few people I talked to before making that change said we should
 do it

I started this [1] some time ago, copy pasting what Darin told me in a
review. Whatever we decide could be documented there.

 However, Alexey recently raised concerns about this change. it doesn't
 strike him as the right direction. 4Gb is not much, and we should
 have more of WebKit work with the right data types, not less.”.
 I did not initially realize that this change was controversial, but
 now that it seems it is, I thought I would raise the question on
 webkit-dev to see what people think about this.
 
 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA
 
 
 
 [1] http://trac.webkit.org/changeset/176275
 [2] http://trac.webkit.org/changeset/176293
 [3] http://trac.webkit.org/changeset/148891

[1] http://trac.webkit.org/wiki/TypesForSize



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

Re: [webkit-dev] GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

[Carlos Garcia Campos]

El sáb, 08-11-2014 a las 16:27 -0800, Darin Adler escribió:
 Hi folks.
 
 The GTK EWS bot is failing to build, with this error:
 
  Can't open 
  /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom/WebKitDOMCustomUnstable.h:
   No such file or directory at 
  /home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb 
  line 3889.
  
  Generating webkitdomgtk documentation...
  Traceback (most recent call last):
File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 201, in 
  module
  
  generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 152, in 
  generate_documentation_for_config
  return generate_doc(generator, arguments.skip_html)
File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 133, in 
  generate_doc
  generator.generate(not skip_html)
File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 145, in 
  generate
  self._run_gtkdoc_mkdb()
File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 361, in 
  _run_gtkdoc_mkdb
  self._run_command(args, cwd=self.output_dir)
File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 210, in 
  _run_command
  % (args[0], process.returncode))
 
 Is there someone who knows how to fix this?

hmm, a clean build should fix that, I'd say.

 — 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] GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

[Carlos Garcia Campos]

El dom, 09-11-2014 a las 11:07 +0100, Carlos Garcia Campos escribió:
 El sáb, 08-11-2014 a las 16:27 -0800, Darin Adler escribió:
  Hi folks.
  
  The GTK EWS bot is failing to build, with this error:
  
   Can't open 
   /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom/WebKitDOMCustomUnstable.h:
No such file or directory at 
   /home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb
line 3889.
   
   Generating webkitdomgtk documentation...
   Traceback (most recent call last):
 File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 201, 
   in module
   
   generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
 File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 152, 
   in generate_documentation_for_config
   return generate_doc(generator, arguments.skip_html)
 File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 133, 
   in generate_doc
   generator.generate(not skip_html)
 File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 145, in 
   generate
   self._run_gtkdoc_mkdb()
 File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 361, in 
   _run_gtkdoc_mkdb
   self._run_command(args, cwd=self.output_dir)
 File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 210, in 
   _run_command
   % (args[0], process.returncode))
  
  Is there someone who knows how to fix this?
 
 hmm, a clean build should fix that, I'd say.

However, that should never happen, unstable headers shouldn't be scanned
by gtk-doc, so this is revealing a bug in our generate-gtkdoc script.

  — 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] GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

[Carlos Garcia Campos]

El dom, 09-11-2014 a las 11:30 +0100, Carlos Garcia Campos escribió:
 El dom, 09-11-2014 a las 11:07 +0100, Carlos Garcia Campos escribió:
  El sáb, 08-11-2014 a las 16:27 -0800, Darin Adler escribió:
   Hi folks.
   
   The GTK EWS bot is failing to build, with this error:
   
Can't open 
/home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom/WebKitDOMCustomUnstable.h:
 No such file or directory at 
/home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb
 line 3889.

Generating webkitdomgtk documentation...
Traceback (most recent call last):
  File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 
201, in module

generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
  File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 
152, in generate_documentation_for_config
return generate_doc(generator, arguments.skip_html)
  File /home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc, line 
133, in generate_doc
generator.generate(not skip_html)
  File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 145, in 
generate
self._run_gtkdoc_mkdb()
  File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 361, in 
_run_gtkdoc_mkdb
self._run_command(args, cwd=self.output_dir)
  File /home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py, line 210, in 
_run_command
% (args[0], process.returncode))
   
   Is there someone who knows how to fix this?
  
  hmm, a clean build should fix that, I'd say.
 
 However, that should never happen, unstable headers shouldn't be scanned
 by gtk-doc, so this is revealing a bug in our generate-gtkdoc script.

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

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


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

Re: [webkit-dev] Disk cache

[Carlos Garcia Campos]

El lun, 03-11-2014 a las 00:22 -0800, Benjamin Poulain escribió:
 On 11/2/14, 1:11 AM, Carlos Garcia Campos wrote:
  El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:
  On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
  carlo...@webkit.org wrote:
   El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
Hello,
   
   
I'm planning to add an experimental HTTP cache
   implementation to
WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).
   
   Great news!
   
 The main motivations are:
   
   
- Improving performance by bringing the cache closer. For
   example we
can serialize WebKit response objects directly instead of
   converting
to/from platform types.
- Making future innovation around caching easier. Closer
   coordination
between cache and WebKit opens new optimization
   possibilities.
   
   
The cache lives in the network process. Most of the code is
cross-platform. The storage backend uses libdispatch IO
   though it
wouldn't be hard to add a generic posix one too.
   
   Why is it limited to the network process? wouldn't it be
   possible to use
   it also in the web process when shared secondary process model
   is used?
 
 
  The cache ties to NetworkResourceLoader which lives in the network
  process. In principle it would be possible to integrate with the web
  process side resource loader too. However I don't want to support
  multiple configurations during development.
 
 
  It would be good if all WK2 ports would eventually switch to using the
  network process. The current multitude of configurations makes
  networking related code more confusing and less hackable than it needs
  to be.
  The GTK+ port supports the network process, but it's only used when
  multiple secondary process model is used. Some applications prefer the
  single shared secondary process model, and even some of the browser
  users change the default process model of epiphany to single web process
  because it requires fewer resources. So, we could either integrate the
  cache with the web process loader, or use the network process
  unconditionally for all process models. I think for many simple
  applications a single web process is the most efficient model, though.
 I believe it would be better to enable the network process for all 
 process models. Maintaining multiple configurations for marginal gains 
 is not sustainable, especially in the network stack.
 
 You say a single Web Process is the most efficient model for some 
 applications. What is the impact of always enabling the network process on:
 -CPU load?
 -Memory load?
 -Overall performance?

I haven't measured, I was thinking mainly on the overhead of the IPC
traffic required for the network resources.

 Once we know where the problems are, we should work together at reducing 
 the impact. I suspect we can get the network process below 5% overhead.
 
 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] Disk cache

[Carlos Garcia Campos]

El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:
 On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
 carlo...@webkit.org wrote:
 El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
  Hello,
 
 
  I'm planning to add an experimental HTTP cache
 implementation to
  WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).
 
 Great news!
 
   The main motivations are:
 
 
  - Improving performance by bringing the cache closer. For
 example we
  can serialize WebKit response objects directly instead of
 converting
  to/from platform types.
  - Making future innovation around caching easier. Closer
 coordination
  between cache and WebKit opens new optimization
 possibilities.
 
 
  The cache lives in the network process. Most of the code is
  cross-platform. The storage backend uses libdispatch IO
 though it
  wouldn't be hard to add a generic posix one too.
 
 Why is it limited to the network process? wouldn't it be
 possible to use
 it also in the web process when shared secondary process model
 is used?
 
 
 The cache ties to NetworkResourceLoader which lives in the network
 process. In principle it would be possible to integrate with the web
 process side resource loader too. However I don't want to support
 multiple configurations during development.

 
 It would be good if all WK2 ports would eventually switch to using the
 network process. The current multitude of configurations makes
 networking related code more confusing and less hackable than it needs
 to be.

The GTK+ port supports the network process, but it's only used when
multiple secondary process model is used. Some applications prefer the
single shared secondary process model, and even some of the browser
users change the default process model of epiphany to single web process
because it requires fewer resources. So, we could either integrate the
cache with the web process loader, or use the network process
unconditionally for all process models. I think for many simple
applications a single web process is the most efficient model, though.

 
 
 
antti
  
 
 
  The code will be behind NETWORK_CACHE feature flag.
 
 
 
 
antti
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 


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

Re: [webkit-dev] Disk cache

[Carlos Garcia Campos]

El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
 Hello,
 
 
 I'm planning to add an experimental HTTP cache implementation to
 WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).

Great news!

  The main motivations are:
 
 
 - Improving performance by bringing the cache closer. For example we
 can serialize WebKit response objects directly instead of converting
 to/from platform types.
 - Making future innovation around caching easier. Closer coordination
 between cache and WebKit opens new optimization possibilities.
 
 
 The cache lives in the network process. Most of the code is
 cross-platform. The storage backend uses libdispatch IO though it
 wouldn't be hard to add a generic posix one too.

Why is it limited to the network process? wouldn't it be possible to use
it also in the web process when shared secondary process model is used?

 
 The code will be behind NETWORK_CACHE feature flag.
 
 
 
 
   antti
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Carlos Garcia Campos]

El vie, 17-10-2014 a las 12:42 +0200, Sergio Villar Senin escribió:
 On 17/10/14 06:28, Benjamin Poulain wrote:
  It works great! Thanks for updating bugzilla, it is really neat.
  
  Benjamin
 
 Could the format of bz emails be changed? The new one with those huge
 tables on top and tiny fonts for the bug comments are pretty difficult
 to process.

I've always received bz emails in plain text, you can change that in
your prefs, I did it yesterday and now I'm receiving the same emails I
used to.

 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] Determining stable JavaScriptCore revision

[Carlos Garcia Campos]

El mar, 07-10-2014 a las 19:26 -0700, Gary Kratkin escribió:
 Hello, I’m using WebKitGtk 2.4.4. It branched from trunk at r163300 on
 Feb. 03, 2014. That may not have been a great moment for
 JavaScriptCore. The jsCStack branch had recently been merged,

That's not accurate due to the confusing svn. r163300 is the revision
where the branch was made (the copy), but the branch point was
r163026, right before the jsCStack merge in r163027. See
http://trac.webkit.org/changeset/163300/releases/WebKitGTK/webkit-2.4
and click on the trunk link.

  and 2.4.4 has numerous JSC crashes, especially in DFG.
  Disabling DFG is a reasonable short-term solution for my use case,
 but it leaves one crash I’m having trouble debugging. The release
 build crashes here:
 
 
 #0 0x7f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const
 () from libjavascriptcoregtk-1.0.so.0
 #1 0x7f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0
 #2 0x7f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0
 #3 0x7f1ff7a5d018 in ?? ()
 #4 0x7f1ff7a5d000 in ?? ()
 #5 0x7f1fb40af970 in ?? ()
 #6 0x7f1f7dec6a28 in ?? ()
 #7 0x7f1fac4b0ff8 in ?? ()
 #8 0x7fffe0e09000 in ?? ()
 #9 0x7fffe0e08da0 in ?? ()
 #10 0x7f1ffd36bada in JSC::JITCode::execute(JSC::VM*,
 JSC::ProtoCallFrame*, JSC::Register*) () from
 libjavascriptcoregtk-1.0.so.0
 Backtrace stopped: previous frame inner to this frame (corrupt
 stack?) 
 
 
 The debug build asserts:
 
 
 #0  0x7f434f2e692f in WTFCrash ()
 at ../../Source/WTF/wtf/Assertions.cpp:333
 #1  0x7f434eefe7ba in JSC::validateCellJSC::Structure*
 (cell=0x3569a30)
 at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
 #2  0x7f434eefe39d in
 JSC::WriteBarrierBaseJSC::Structure::operator-
 (this=0x7f42fd3bba90)
 at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
 #3  0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90)
 at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
 #4  0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,
 exec=0x7f42fd3bb878)
 at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
 #5  0x7f434ef290b5 in JSC::JSValue::toBoolean
 (this=0x7fff20ff7410, exec=0x7f42fd3bb878)
 at ../../Source/JavaScriptCore/runtime/JSString.h:521
 #6  0x7f434f085a84 in JSC::operationConvertJSValueToBoolean
 (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90)
 at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861
 #7  0x7f43069fc99c in ?? ()
 #8  0x7f43069218e0 in ?? ()
 #9  0x0274c130 in ?? ()
 #10 0x0301f740 in ?? ()
 #11 0x031e5eb0 in ?? ()
 #12 0x03295eb8 in ?? ()
 #13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling
 (object=0x7f43069218e0)
 at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
 #14 0x7fff20ff74c0 in ?? ()
 #15 0x7f434f06f74c in JSC::JITCode::execute
 (this=0xf0458b4832eb, vm=0xb8077500f07d,
 protoCallFrame=0x8348f0458948, topOfStack=0xdb6e8c7894860c0)
 at ../../Source/JavaScriptCore/jit/JITCode.cpp:48
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 
 
 My question isn’t how to debug this, though any insights would be
 welcome. Instead I’m hoping to to roll JSC forward or backward to a
 more stable revision somewhere near 02/2014  (in order to reduce
 problems merging into WebKitGtk). It seems best to tie it to a
 contemporaneous Safari release, perhaps from the safari-600.1 branch.
 I’m wondering if that branch is considered always stable, and
 therefore safe to pull from at an arbitrary revision. Alternatively,
 is there a way to discover the revision for a given Safari release?
 
 
 Thanks for any help,
 Gary
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] New EWS status bubbles in Bugzilla

[Carlos Garcia Campos]

El lun, 29-09-2014 a las 15:05 -0700, Alexey Proskuryakov escribió:
 Hi,
 
 
 WebKit Bugzilla has new EWS status bubbles now, which will hopefully
 make it more clear what's going on with a patch. Mysterious yellow
 bubbles that could mean anything were eliminated, and most
 importantly, there is now detailed information presented on hover:

 Please try it out, and let me know if something breaks, or is not as
 good as it could be!

Looks great! thanks. I've noticed that now we use red also for patches
that don't apply. I liked that there was a different color for that
case, since it's common when a patch depends on another one, and the
patch itself is not necessarily bad.

 
 - 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] New EWS status bubbles in Bugzilla

[Carlos Garcia Campos]

El lun, 29-09-2014 a las 23:51 -0700, Alexey Proskuryakov escribió:
 29 сент. 2014 г., в 23:12, Carlos Garcia Campos carlo...@webkit.org 
 написал(а):
 
  Please try it out, and let me know if something breaks, or is not as
  good as it could be!
  
  Looks great! thanks. I've noticed that now we use red also for patches
  that don't apply. I liked that there was a different color for that
  case, since it's common when a patch depends on another one, and the
  patch itself is not necessarily bad.
 
 I agree that this is a non-obvious case. I chose red because EWS can't
 say anything good about the patch (or anything at all), so it needs
 extra careful attention from a reviewer.
 
 Other options that I considered were:
 
 - Keep it purple, as it was. I restricted purple to indicating
 internal errors, so it should pretty much never happen. Using the same
 color for the entirely different case of a patch that does not apply
 seems wrong.

Agree.

 - Make it white. That seems to make sense logically, but it has the
 same problem of using a single color for multiple purposes as red
 does. Also, I expect it to be surprising (I posted my patch several
 hours ago, why is it still white?)

Agree.

 - Add a new color. I'm not sure if this case is common enough for the
 color to become generally recognizable.

Well, I guess it's a matter of getting used to it :-)

 - Instead of per-queue bubbles, show text like Patch does not apply
 to trunk. Not workable, because queues start at different times, and
 only some of them could fail to apply the patch.

Right.

 Perhaps most importantly, this case is really no different from
 failing to build due to a dependency on another patch, or to failing
 some tests for the same reason. So I don't think that we can represent
 dependency on another patch with color.

Fair enough, I haven't thought about those cases, I agree it's indeed
the same case and we will see red bubbles. Ideally, the EWS might apply
the patches following the dependency chain, but I guess that's not easy
to do.

 Thinking about this now, we could replace bubbles with text when no
 queue has results (i.e. at least one queue has failed to apply, and
 those that didn't still haven't started processing - we can reasonably
 expect that they will fail, too, and even if they apply cleanly, we
 can just revert to showing bubbles then). I can't think of any
 situation where this would be misleading or difficult to comprehend.
 Would this resolve your concern? Would you be willing to post a patch
 implementing this?

Well, I was just surprised to see the bubbles red because I was used to
seeing them purple, but I agree the case it's not different to when a
patch fails to build because of a dependency. So, I'll get used to the
red :-)

 - Alexey
 
 


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

Re: [webkit-dev] What’s the status of the GObject bindings?

[Carlos Garcia Campos]

El sáb, 19-07-2014 a las 23:08 -0700, Darin Adler escribió:
 Which port exposes the GObject bindings? I had the impression that the GTK 
 port was dropping WebKit1. Are the GObject bindings used with WebKit2?

Yes, GObject DOM bindings are now used in WebKit2 GTK+ using web
extensions (injected bundle) API.

 — 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] PSA: COMPILE_ASSERT_MATCHING_ENUM is a bad idea

[Carlos Garcia Campos]

El mar, 28-01-2014 a las 14:32 -0800, Anders Carlsson escribió:
 Hi floks!
 
 I noticed that both the EFL port and GTK+ port use a 
 COMPILE_ASSERT_MATCHING_ENUM macro to make sure that WebCore enum values map 
 to API enum values correctly, for example:
 
 COMPILE_ASSERT_MATCHING_ENUM(WEBKIT_WEB_NAVIGATION_REASON_LINK_CLICKED, 
 NavigationTypeLinkClicked);

Yes, we preferred that way to keep the code simpler and avoid long
switches.

 This means that we can’t add new enums declarations (unless they’re added at 
 the end) without breaking the build.

That's right, it's also true that most of the times enums are extended
adding new entries at the end.

 Instead of doing this (and then just blindly casting between the API layer 
 and WebCore enum types), use conversion functions, like this (taken from 
 WebKit2):
 
  inline WebCore::PageVisibilityState 
  toPageVisibilityState(WKPageVisibilityState wkPageVisibilityState)
  {
  switch (wkPageVisibilityState) {
  case kWKPageVisibilityStateVisible:
  return WebCore::PageVisibilityStateVisible;
  case kWKPageVisibilityStateHidden:
  return WebCore::PageVisibilityStateHidden;
  case kWKPageVisibilityStatePrerender:
  return WebCore::PageVisibilityStatePrerender;
  }
  
  ASSERT_NOT_REACHED();
  return WebCore::PageVisibilityStateVisible;
  }
 
 I plan to audit the Mac and Windows ports and look for places where we cast 
 between API enum types and WebCore enum types, and I filed 
 
 https://bugs.webkit.org/show_bug.cgi?id=127800 WebKitGTK+ should stop using 
 COMPILE_ASSERT_MATCHING_ENUM macros
 https://bugs.webkit.org/show_bug.cgi?id=127801 EFL port should stop using 
 COMPILE_ASSERT_MATCHING_ENUM macros
 
 for the Mac and EFL ports respectively. I’m happy to answer any questions 
 about this.

Ok, let's fix this sooner rather than later, then.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3


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

Re: [webkit-dev] Guideline for nullptr

[Carlos Garcia Campos]

El lun, 06-01-2014 a las 14:19 -0800, Martin Robinson escribió:
 On Mon, Jan 6, 2014 at 1:16 PM, Ryosuke Niwa rn...@webkit.org wrote:
  Sounds like a great idea to me.
 
 Seconding this. nullptr also has much better compatibility with varargs than 
 0.

Yeah, with nullptr we don't need the coding style exceptions for C API
using NULL as a sentinel.



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

Re: [webkit-dev] ChangeLog format

[Carlos Garcia Campos]

El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
 On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa rn...@webkit.org
 wrote:
 On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
 carlo...@webkit.org wrote:
 
 El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa
 escribió:
  Hi,
 
 [...]
 
  Separately, I'd like to know whether people liked
 the new format and
  it's worth my time making webkitpy adopt the new
 format.
 
 
 I prefer the old format.
 
 
  I personally didn't like the old format because it
 made the first line
  of each change log too long.  I'm also not a big fun
 of wrapping URLs
  in angle brackets.  It's also unclear to me what
 should happen when
  there are multiple Bugzilla URLs to list.
 
 
  But I hear the new format made git log --oneline
 much more readable so
  I can be convinced although I don't intend to use
 git for WebKit
  development in the foreseeable future myself.
 
 
 Well, git log is not actually affected by the
 ChangeLog format, but by
 the commit message. I mean, we generate the commit
 message from the
 ChangeLog, so we can keep the old format in the
 ChangeLog and update the
 script to generate the commit message to make it
 better for oneline git
 log format. webkitpy parses the ChangeLog not the
 commit message, so
 everything should work.
 
 
 If I'm not mistaken, I think a bunch of tools DO analyze git
 logs to do the work; commit-queue, webkitbot, etc...
 
 
 e.g. MarkBugFixed._determine_bug_id_and_svn_revision
 uses tool.scm().svn_commit_log to figure out the bug number.  In fact,
 the code assumes that the commit log uses the same format as the
 change log and uses changelog.py's parse_bug_id_from_changelog
 
 
 In fact, making change log  commit log use a different format is much
 more challenging than changing the format of change log  commit log.
  It requires A LOT of refactoring and bug fixes in webkitpy.  I don't
 even know much work is required for webkitperl and other tools.

I see, I thought ChangeLog parser was used everywhere. So, I guess the
solution would be to find a format most people like and adapt all
scripts to it. I personally think it's not worth it, though. The oneline
git log format is ok with the old commit message format IMO. If the only
problem is that the bug number is not in the first line we can probably
add it without adding the URL in angle brackets, something like:

Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
https://bugs.webkit.org/show_bug.cgi?id=119872

 
 - R. Niwa
 
 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] ChangeLog format

[Carlos Garcia Campos]

El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
 On 2013-08-21, at 11:11 PM, Carlos Garcia Campos carlo...@webkit.org wrote:
 
  I see, I thought ChangeLog parser was used everywhere. So, I guess the
  solution would be to find a format most people like and adapt all
  scripts to it. I personally think it's not worth it, though. The oneline
  git log format is ok with the old commit message format IMO. If the only
  problem is that the bug number is not in the first line we can probably
  add it without adding the URL in angle brackets, something like:
  
  Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
  https://bugs.webkit.org/show_bug.cgi?id=119872
 
 What benefit does duplicating the bug number in the first line provide? It’s 
 just yet another thing to have to add when writing the ChangeLog entry.

The benefit is that you see the bug number when using git log oneline
format, I'm guessing that seeing the bug number in the first line was
the motivation of the new ChangeLog format.

 - Mark
 
 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?

[Carlos Garcia Campos]

El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson escribió:
 On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa rn...@webkit.org wrote:
  Are Qt and GTK+ (and other) ports intentionally returning false in
  shouldShowPlaceholderWhenFocused?  Or is this just an oversight due to the
  fact the default implementation returned false?
 
 I just confirmed that the native GTK+ behavior is for placeholder text
 to disappear when a text entry is focused. I believe for GTK+ this
 method should return false.

I think that removing the placeholder text when starting typing instead
of when the entry is focused is indeed a good idea. I implemented the
placeholder text in GTK+ following the WebKit approach, so maybe we can
change it in both places.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?

[Carlos Garcia Campos]

El mar, 20-08-2013 a las 23:41 -0700, Ryosuke Niwa escribió:
 Does that mean we want the new Mac behavior
 (i.e. shouldShowPlaceholderWhenFocused returning true) everywhere?

I think so unless any GTK+ port maintainer disagree, but consistency
with the platform is important too, so I'll first check with GNOME
designers if they are ok with changing that in GTK+.

 Ryosuke Niwa
 
 
 
 
 On Tue, Aug 20, 2013 at 11:35 PM, Kangil Han kangil@samsung.com
 wrote:
 +1
 
 -Original Message-
 From: webkit-dev-boun...@lists.webkit.org
 [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of
 Carlos Garcia Campos
 Sent: Wednesday, August 21, 2013 3:08 PM
 To: Martin Robinson
 Cc: WebKit Development
 Subject: Re: [webkit-dev] Are Qt and GTK+ intentionally
 returning false in shouldShowPlaceholderWhenFocused?
 
 El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson
 escribió:
  On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa
 rn...@webkit.org wrote:
   Are Qt and GTK+ (and other) ports intentionally returning
 false in
   shouldShowPlaceholderWhenFocused?  Or is this just an
 oversight due
   to the fact the default implementation returned false?
 
  I just confirmed that the native GTK+ behavior is for
 placeholder text
  to disappear when a text entry is focused. I believe for GTK
 + this
  method should return false.
 
 I think that removing the placeholder text when starting
 typing instead of when the entry is focused is indeed a good
 idea. I implemented the placeholder text in GTK+ following the
 WebKit approach, so maybe we can change it in both places.
 
  --Martin
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 --
 Carlos Garcia Campos
 
 http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
 ___
 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
 
 
 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] ChangeLog format

[Carlos Garcia Campos]

El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió:
 Hi,

[...]
 
 Separately, I'd like to know whether people liked the new format and
 it's worth my time making webkitpy adopt the new format.

I prefer the old format.

 
 I personally didn't like the old format because it made the first line
 of each change log too long.  I'm also not a big fun of wrapping URLs
 in angle brackets.  It's also unclear to me what should happen when
 there are multiple Bugzilla URLs to list.
 
 
 But I hear the new format made git log --oneline much more readable so
 I can be convinced although I don't intend to use git for WebKit
 development in the foreseeable future myself.

Well, git log is not actually affected by the ChangeLog format, but by
the commit message. I mean, we generate the commit message from the
ChangeLog, so we can keep the old format in the ChangeLog and update the
script to generate the commit message to make it better for oneline git
log format. webkitpy parses the ChangeLog not the commit message, so
everything should work.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Adding ENABLE_CSS_DIRECTIONAL_FOCUS to WebCore.

[Carlos Garcia Campos]

El vie, 26-07-2013 a las 20:07 -0700, Benjamin Poulain escribió:
 On Fri, Jul 26, 2013 at 1:57 AM, Mario Sanchez Prada 
 mario.pr...@samsung.com wrote:
 
   Ah, When I made a new patch, had doubts about the file name Deprecated.
   So, I have to wait the StyleBuilder Class to have a clear form.
 
  On this regard, some input from Dirk Schulze could probably be very useful
  as guidance here, as he was the original author of the commit where this
  class got deprecated[1].
 
 
 It is a work in progress to clean the StyleBuilder.
 
 
   Also, I'm waiting for the community to conclude this discussion.
 
  Me too.
 
 
 Honestly, I am concerned that no one in favor of this feature is a regular
 contributor.

Mario has volunteered to maintain this feature, or do you really mean
Mario is not a regular contributor?

 The feature does not seem very invasive so if some people really invest
 time in maturing this, it could be worth experimenting with this and
 provide feedback to the W3C working group.
 I think everything should be behind a feature flag, and have the -webkit-
 prefix. As usual with experimental features, you will have to remove it if
 it turns out the experiment is not successful.
 
 Benjamin
 On Fri, Jul 26, 2013 at 1:57 AM, Mario Sanchez Prada
 mario.pr...@samsung.com wrote:
  Ah, When I made a new patch, had doubts about the file name
 Deprecated.
  So, I have to wait the StyleBuilder Class to have a clear
 form.
 
 
 On this regard, some input from Dirk Schulze could probably be
 very useful
 as guidance here, as he was the original author of the commit
 where this
 class got deprecated[1].
 
 
 It is a work in progress to clean the StyleBuilder.
  
  Also, I'm waiting for the community to conclude this
 discussion.
 
 
 Me too.
 
 
 Honestly, I am concerned that no one in favor of this feature is a
 regular contributor.
 
 
 The feature does not seem very invasive so if some people really
 invest time in maturing this, it could be worth experimenting with
 this and provide feedback to the W3C working group.
 I think everything should be behind a feature flag, and have the
 -webkit- prefix. As usual with experimental features, you will have to
 remove it if it turns out the experiment is not successful.
 
 
 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] WebKit2 and ENABLE_PLUGIN_PROCESS

[Carlos Garcia Campos]

El lun, 20-05-2013 a las 15:15 -0700, Anders Carlsson escribió:
 Hello,
 
 is anyone building WebKit2 without ENABLE_PLUGIN_PROCESS set, running 
 Netscape plug-ins in the web process?
 
 The reason I’m asking is that having two code paths complicates things and 
 I’d like to remove the non-plug-in process code path.

I think we removed the compile option in GTK port already.

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


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

Re: [webkit-dev] Crash in JSC while loading gap.com on 1.6.3

[Carlos Garcia Campos]

El mar, 30-04-2013 a las 09:11 +0200, Allan Sandfeld Jensen escribió:
 He probably refers to 1.6.3 of WebKitGTK+, the confusion comes from the fact 
 that WebKitGTK+ calls themselves and their library 'WebKit' on Linux with no 
 attempt of disambiguation.

right :-( but we fixed that already, our libs are now libwebkitgtk,
libwebkit2gtk and libjavascriptcoregtk

 He needs to update though. I think they are at 1.11 and 2.0 now.

Right.

 `Allan
 
 On Tuesday 30 April 2013, Filip Pizlo wrote:
  Three suggestions:
  
  1) If you find a bug in some part of WebKit (JSC or elsewhere), you should
  file it on bugs.webkit.org.  webkit-dev isn't really the right venue for
  bug reports.
  
  2) You should be more specific - in the bug report that you will file and
  not in this thread - about what port you're using.  Version 1.6.3 is
  ambiguous, to me.  There are a number of ports that support ARM, and it's
  not clear to me which you're using.  Hence, I don't even know how old
  1.6.3 is, because I'm not familiar with the versioning that the
  different ports do.
  
  3) Your best bet is probably to update to a newer version, and see if the
  bug reproduces.
  
  -Filip
  
  On Apr 29, 2013, at 10:15 PM, developer World world2deve...@gmail.com 
 wrote:
   Hi,
   
 I am using the 1.6.3 release (an old one) for my development and get a
 crash while loading gap.com and youtube.com/tv.(Both related to JS
 function apply having an incredibly large number of arguments)
   
   My processor is ARM 11 based and the smaps of the crash point me to the
   location where the JIT has dumped the bytecode for excuting various JS
   functionality.
   
   From the looks of it, the issue I face is very similar to this one
   https://bugs.webkit.org/show_bug.cgi?id=108991 however, since I am on an
   old version it is difficult for me to fix it in my JSC. Can anyone help
   me out over here as to where should I patch my JSC source code
   
   Thanks
   ___
   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] C++11 (was Re: on coding-style)

[Carlos Garcia Campos]

El vie, 12-04-2013 a las 18:15 -0700, Maciej Stachowiak escribió:
 On Apr 12, 2013, at 4:09 PM, Karen Shaeffer shaef...@neuralscape.com wrote:
 
  
  Of course, I understand that. But there is a huge opportunity cost to 
  webkit.
  The c++11 standard also rewrites the entire standard library. I have been 
  using
  g++ 4.7.2 using -stdc++11 in my work with linux. And the code I have tested 
  is
  performing nearly like c code. If you take advantage of the performance 
  enhancements
  in C++11, then you can realize impressive performance gains.
  
  I do understand the nature of the business. And I also understand that 
  performance
  is huge moving forward, where resource constrained mobile platforms are 
  significantly
  affected by performance issues. I suggest you'll see Blink moving 
  aggressively to
  support C++11 moving forward. And I suggest it is in WebKit's long term 
  interest to
  do so as well.
 
 As others have said, we are definitely eager to use C++11 across the board 
 but are limited by compiler support requirements.
 
 One thing that it would be useful to know: what are the compilers and minimum 
 required versions used for in-tree ports? Perhaps we could record this so we 
 can regularly evaluate which features are safe to use and what the blockers 
 are to wholesale adoption, if any.

The GTK+ port now requires gcc = 4.7 and clang = 3. We also added the
-stdc++11 where possible. See
https://bugs.webkit.org/show_bug.cgi?id=109932

 Regards,
 Maciej
 
 
 
 
 
 
 On Apr 12, 2013, at 4:09 PM, Karen Shaeffer shaef...@neuralscape.com
 wrote:
 
  
  Of course, I understand that. But there is a huge opportunity cost
  to webkit.
  The c++11 standard also rewrites the entire standard library. I have
  been using
  g++ 4.7.2 using -stdc++11 in my work with linux. And the code I have
  tested is
  performing nearly like c code. If you take advantage of the
  performance enhancements
  in C++11, then you can realize impressive performance gains.
  
  I do understand the nature of the business. And I also understand
  that performance
  is huge moving forward, where resource constrained mobile platforms
  are significantly
  affected by performance issues. I suggest you'll see Blink moving
  aggressively to
  support C++11 moving forward. And I suggest it is in WebKit's long
  term interest to
  do so as well.
  
 
 As others have said, we are definitely eager to use C++11 across the
 board but are limited by compiler support requirements.
 
 
 One thing that it would be useful to know: what are the compilers and
 minimum required versions used for in-tree ports? Perhaps we could
 record this so we can regularly evaluate which features are safe to
 use and what the blockers are to wholesale adoption, if any.
 
 
 Regards,
 Maciej
 
 
 
 
 
 
 
 
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3


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

Re: [webkit-dev] Changes to the WebKit2 development process

[Carlos Garcia Campos]

El mar, 29-01-2013 a las 09:39 +0100, Balazs Kelemen escribió:
 
  IMHO, recently, contributors as well as WK2 owners are a bit suffering 
  from it. I think we can go to a better direction: making all 
  developers happy as well as resolving WK2 owners' concerns.
 
 
 I think the straightforward way to achieve this is to let somebody be an 
 owner from every port. He/she should could be restricted to approve only 
 platform specific changes.

And why not making it even simpler an allow any reviewer to r+
port-specific patches? If the patch doesn't change any cross-platform
code at all there's no risk to break mac or any other port. 


Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient

[Carlos Garcia Campos]

El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió:
 Hi Mario,
 
 The motivation of the change was to reduce the chatter between the
 WebProcess and UIProcess and reduce the amount of knowledge the
 UIProcess has about the internals of the WebProcess.  We will also be
 removing the UIProcess' notion of the frame tree, for the same reason.

Now that you guys can break other ports at any time, would it be
possible that those changes are announced in advance here so that we
have some time to prepare for the change? I don't mean all changes that
might break the build and are easy to fix, but changes like that one
that break the C API, remove functionality, etc. that require a lot of
work adapting to them.

 Going forward, if you need that kind of detailed knowledge, you should
 use the WebInspector or the protocol it is based on.

The GTK+ API depends on the WebResource API, so WebInspector is not a
solution, 14 unit test are timing out now that resources don't work at
all. We'll rework it using injected bundle, but I'm afraid the injected
bundle API could be removed too, are there any plans in that regard or
can we safely use the injected bundle API?

 -Sam
 
 On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada mario.pr...@samsung.com 
 wrote:
 
  Hi,
   
  So it seems WebKit2GTK+ builds are broken since yesterday due to this 
  commit (as it was already predicted by EWS in [1]):
  http://trac.webkit.org/changeset/140285
   
  ... and it seems to me it’s not something easily fixable since it will 
  certainly require a certain amount of work (and maybe a certain amount of 
  re-design too) to get it back, as the WebKitWebResource API (as well as 
  certain parts in WebKitWebView API) did benefit of both 
  WKResourceLoadClient and WebResourceLoadClient.
   
  I’ve checked the related bug [1], but still haven’t been able to properly 
  understand what’s exactly the reason of this change and, more importantly, 
  what could be the best way to sort this out in the GTK port (an alternative 
  implementation using the Injected Bundle perhaps?).
   
  If anyone could drop some light on this issue or provide some pointers to 
  better understand the motivation of this change, I’d really appreciate 
  that. I understand rolling r140285 might be not the best option at this 
  point, yet I’d personally rather not keep the WebKit2GTK+ broken for too 
  long.
   
  Thanks,
  Mario
   
  [1] https://bugs.webkit.org/show_bug.cgi?id=107405
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 Hi Mario,
 
 
 The motivation of the change was to reduce the chatter between the
 WebProcess and UIProcess and reduce the amount of knowledge the
 UIProcess has about the internals of the WebProcess.  We will also be
 removing the UIProcess' notion of the frame tree, for the same reason.
 
 
 Going forward, if you need that kind of detailed knowledge, you should
 use the WebInspector or the protocol it is based on.
 
 
 -Sam
 
 On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada
 mario.pr...@samsung.com wrote:
 
  Hi,
   
  So it seems WebKit2GTK+ builds are broken since yesterday due to
  this commit (as it was already predicted by EWS in [1]):
  http://trac.webkit.org/changeset/140285
   
  ... and it seems to me it’s not something easily fixable since it
  will certainly require a certain amount of work (and maybe a certain
  amount of re-design too) to get it back, as the WebKitWebResource
  API (as well as certain parts in WebKitWebView API) did benefit of
  both WKResourceLoadClient and WebResourceLoadClient.
   
  I’ve checked the related bug [1], but still haven’t been able to
  properly understand what’s exactly the reason of this change and,
  more importantly, what could be the best way to sort this out in the
  GTK port (an alternative implementation using the Injected Bundle
  perhaps?).
   
  If anyone could drop some light on this issue or provide some
  pointers to better understand the motivation of this change, I’d
  really appreciate that. I understand rolling r140285 might be not
  the best option at this point, yet I’d personally rather not keep
  the WebKit2GTK+ broken for too long.
   
  Thanks,
  Mario
   
  [1] https://bugs.webkit.org/show_bug.cgi?id=107405
  ___
  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

Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Moving to Git?

[Carlos Garcia Campos]

El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and infrastructure,
  against my better judgement, I'd like to distract you from being productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.
 
 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).

I agree about merging commits, but I think it's possible to enforce all
merges to be fast-forward and without merging commits. In general
browsing git history is easier and cleaner than svn, and more important
it's much faster (my taste :-P)

 Then for everything else I use git and its power locally.

I would be more than happy with the switch :-)

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Moving to Git?

[Carlos Garcia Campos]

El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
  It is possible to keep linear history with git.  This just requires you to 
  fast forward and rebase before pushing.
 
 But can you enforce in the server? To avoid people to push it by mistake?

Yes, I think it's possible with a hook in the server.

  Konrad
  Sent from my BlackBerry on the Rogers Wireless Network
 
  - Original Message -
  From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
  Sent: Thursday, March 08, 2012 12:27 PM
  To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Moving to Git?
 
  El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
  On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
   On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
   ashodnakash...@yahoo.com
   wrote:
  
   In the light of discovering that some SVN scripts have fallen behind in
   terms of maintenance[1] and WebKit's strong Git support and 
   infrastructure,
   against my better judgement, I'd like to distract you from being 
   productive
   by bringing up this topic (again).
  
   The wiki page of the same name[2] was created 3 years ago and hardly
   updated since[3]. I know we're all busy with more important things, but 
   IMHO
   I think we can at least update the wiki and perhaps vote on when/how we
   should do the eventual transition.
  
   I understand that while this type of work isn't necessarily very
   productive, maintaining two repositories and sets of scripts (with their
   docs and issues) has a very real cost as well. I'm proposing we 
   reevaluate
   the situation and act accordingly.
  
  
   Re-evaluating the situation is good, but I'm still opposed.
 
  I don't use svn but the only benefit I see of WebKit using svn is the
  linear history, clean, easy to read and to explore. Git repos tend to
  have merging commits a lot and it leads to make bisecting/history
  browsing harder (my taste).
 
  I agree about merging commits, but I think it's possible to enforce all
  merges to be fast-forward and without merging commits. In general
  browsing git history is easier and cleaner than svn, and more important
  it's much faster (my taste :-P)
 
  Then for everything else I use git and its power locally.
 
  I would be more than happy with the switch :-)
 
  --
  Carlos Garcia Campos
  http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  -
  This transmission (including any attachments) may contain confidential 
  information, privileged material (including material protected by the 
  solicitor-client or other applicable privileges), or constitute non-public 
  information. Any use of this information by anyone other than the intended 
  recipient is prohibited. If you have received this transmission in error, 
  please immediately reply to the sender and delete this information from 
  your system. Use, dissemination, distribution, or reproduction of this 
  transmission by unintended recipients is not authorized and may be unlawful.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 
 


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