Re: [webkit-dev] Replacing Cairo in WebKit with Skia

[Dominik Röttsches via webkit-dev]

Hi,

Thanks for taking on this effort and the technical investigation that went
into this!

One question I had asked on X: Does this have implications for font format
support: Will WebKitGTK/WPE with Skia support COLRv1 fonts through Skia?
Will it also support the Fontations Rust backend of Skia, that's in
development?

Thanks,

Dominik




On Fri, Feb 2, 2024 at 4:49 PM Carlos Garcia Campos via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> 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
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: supports() extended syntax for @font-face

[Dominik Röttsches via webkit-dev]

Hi Myles,

On Mon, Aug 9, 2021 at 8:09 PM Myles Maxfield  wrote:

>
> Is this something you're considering developing / shipping in WebKit? As
> Myles has been an active contributor in the proposal in issue #633, I am
> hoping we have your support on this matter.
>
>
> Positive signal.
>

Thanks, good to hear.

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

[webkit-dev] Request for position: supports() extended syntax for @font-face

[Dominik Röttsches via webkit-dev]

Hi @ webkit-dev, hi Myles,

we'd like to know your opinion on the extended supports()
syntax of the @font-face src: descriptor.


   - Specification or proposal URL:
   https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing, in
   particular the [ format(
    [supports
   
   #]?)]? part
   of the spec.

The changes have originally been approved / developed in the CSS WG process
already. As we're considering shipping this feature, we'd like to know if
Apple is considering implementing support as well.


   - CSS WG Resolution for issue #633
    initially adding
   format() and supports() syntax
   - CSS WG change in issue #6340
    to clarify parsing
   rules for supports syntax


Is this something you're considering developing / shipping in WebKit? As
Myles has been an active contributor in the proposal in issue #633, I am
hoping we have your support on this matter.

Thanks in advance,

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

Re: [webkit-dev] Request for position: CSS @font-face descriptor advance-override

[Dominik Röttsches via webkit-dev]

As an update to our intent here. as posted by Xiaocheng earlier, we're
planning to ship the size-adjust descriptor
.

On Mon Feb 22 16:50:28 PST 2021 Xiaocheng Hu xiaoche...@chromium.org wrote:

Hi webkit-dev,
> This is a request for WebKit's position on a new descriptor
> 'advance-override' of the CSS @font-face rule.
> This is a new feature that the CSSWG just added into CSS Fonts Level 5 for
> reducing layout shifting caused by web fonts. Chrome has already
> implemented it in M90 behind a flag.
>


> Explainer:
> https://gist.github.com/xiaochengh/3aae8a97d1b0388c8e701819b63e2c49
> Spec: https://drafts.csswg.org/css-fonts-5/#font-metrics-override-desc
> May I assume https://github.com/w3c/csswg-drafts/pull/5991, authored by
> Myles, as a positive signal?
> Thank you!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for Position: COLR v1 Vector Color Fonts

[Dominik Röttsches via webkit-dev]

urpose 2d graphics
> serialization format. Therefore, it doesn’t actually improve upon the color
> font table fragmentation situation, which is widely regarded as one of the
> biggest drawbacks to color fonts today.
>

I’ll not go into details whether embedding bitmaps in OT-SVG fonts makes
sense over choosing a bitmap font format such as CBDT/CBLC or SBIX.

Cross-browser supported bitmap color font formats already exist (SBIX for
example), but it’s not our primary focus with COLRv1 to embed bitmaps as it
is not on the critical path of those exact scalability and rendering
quality issues we want to address.
However, taking on your feedback, we’re discussing embedded and reusing
bitmaps from existing bitmap formats in this github issue
<https://github.com/googlefonts/colr-gradients-spec/issues/272> as a
possible future extension to COLRv1, possibly incorporating existing bitmap
font table definitions.

Given these two lists, Apple’s WebKit team and Core Text team are negative
> on this proposal.
>
> Thanks,
> Myles
>
> * Except for font variations, which A) can be added to OT-SVG easily, and
> B) probably aren't a particularly compelling feature in conjunction with
> color font technology, at least now.
>
>
I have not seen an approach that defines an “easy” definition of applying
OT variations to SVG paths, let alone in a compact way in terms of font
file size. From what we hear from font designers and reviewers of the
specification (see also Chris Liley’s statement above), we certainly do not
want to offer a vector font format that lacks variations as exciting
variable fonts are being used and designed at the moment (for example a
full CJK variable font) and we would not want to lose this momentum when it
comes to color fonts.

With these additional points in mind, and the additional data we shared on
font size and performance advantages, we kindly invite you to reconsider
your position. We’d be very happy if you’d consider experimenting with
implementing COLRv1 and evaluate it from that perspective.

Dominik



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

[webkit-dev] Request for Position: COLR v1 Vector Color Fonts

[Dominik Röttsches via webkit-dev]

Hi,

This is a request for WebKit's position on COLR v1 vector color fonts.

Spec:

https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md
*Proposed changes to ISO/IEC 14496-22 (Amendment 2)*

Chromium Bug:
https://crbug.com/1170733

Summary:

COLR v1 fonts are a new vector color font format that provides gradients,
transforms and compositions for font glyph drawing enabling an expressive,
very compact glyph definition format for OFF/OpenType fonts. This format
provides size and rendering fidelity (scaling) advantages over bitmap fonts
such as SBIX, CBDT/CBLC fonts for glyph designs that lend themselves well
to being encoded as vector art.

Thank you in advance for your position statement on this topic,

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

Re: [webkit-dev] Christophe Dumez is now a WebKit reviewer

[Dominik Röttsches]

On 05/10/2013 03:22 AM, Laszlo Gombos wrote:

I'm happy to announce that Christophe Dumez is now a WebKit reviewer.


Congratulations, Chris! Well deserved indeed.

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

Re: [webkit-dev] Fwd: WebKit2 Extending Javascript

[Dominik Röttsches]

On 04/04/2013 10:33 AM, Christian Frost wrote:


My problem is that I have to extend Javascript in WebKit2. That is, I
have to add a set of global variables and functions. Potentially I
also need to add custom classes. However, this doesn't seem to be
possible in WebKit2 since it is not yet supported. Can you help me on
this matter?


If you're looking for adding custom JavaScript API at compile time and 
make it available for all scripting contexts, there is no problem with 
that (and there's not a big difference between WebKit1 and 2 for that 
matter). You can start by familiarizing yourself with an IDL file that's 
similar to your purposes, and look at the related .cpp and *Custom.cpp 
files that implement the API that corresponds to that IDL file.


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

[webkit-dev] Authentication backend issues for svn.webkit.org?

[Dominik Röttsches]

Hi Lucas, William,

could you have a look at the authentication backend?

Quoting from IRC:

(02:27:47 PM) drott: can anyone have a look at the authentication 
backend of trac  svn?
(02:28:08 PM) drott: http://trac.webkit.org/auth/login show Internal 
Server Error  manual commits don't seem to work

(02:29:15 PM) rudy [~rudy@growl/rudy] entered the room.
(02:30:25 PM) yurys: see the same problem here: ERROR from SVN:
(02:30:26 PM) yurys: Authorization failed: MKACTIVITY of 
'/repository/webkit/!svn/act/16589eca-1532-40c0-b238-1e93a1aa25c8': 
authorization failed: Could not authenticate to server: rejected Digest 
challenge (http://svn.webkit.org)


Thanks,

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

Re: [webkit-dev] build.webkit.org login problem

[Dominik Röttsches]

 A database server went down. Everything should be back up now.

Bill, thanks for fixing the issue!

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

Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)

[Dominik Röttsches]

On 01/16/2013 10:07 PM, Eric Seidel wrote:

Do we know if there is a way to re-write our existing forks w/o
pulling the whole repo down, just to push it back up again?


If you make the new github mirror fork a remote for your existing 
git.webkit.org clone and push from there you would only need to push a 
small amount - at least that's how it worked for me.


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

[webkit-dev] Recommended commit procedure for large EFL rebaseline?

[Dominik Röttsches]

Hi,

when we land https://bugs.webkit.org/show_bug.cgi?id=106774
we'll have to do a large rebaseline of EFL results. (subpixel and 
FreeType related change)


Now, for landing, what we had in mind is, (optionally) take our bots 
offline, 1) land the actual patch, 2) then manually land the new baselines.

Then restart the bots.

Regarding step 2) there: Would you recommend to land the rebaselines in 
smaller chunks or in one big SVN commit? If in chunks - what sizes work 
well?


Thanks,

Dominik

--
Dominik Röttsches dominik.rottsc...@intel.com

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

Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)

[Dominik Röttsches]

On 01/14/2013 03:19 PM, Jesus Sanchez-Palencia wrote:

We have decided that the best approach for this is to start a new
repository (webkit-mirror), delete the old one
(https://github.com/WebKit/webkit) and then rename the new repository.

I will be doing the mirroring myself for while, until Apple can set
this up from the same machine that git pushes to git.webkit.org.


Great to see this, thanks!

Dominik

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

Re: [webkit-dev] Porting WebKit To a new graphic backend.

[Dominik Röttsches]

On 11/14/2012 07:24 AM, ZhangJiPeng wrote:
The idea came from an embedded browser development project. Benjamin I 
want to porting WebKit to a new platform, the platform can only 
provide video address programming interface. So I need to porting 
DirectFB, Cairo, GTK and so on. However the hardware resources are 
limited, can't running so much software, I need to find a more 
lightweight and high quality solutions, so I develop the picasso 
library. The same code base can run on different graphics system does 
not depend on the features of graphic system, this is the goal of 
Picasso.


To experiment with this, you could create your own git branch and try 
implementing a GraphicsContextPicasso (see 
Source/WebCore/platform/graphics/cairo | skia) - similar to 
GraphicsContextSkia and GraphicsContextCairo. Then you need to typedef 
the WebKit GraphicsContext to the Picasso graphics context and instruct 
your browser app to do all WebKit rendering into the Picasso 
GraphicsContext.


Gettings simple web pages to render with a new backend, somewhat close 
to the other backends might not even take that long. However, getting 
every detail right, like layers with opacity, rounded corners, correct 
clipping, full SVG support etc. is a rahter large amount of work.


Regards,

Dominik


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

[webkit-dev] Feature ENABLE_XHR_TIMEOUT

[Dominik Röttsches]

Hi,

in http://webkit.org/b/74802 Adam asked me to conditionalize the XHR 
timeout support since not all network backends have support for 
setTimeoutInterval. In such a case, default enabling the timeout and 
ontimeout properties on XHR would confuse feature detection.


I consider this a temporary feature until the remaining ports have 
enabled this in their network backends (volunteers very welcome):

https://bugs.webkit.org/show_bug.cgi?id=98397
It's currently working on Apple Mac, EFL, GTK.

Please let me know if there are any objections to pushing such a 
feature. I plan to track the backend support and I remove the feature 
once it's universally available.


Regards,

Dominik

--
Dominik Röttsches dominik.rottsc...@intel.com

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

Re: [webkit-dev] Feature ENABLE_XHR_TIMEOUT

[Dominik Röttsches]

Sorry, forgot to mentiont that the bug for this is: 
https://bugs.webkit.org/show_bug.cgi?id=100356
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] HbbTV support within Webkit

[Dominik Röttsches]

On 10/10/2012 10:26 AM, Mark Toller wrote:

What we would like to see initially is Webkit based browsers (Chrome,
Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the
user to download the content - this would indirectly benefit the end goal of
Webkit (to get everyone to support standard W3C/HTML5)...
This particular change is just a matter of adding one more displayable 
mime-type, right?


Dominik

--
Dominik Röttsches dominik.rottsc...@intel.com

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

Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline

[Dominik Röttsches]

Hi Dirk,

On 08/22/2012 10:49 PM, Dirk Pranke wrote:

The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts.



Can the failure limit be increased to 1 for example? Levi/Emil were 
saying the rebaseline touches about 8000 cases. Otherwise we'd have to 
go through a more complicated process like Zan explains.


Dominik

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

[webkit-dev] Subpixel layout - requesting help for big rebaseline

[Dominik Röttsches]

Hi Chromium folks,

Levi and Emil did a great job in implementing SubPixel Layout. I was 
looking into enabling it on WebKit EFL.
Unfortunately, the initial rebaseline for EFL would be huge. That's why 
I hesitated to enable it right away. Instead I started looking into what 
the reasons are.


I found one case where rounding should be added, here's my patch:
https://bugs.webkit.org/show_bug.cgi?id=89572

Landing this makes the rebaselining efforts for ports enabling subpixel 
layout smaller, so IMHO it'd accelerate adoption.
On the other hand, landing this patch requires a rebaselining for 
Chromium in the area of several thousand testcases.


I do feel the pain there. So I'd appreciate your help for getting this 
one landed. According to their comments on bugzilla, Emil and Levi 
approve the change.


Thanks,

Dominik

--
Dominik Röttsches dominik.rottsc...@intel.com

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

Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline

[Dominik Röttsches]

Hi,

As another alternative, could we gather all the Chromium bot admins and 
ask them to temporarily take the bot offline in non-peak hours, create 
rebaselines per bot with the patch applied, collect those as 
binary-compatible diffs in one place, and manually land those collected 
baselines, in short succession together with the patch?


Dominik

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

[webkit-dev] Feature: Implementing XHR2 timeouts

[Dominik Röttsches]

Hi,

I'd like to inform you about about my plan to implement the timeout 
behavior specified in
http://www.w3.org/TR/XMLHttpRequest/#the-timeout-attribute (and other 
sections with regards to that attribute).


I opened meta bug: https://bugs.webkit.org/show_bug.cgi?id=94461

Please let me know if there are any concerns or objections.

Regards,

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

Re: [webkit-dev] WebKit memory instrumentation

[Dominik Röttsches]

On 07/24/2012 01:09 AM, Yury Semikhatsky wrote:



On Mon, Jul 23, 2012 at 11:21 PM, Ryosuke Niwa rn...@webkit.org 
mailto:rn...@webkit.org wrote:


This is somewhat tangential but once we've solved this problem,
can we expose the data via testRunner or internals object so that
we may use it in our performance tests? It'll be very valuable to
be able to monitor changes in these metrics.

At the moment the data are only accessible through the Web Inspector 
protocol but I don't see any issues with exposing it via internals object.


Something similar is going on here
Add FastMalloc statistics in window.internals
https://bugs.webkit.org/show_bug.cgi?id=91274

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

Re: [webkit-dev] Using ref tests for repaint bugs

[Dominik Röttsches]

Andrei,

On 05/25/2012 02:43 AM, Andrei Bucur wrote:

Ojan,

As Simon states, some repaint tests will likely not be possible to 
write correctly as ref tests, but some of them I think they fit very 
well in the happy-no-pixel-test bucket :). If people decide it's a 
direction worth investigating, I'll give the idea a spin.


I'd be interested to hear about your progress. Recently I was facing a 
couple of similar issues:

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

and then GTK decided to always do repaints before dumping pixel results:
https://bugs.webkit.org/show_bug.cgi?id=86284
which might not be the right solution either - so if you come up with 
something more fine-grained - that'd be great.


Dominik

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

Re: [webkit-dev] A massive rebaseline needed for r117672

[Dominik Röttsches]

Hello Ryosuke,

On 05/19/2012 12:33 PM, Ryosuke Niwa wrote:
Unfortunately, I was not able to rebaseline tests for Windows and EFL 
bots because Windows bots have been failing to compile since r117672 
and EFL bots don't seem to upload results properly (I can't see diff 
on results page).


The EFL bot is uploading the results without issues, however they are 
currently not extracted on the buildbot master due to resource limitations.
Apple is working on a fix, this is tracked in 
https://bugs.webkit.org/show_bug.cgi?id=81760


In the future, if there's any rebaselining that you need done/help with 
for EFL, feel free to get in touch with one of our gardeners:

http://trac.webkit.org/wiki/EFLWebKitBuildBots

Regards,

Dominik

--
Dominik Röttschesdominik.rottsc...@intel.com

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

Re: [webkit-dev] EFL Debug Buildbot Green

[Dominik Röttsches]

Hi,

On 05/10/2012 06:43 PM, Dominik Röttsches wrote:
We'll [...] set up a gardening schedule to keep it green and tidy in 
the future.

The buildbot gardening schedule has been published here:
https://trac.webkit.org/wiki/EFLWebKitBuildBots

Regards,

Dominik

--
Dominik Röttschesdominik.rottsc...@intel.com

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

[webkit-dev] EFL Debug Buildbot Green

[Dominik Röttsches]

Hi all,

We're happy to share with you that yesterday the EFL Linux Debug 
Buildbot has turned green for the first time.

http://build.webkit.org/builders/EFL%20Linux%20Debug

This has been an example of a great team effort [1]. We'd like to thank 
the friendly reviewers and committers who helped us for their support!


We'll keep a close eye on our buildbot lamp http://goo.gl/ei1gL from now 
and set up a gardening schedule to keep it green and tidy in the future.


Dominik

[1] http://wkb.ug/85601

--
Dominik Röttschesdominik.rottsc...@intel.com

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

Re: [webkit-dev] Bot watching and Apple bots

[Dominik Röttsches]

On 04/26/2012 01:11 AM, Maciej Stachowiak wrote:

I think it may help the project overall if we made the buildbot page indicate 
who's the sheriff/gardner/watcher for any given buildbot. Right now it may be 
hard to tell who to work with if you caused breakage. Barring actual changes to 
the buildbot page, another thing we could do is put all this info in a shared 
wiki page.


I think that would be useful indeed - I'd try to create and publish the 
sherriff schedule for the EFL bot(s).


Dominik

--
Dominik Röttschesdominik.rottsc...@linux.intel.com

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

Re: [webkit-dev] [webkit-efl] EFL Linux Debug Buildbot online

[Dominik Röttsches]

Hi Gyuyoung,

On 04/13/2012 01:34 AM, Gyuyoung Kim wrote:


Great jobs !!

Why don't we make EFL category for our build bots ?
- http://build.webkit.org/


Yes, the patch's been already there, I am waiting for review
https://bugs.webkit.org/show_bug.cgi?id=82712

Regards,

Dominik



2012/4/13 Dominik Röttsches dominik.rottsc...@linux.intel.com 
mailto:dominik.rottsc...@linux.intel.com


Hi,

I am happy to inform you that the EFL Debug Buildbot got online
tonight (EEST).
By now it has completed its maiden build 0 :-)

http://build.webkit.org/builders/EFL%20Linux%20Debug

There's some tuning to do in the next few days, but it already
gives us useful information.
Let's continue to work on getting the bots green.

Regards,

Dominik



--
Dominik Röttschesdominik.rottsc...@linux.intel.com
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
  



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

[webkit-dev] Setting up additional WebKit EFL buildbot for 64bit Debug

[Dominik Röttsches]

Hello webkit-dev, Lucas,

Gyuyoung and we have agreed to run a secondary EFL buildbot maintained 
by Intel.
We would kindly ask for your support in creating credentials to hook our 
machine to the master buildbot.


Let me know if there are any additional steps we need to follow in 
addition to

http://trac.webkit.org/wiki/BuildBot

In understand once I have the local configuration ready - the master.cfg 
needs to be adjusted - should I create a bugzilla issue and a patch to 
update it to have two builders for the EFL platform?


Thank you very much,

Dominik Röttsches

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

Re: [webkit-dev] Upstreaming Support for W3C Sensor API

[Dominik Röttsches]

Maciej, Adam,

On 03/17/2012 12:26 AM, Maciej Stachowiak wrote:

Therefore, I think this work is not appropriate for the WebKit repository at 
this time, even as a WebCore Module. Of course, implementing the feature 
outside the main repository, e.g. via GitHub, is ok, and may be an opportunity 
to demonstrate its general usefulness.


thank you for your suggestions and feedback. Going the GitHub route is 
an option for us, we'll keep everyone informed on tracking bug 81352.


Regards,

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

[webkit-dev] Upstreaming Support for W3C Sensor API

[Dominik Röttsches]

Hello webkit-dev,

We would like to upstream our implementation of W3C Sensor API [1].

As we are aware that this is a young specification, we propose to have 
it default #ifdef-disabled.
However, we believe it could be useful for certain ports or useful for 
being accessed by Chrome extensions.


Your feedback is welcome.

For reference, we created meta bug 
https://bugs.webkit.org/show_bug.cgi?id=81352


Regards,

Dominik Röttsches

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