Re: [webkit-dev] Webkit handling of SVG with rgba() color

[Dirk Schulze]

The SVG 1.1 specification has a reference to CSS2. So from the
specifications point of view, rgba() shouldn't be supported.
Nevertheless SVG 1.1se won't have a strict reference to CSS2. Also other
browsers support rgba on SVG already.
I'm fine with a rgba implementation and Eric wrote already what is
needed to support it on the bug report.

Dirk

> I was looking at Bug 16183
> (https://bugs.webkit.org/show_bug.cgi?id=16183) - SVG doesn't support
> rgba() colors.  I was planning on fixing this but after reading the
> SVG spec at http://www.w3.org/TR/SVG11/ which states that SVG supports
> CSS2 color specifications I'm unsure if this should be fixed or not.
> rgba() was introduced with CSS3 so is technically not supported by
> SVG.  
> 
> 
> Looking at other implementations Chrome and webkit-head both render a
> rgba() color as pure black.  Safari 4.0.5 I've seen render it as
> either black or missing.  Firefox does render it properly.  Batiq
> fails to render and gives an error: "The attribute "stroke" represents
> an invalid CSS value ("rgba(0, 255, 0, 0.5)")."  
> 
> 
> Looking at this bug from an end user perspective it would be good to
> add this feature in as its likely that people will build sites that
> aren't strictly compliant and would want things to just work.  However
> I'm always wary of making changes that go against a published standard
> as that path can lead to ugliness, divergent standards and future
> headaches.  
> 
> 
> What I'm looking for from the community is feedback on what the right
> thing to do here with respect to webkit is.  Is it worth the
> convenience to the user to add support for rgba() to the SVG code? 
> 
> 
> -Jon
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] Cairo and "-webkit-mask-clip: text"

[Dirk Schulze]

Hi Andrei,

this kind of question should be asked in a bug report. Bug 23526 is the
best location, since it is a general issue with clipToImageBuffer on the
Cairo ports.

I'm interessted in a test case, where the patch on the mentioned bug
report does not work. I don't know of an example, that didn't work with
the current patch, neither on CSS mask nor SVG mask or filter.
But let us move the discussion to the bug report.

Greetings,
Dirk

Am Mittwoch, den 23.06.2010, 19:45 +0300 schrieb Andrei Bucur:
> Hello!
> 
> 
> 
> I'm trying to implement this CSS value on the Cairo backend and I'm
> stuck with a problem regarding the Porter-Duff composition operators
> (why is CAIRO_OPERATOR_DEST_IN unbound?). I've made the following
> changes to reach this point:
> 
> 
> 1. I implemented a version of GraphicsContext::clipToImageBuffer
> starting from this patch:
> https://bugs.webkit.org/show_bug.cgi?id=23526 , but saving the image
> mask and the masking rect on a stack and pushing only a group for the
> masked content.
> 2. In GraphicsContext::restorePlatformState when the save count is 0
> for the current mask, I recover the masked content as a pattern, I
> clip it using the mask from the stack (I used a new group and operator
> CAIRO_OPERATOR_IN) and then I should apply the result on the
> destination surface using CAIRO_OPERATOR_DEST_IN, but bounded to the
> current mask. The problem here is that CAIRO_OPERATOR_DEST_IN is
> unbounded so it doesn't take into account the mask, thus affecting all
> the surface.
> 3. I modify RenderBoxModelObject::paintFillLayerExtended so that when
> drawing the background image to use the bgLayer->composite() operator
> if the clip is TextFillBox. Using CompositeSourceIn can't work because
> clipToImageBuffer started a new group which uses a different surface
> for drawing (so there is no destination text to composite with). This
> way the composition will be done in restorePlatformState.
> 
> 
> I know this is ugly and that it's highly unlikely to work in this form
> with SVG masking. For now I just need a hook to make this work. Do you
> have any other suggestions to make this CSS value work with Cairo?
> 
> 
> Thanks,
> Andrei.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] [svg] rect with invalid stroke value

[Dirk Schulze]

Hi Yuzo,

the issue should be fixed in WebCore/rendering/RenderSVGPaintServer.
Removing this check in the test doesn't help to fix the bug :-)

Dirk

Am Montag, den 28.06.2010, 11:05 +0900 schrieb Yuzo Fujishima:
> Hi,
> 
> 
> Any update on this?
> 
> 
> Is it OK to remove 'stroke="#0"' from:
>   LayoutTests/svg/custom/invalid-fill-hex.svg
> 
> ?
> 
> 
> If there are no objections, I'll upload a patch to remove it for
> review.
> 
> 
> Yuzo
> 
> 
> 
> 
> On Tue, Jun 15, 2010 at 5:52 PM, Yuzo Fujishima 
> wrote:
> Nikolas,
> 
> 
> Thank you for your response.
> I'll hold off
> committing https://bugs.webkit.org/show_bug.cgi?id=24742 until
> you make a decision. Please let me know when you make one.
> 
> 
> Yuzo
> 
> 
> On Tue, Jun 15, 2010 at 3:42 PM, Nikolas Zimmermann
>  wrote:
> 
> Am 15.06.2010 um 08:28 schrieb Cameron McCormack:
> 
> 
> Nikolas Zimmermann:
> We had 'none' for years, until
> compatibility bugs were raised, as
> Opera uses black as default stroke, if
> there is any error.
> 
> Doesn’t seem to be the case any more, at least
> for Opera 10.53:
> 
> http://livedom.validator.nu/?%3C!DOCTYPE%
> 20html%3E%0D%0A%3Csvg%20width%3D'100'%20height
> %3D'100'%3E%3Ccircle%20cx%3D'50'%20cy%3D'50'%
> 20r%3D'30'%20fill%3D'yellow'%20stroke%3D'xxx'%
> 20stroke-width%3D'4'%2F%3E%3C%2Fsvg%3E
> 
> Note the stroke="xxx".  Firefox nightlies
> behave the same.
> 
> 
> That would be good news, I've been against the switch
> all time, we should reiterate that specific behaviour.
> Turning off that default stroke behaviour and seeing
> which layout tests break, and whether we now consider
> this a progression :-)
> I'll have a look at it this week.
> 
> Cheers,
> Niko
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] Path::createEllipse() - why not leverage port paths?

[Dirk Schulze]

The main reason is DumpRenderTree. If we use the Path::createEllipse
logic of the different platforms, we end up with different LayoutTest
results on SVG between platform, since we create them by traversing the
path data of the certain platform.
So changing this is painful and causes a lot of new platform dependent
results. But I would support this! :-)
Btw, we have the same problem with Path::createCircle.

Dirk

Am Sonntag, den 19.09.2010, 05:11 +0200 schrieb Andreas Kling:
> Hey folks,
> 
> Is there a reason we're manually creating the ellipses in 
> Path::createEllipse() instead of using the port-specific Path::addEllipse()?
> 
> For the SVG version of the benchmark at 
> http://www.themaninblue.com/writing/perspective/2010/03/22/ we're 
> spending roughly 25% of runtime in Path::createEllipse(), whereas if I 
> let it use Qt's Path::addEllipse() it drops to 2.5%.
> 
> (Qt is also much better at rendering the paths generated by 
> QPainterPath::addEllipse() instead of the 100x LineTo paths from 
> Path::createEllipse - time spent filling paths goes down from 30% to 25%.)
> 
> All in all, these are 15 additional FPS that I'd love to get if 
> possible. So lay it on me :-)
> 
> Curiously yours,
> -Kling
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] Path::createEllipse() - why not leverage port paths?

[Dirk Schulze]

Am Sonntag, den 19.09.2010, 09:32 +0200 schrieb Dirk Schulze:
> The main reason is DumpRenderTree.
Let me rephrase it: The only reason why we still use this logic is
DumpRenderTree.

> If we use the Path::createEllipse
> logic of the different platforms, we end up with different LayoutTest
> results on SVG between platform, since we create them by traversing the
> path data of the certain platform.
Just an examples: IIRC CoreGraphics uses cubic or qudratic curves to
draw an ellipse, Cairo uses arc and scales the path context to create an
ellipse, not sure what Skia or Qt are doing internally, but because of
the traversing of the path data, we definitely end up with different
results on DRT.

Dirk

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

Re: [webkit-dev] Pixel test experiment

[Dirk Schulze]

I strongly support pixel tests for SVG on the bots! Niko and me are hard 
working to get SVG pxiel perfect at all time. We run pixel tests on every patch 
we apply to the SVG code. And it would really help us if the bots blame any 
change that causes a pixel test to fail, or at least give some kind of feedback.

Dirk

> Good evening webkit folks,
> 
> I've finished landing svg/ pixel test baselines, which pass with --tolerance 
> 0 on my 10.5 & 10.6 machines.
> As the pixel testing is very important for the SVG tests, I'd like to run 
> them on the bots, experimentally, so we can catch regressions easily.
> 
> Maybe someone with direct access to the leopard & snow leopard bots, could 
> just run "run-webkit-tests --tolerance 0 -p svg" and mail me the results?
> If it passes, we could maybe run the pixel tests for the svg/ subdirectory on 
> these bots?
> 
> Cheers,
> Niko
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Pixel test experiment

[Dirk Schulze]

We missed many changes because of an existent tolerance level in the past. We 
made a baseline for MacOS Leopard as well as Snow Leopard and I would active 
pixel tests just for those two bots. I don't expect any problems. Niko and I 
run pixel tests on different machines and get the same results.

Dirk

Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak:

> 
> On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote:
> 
>> Good evening webkit folks,
>> 
>> I've finished landing svg/ pixel test baselines, which pass with --tolerance 
>> 0 on my 10.5 & 10.6 machines.
>> As the pixel testing is very important for the SVG tests, I'd like to run 
>> them on the bots, experimentally, so we can catch regressions easily.
>> 
>> Maybe someone with direct access to the leopard & snow leopard bots, could 
>> just run "run-webkit-tests --tolerance 0 -p svg" and mail me the results?
>> If it passes, we could maybe run the pixel tests for the svg/ subdirectory 
>> on these bots?
> 
> Running pixel tests would be great, but can we really expect the results to 
> be stable cross-platform with tolerance 0? Perhaps we should start with a 
> higher tolerance level.
> 
> REgards,
> Maciej
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Pixel test experiment

[Dirk Schulze]

> The problem I worry about is that on future Mac OS X releases, rendering of 
> shapes may change in some tiny way that is not visible but enough to cause 
> failures at tolerance 0. In the past, such false positives arose from time to 
> time, which is one reason we added pixel test tolerance in the first place. I 
> don't think running pixel tests on just one build slave will help us 
> understand that risk.
> 
> Why not start with some low but non-zero tolerance (0.1?) and see if we can 
> at least make that work consistently, before we try the bolder step of 
> tolerance 0?
> 
> Also, and as a side note, we probably need to add more build slaves to run 
> pixel tests at all, since just running the test suite without pixel tests is 
> already slow enough that the testers are often significantly behind the 
> builders.
> 
> Regards,
> Maciej
Running pixel test with a tolerance of 0.1 is still better than don't run pixel 
tests at all. So if we get a consensus with a small tolerance, I'm fine.
And yes, we might get problems with a new MacOS release. We have a lot of 
differences (<0.1%) between 10.5 and 10.6 right now.
But I don't see a problem with it as long as someone manages the results. Niko 
and I are doing it for SVG on MacOSX 10.6 and also continue it on 10.5 for a 
while.

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

Re: [webkit-dev] Pixel test experiment

[Dirk Schulze]

Does it support pixel test updates? Is it possible to extend this tool if not? 
This would limit the maintenance cost and every commiter should rebaseline mac 
if the change is a progression, or the difference is machine dependent
(but not OS dependent).

Dirk

Am 12.10.2010 um 22:49 schrieb Adam Barth:

> On Tue, Oct 12, 2010 at 1:43 PM, James Robinson  wrote:
>> - Do we have the tools and infrastructure needed to do mass rebaselines in
>> WebKit currently?  We've built a number of tools to deal with the Chromium
>> expectations, but since this has been a need unique to Chromium so far the
>> tools only work for Chromium.
> 
> webkit-patch has a very primitive "rebaseline" command.  There are
> some bugs on file on making it better.
> 
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] MathML renderer

[Dirk Schulze]

Hi webkit-dev,

I was looking at the MathML code recently and I wonder, that all files are 
located at WebCore/mathml, even the renderer. Shouldn't the rendering code be 
moved to WebCore/rendering/? Or better WebCore/rendering/mathml/?

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

Re: [webkit-dev] MathML renderer

[Dirk Schulze]

Am 05.01.2011 um 06:14 schrieb Maciej Stachowiak:

> It might make sense to use subdirectories of rendering/, as svg has started 
> to (although this seems incomplete - SVG folks, is the plan to move the 
> remaining SVG-related rendering files from rendering/ to rendering/svg?).
> 
Yes it is on the TODO list :-P

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

Re: [webkit-dev] The future of TransformationMatrix

[Dirk Schulze]

At first SVGMatrix and the complete SVG code itself is not using 
TransformationMatrix. We had bigger performance problems and the memory amount 
raised up by 6-10%. Thats why we decided to turn back to AffineTransform.

Because of the platform dependencies of TransformationMatrix. I noted that 
replacing AffineTransform, that was platform dependent at that time, by 
TransformationMatrix, which wasn't, may cause performance losses. At this time 
it was not clear that we would use 3D all over the place. I was told that the 
great benefit of a independent implementation is, that we get same results 
across platforms (a bigger problem that we saw on DRT and which caused a lot of 
platform dependent results). Is this argument not valid or important anymore?

Cheers
Dirk

> 
> The current reworking of the TransformationMatrix class and friends 
> (https://bugs.webkit.org/show_bug.cgi?id=48031) got me thinking about the 
> future of this class. I've chit chatted about this with various people, but 
> nothing serious has been done yet.
> 
> As WebKit and "HTML5" get more 3D functionality (CSS Transforms now, WebGL 
> later) a 4x4 matrix class becomes more important. There has even been talk of 
> adding 3D transforms to SVG. Today, the workhorse 3D matrix class is 
> TransformationMatrix. This is used by SVGMatrix and CSSMatrix and internally 
> in several places. The above bug is making the functions in 
> TransformationMatrix more rational and that is a good first step. But we need 
> to architect the most efficient class hierarchy in this area as possible. 
> 
> For instance, today you can use CSSMatrix in WebGL. But it has an inordinate 
> amount of overhead because the class is immutable. So every call that is made 
> must construct a new CSSMatrix. This not only adds call overhead, but in the 
> GC workload as well. I feel that making a mutable 4x4 matrix available is 
> very important. This could be done with a base Matrix class, available to 
> JavaScript, which would have mutable calls. Then SVGMatrix and CSSMatrix 
> could derive from this with their own APIs. 
> 
> Internally, I think we should eventually restructure TransformationMatrix to 
> have mutable fast-path operations. Today, for instance, operator*= calls into 
> the operator* class, so there's always an extra matrix copy. That should be 
> changed and we should similarly have mutable versions of all the calls 
> (translate, rotate, etc.) on the fast path.
> 
> We should also restructure TransformationMatrix to allow for platform 
> specific versions of the calls. For instance, PLATFORM(CA) has access to 
> CATransform3D, which has accelerated versions of its API where possible. I'm 
> sure QMatrix, SkMatrix and others might also be able to be used for similar 
> performance gains.
> 
> I've opened a couple of bugs for this:
> 
>   https://bugs.webkit.org/show_bug.cgi?id=52488
>   https://bugs.webkit.org/show_bug.cgi?id=52490
> 
> Please feel free to comment here or there…
> 
> -
> ~Chris
> cmar...@apple.com
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] Irregular nightly builds

[Dirk Schulze]

Hi

I noticed that we have irregular nightly builds for Mac 
(http://nightly.webkit.org/builds/trunk/mac/1). Between two builds is sometimes 
more than a week. I'm tracking a bug that was introduced between 2010-12-17 and 
2011-01-08. More than 1000 Patches were committed during that time. This makes 
it much harder to find the exact revision that causes the problem. What is the 
reason for the rare number of builds?

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

Re: [webkit-dev] Irregular nightly builds

[Dirk Schulze]

> Reorganising the source tree like we've been doing recently means that the 
> build scripts for the nightlies have to be updated.  A number of the places 
> where the updates were needed were very late in the build process, meaning 
> that a three hour turnaround per attempt at a fix was required.  When 
> combined with the occasional build breakage on trunk during my attempts at 
> spinning builds, this led to a larger dead period in the nightlies than I 
> would have liked.
> 
> - Mark
> 

Thanks for your working on that Mark!

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

Re: [webkit-dev] bugid in ChangeLog

[Dirk Schulze]

> If you use webkit-patch everything just magically works (yay!!)
> 
> --Oliver
> 

I agree! And if people would use it on uploading patches to a bug report, we 
wouldn't need a style-bot.

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

Re: [webkit-dev] Writing a new XML parser with no external libraries

[Dirk Schulze]

Am 29.06.2011 um 05:42 schrieb TAMURA, Kent:

> I'm a little negative of developing a new XML parser. I'm afraid that the new 
> parser introduces a lot of security/stability problems which existing parsers 
> already resolved.

I feel the same. Writing a new parser from scratch means introducing a lot of 
new security bugs, parsing errors and maybe bigger performance lost at the 
beginning. Speaking from the SVG side, we fail at least three tests on the W3C 
SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these bugs 
are fixed in later versions of libxml2. Updating libxml2 more often on MacOS 
would help a lot.

With the new parser we won't loose support XSLT and XLink support?

Dirk

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

Re: [webkit-dev] Timing updates for SVG SMIL animations

[Dirk Schulze]

Am 27.07.2011 um 23:03 schrieb Darin Fisher:

> Perhaps related to this thread, shouldn't we be basing SVG animations off of 
> the same animation scheduler that drives requestAnimationFrame and soon CSS 
> animations (https://bugs.webkit.org/show_bug.cgi?id=64591)?  It seems less 
> than ideal to use a Timer.
I'd love to share as much animation timing stuff as possible!

Dirk

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

Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?

[Dirk Schulze]

We could at least remove the subsets of SVG. Some developers build without SVG 
for compile time reasons.

Dirk

Am 09.09.2011 um 23:45 schrieb Levi Weintraub:

> I know webOS ships (or doesn't these days?) sans-SVG.
> 
> On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel  wrote:
>> I am interested in removing the ENABLE_SVG define, and all associated
>> sub-defines
>> 
>> ENABLE_SVG_ANIMATION
>> ENABLE_SVG_AS_IMAGE
>> ENABLE_SVG_FONTS
>> ENABLE_SVG_FOREIGN_OBJECT
>> ENABLE_SVG_USE
>> 
>> SVG is part of HTML5, and all major ports compile and ship with SVG
>> enabled (and have for years).
>> 
>> Please let me know if you are compiling with ENABLE_SVG disabled.
>> 
>> -eric
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Color profiles in expected.png files

[Dirk Schulze]

The color profile switches automatically for me on running pixel tests with 
Lion or SL. How is it even possible that we got images with different color 
profiles for mac results?

Dirk

Simon Fraser:
> It turns out that some of the layout test expected.png files have color 
> profiles (Generic RGB), and some do not 
> .
> 
> On my Lion machine, at least, this affects the appearance of the standard 
> green color, and causes pixel tests to fail.
> 
> It appears that these files have come from various sources, including Tony 
> Chang's embedding of checksums in image files, and new expected results 
> created on Lion.
> 
> I think we should be consistent about color profiles, and in a way that 
> doesn't break pixel tests. Does anyone want to vote one way or the other?
> 
> Once we decide, we should also have some kind of protection against adding 
> new pixel results which don't follow convention. Maybe webkit-patch can be 
> taught about this.
> 
> Simon
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Starting implementation on W3C Filter Effects

[Dirk Schulze]

Dean, do you want to reuse the existing filter code, or do you plan to write 
another filter implementation just for CSS? Would be interesting if we would 
need to nest CSS_FILTERS and FILTERS, or if they could get enabled independent 
of each other.

Like previous comments mention, Apple still does not enable SVG Filters for 
Safari or Safari mobile. Once you reuse some code and enable CSS_ENABLE, it 
would force FILTERS to get enabled as well.

Cheers
Dirk


Am 22.09.2011 um 22:06 schrieb Darin Adler:

> The settings in TOT are the settings for nightly builds. They don't 
> necessarily make it clear what Apple does for releases. There are features 
> like this one that we’ve been turning off on release branches.
> 
>-- Darin
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] new APIs for strokes with dash in Canvas

[Dirk Schulze]

The WebCore patch of Young is basically using the specified behavior of 
stroke-dasharray and stroke-dashoffset in the SVG specification [1]. But we 
wouldn't support units or percentages, just floating point numbers.

Dirk

Am 23.09.2011 um 07:38 schrieb Young Han Lee:

> On Fri, Sep 23, 2011 at 1:44 PM, Ian Hickson  wrote:
> 
> Is there any documentation on how this patch and Gecko's implementation
> work and what they support?
> 
> 
> I spent some time trying to find it, but couldn't. This bugzilla seems to be 
> the only place we can get information at the moment.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=662038 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Pixel testing and WebKit2

[Dirk Schulze]

Am 12.10.2011 um 00:24 schrieb Simon Fraser:

> For this reason, I'd like to propose that on Mac, all pixel testing is done 
> using WebKit2, which you can get by passing "-2" to run-webkit-tests or 
> new-run-webkit-tests. I can fix the scripts to print a warning if you pass 
> --pixel without -2 (or make --pixel use -2 by default).
I'd suggest to do both: make -2 default and warn if it is not set.

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

[webkit-dev] OpenCL implementation of W3C Filter Effects

[Dirk Schulze]

I plan to use OpenCL to HW accelerate SVG and CSS Filters [1]. I'm targeting 
OpenCL 1.1 which consists of two profiles: 'full' for the Desktop and 
'embedded' for embedded devices like mobile phones. For filters I'll use 
OpenCLs facilities for image processing from the 'full' profile. The most 
graphic chip manufactures like Imagination [2],[3] support even this part that 
is optional for the 'embedded' profile.

Right now I plan to reuse the current structure of our filters implementation 
as much as possible. So we can continue to calculate and use the smallest 
intermediate image buffers. I'll make sure that we don't have unnecessary data 
transfers between host and computing device. Just the data transfer for the 
source image to the device and the data transfer of the result to the host will 
be used. Therefore I'll propose to proceed with the following steps:

1. Make FilterEffect::apply() independent from any imageBuffer / imageData 
management (this will be a benefit for other HW acceleration implementations 
like CIFilters or OpenGL ES as well).
2. Add a compiler flag to disable/enable OpenCL
3. Implement basic FilterOpenCL object that manages the image processing, the 
kernels, the memory objects and the devices.
4. Create kernels for filter effects. This will be done for every single filter 
effect in followup patches. At the beginning every filter effect just allocates 
empty memory on the device to not block already implemented effects. I'll start 
with implementing SourceGraphic, feOffset and feColorMatrix.
5. Implement fallback to the existing software rendering (or other HW 
accelerated rendering) if no OpenCL capable device was found.

I opened the master bug "OpenCL implementation of W3C Filter Effects Master 
Bug" to track all these steps.

Dirk

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
[2] http://www.imgtec.com/news/Release/index.asp?NewsID=516
[3] http://www.khronos.org/conformance/adopters/conformant-products/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dirk Schulze]

Am 24.10.2011 um 21:51 schrieb Adam Barth:

>> 
>> I'd like to know what the actual threat of such timing attacks are. I've 
>> seen claims of a maximum theoretical leak rate (in bits/s) but then counter 
>> claims that since, in this case, it would be hard to distinguish the 
>> difference in slowdown between CSS shaders and general page rendering, that 
>> the real rate is much lower. And, at least in the case of Safari, you can't 
>> always be sure that getting a rAF callback means you're about to draw.
>> 
>> Does anyone have hard data on this?
> 
> At a minimum, please do not land an implementation for this feature
> without a way for ports that are concerned about this security feature
> to disable it independently of both CSS_FILTERS and WEBGL.  Contrary
> to your previous assertion, the security implications are quite
> different than those with WebGL.
We already discussed the HW acceleration of SVG Filters on 
https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS 
Filters earlier on this mailing list. We agreed that we will continue to use 
the implemented software rendering as fallback for Filters. CSS Shaders won't 
be included. Shaders should just be supported if HW acceleration is enabled. 
And I think as a minimum consensus on bug 70099 most people on the thread 
agreed to go on with GraphicsContext3D for now. In my opinion it means we would 
have the same security concerns like on WebGL. That's also one reason why I 
think that the WEBGL flag would match these needs quite well, even if CSS 
Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS Shaders 
are deactivated (and ignored if web developers use them in their filter chain) 
and Filters take the software rendering fallback.

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

[webkit-dev] Subpixel Layout Update

[Dirk Schulze]

Hi Emil and Levi,

I have a question to sub pixels from the SVG point of view.

Right now a lot of content on renderers and also in RenderStyle uses 
LayoutPoint, LayoutSize, LayoutRect, Length… and so on. How would LayoutUnit 
deal with SVG's "float system"? Your Wiki says that SVG's float system stays 
unchanged. I assume that you mean that the source code of the SVG 
implementation will stay float based and not move to LayoutUnit. Is that 
correct?

So my question is, if we use code of renderers or RenderStyle that would work 
on LayoutUnits, would we still be confronted with rounding to fixed point 
units? Or can LayoutUnit deal floats than? In SVG we would still like to have 
float based results, not rounded to fixed point, even if it is better than 
integer. This would be interesting for supporting 'transform-origin' and other 
CSS features in SVG. Maybe it is just a misunderstanding from me. Thanks for 
any clarification.

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

Re: [webkit-dev] Subpixel Layout Update

[Dirk Schulze]

On Feb 21, 2012, at 10:13 AM, Levi Weintraub wrote:

Hi Dirk,

Inline:

On Sat, Feb 18, 2012 at 9:44 PM, Dirk Schulze 
mailto:dschu...@adobe.com>> wrote:
Hi Emil and Levi,

I have a question to sub pixels from the SVG point of view.

Right now a lot of content on renderers and also in RenderStyle uses 
LayoutPoint, LayoutSize, LayoutRect, Length… and so on. How would LayoutUnit 
deal with SVG's "float system"? Your Wiki says that SVG's float system stays 
unchanged. I assume that you mean that the source code of the SVG 
implementation will stay float based and not move to LayoutUnit. Is that 
correct?

Currently, when SVG code queries the Render Tree it receives results as 
integers or floats. The only change we're making is to replace those integers 
with a subpixel unit. Things that were floats before will remain so (including 
all SVG layout), and we'll only increase precision in other places.
I understand that. But if you look at RenderStyle::applyTransform() it takes 
LayoutSize. There are more examples like that. SVG could use some of these 
functions as well. That is why I hoped that LayoutSize and co could get more 
generic. Taking floats or integers and translating them to the needs of the 
addressor. But I understand the use case you are addressing. But this means we 
still have to use new functions to address the precision that is needed for SVG.

Another question: It looks like Length.h/cpp switch to float values internally 
in your branch. Will that go to trunk as well? That would help us a lot on SVG. 
Currently I try to implement transform-origin for SVG. The function 
Length::calcFloatValue should take a float to calculate a length value on SVG 
elements. I just notice that some tests started to fail after that change. I 
couldn't verify the differences (lack of time). When will these changes land? 
Will the complete branch land as a package, or in smaller chunks? How long does 
it take to land these parts (I am primarily interested in the change of Length 
:))?

Greetings,
Dirk



So my question is, if we use code of renderers or RenderStyle that would work 
on LayoutUnits, would we still be confronted with rounding to fixed point 
units? Or can LayoutUnit deal floats than? In SVG we would still like to have 
float based results, not rounded to fixed point, even if it is better than 
integer. This would be interesting for supporting 'transform-origin' and other 
CSS features in SVG. Maybe it is just a misunderstanding from me. Thanks for 
any clarification.

LayoutUnits will not be floats, but we are not replacing things that were 
floats with LayoutUnits. LayoutUnits will be integers that represent 1/60th of 
a pixel, and you'll be able to convert floats to and from LayoutUnits when 
needed. There should not be any additional rounding in SVG or anywhere else 
than there is now.

-Emil and Levi


Greetings,
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] -webkit-transform-origin-x,y CSS properties

[Dirk Schulze]

On Feb 29, 2012, at 9:44 AM, Simon Fraser wrote:

> On Feb 29, 2012, at 9:32 AM, Hans Muller wrote:
> 
>> 
>> Are the -webkit-transform-origin-x,y CSS properties on their way in our
>> out?  The ugly little test below demonstrates that they're probably not
>> supported by Opera or Mozilla.
> 
> They are not in the spec:
> 
> 
> We will not be supporting the unprefixed versions of these properties.
The question was more, if we will continue supporting the prefixed version of 
these properties. Even if you did not answer directly, your answer implies that 
you want to continue to support them.

Dirk

> 
> Simon
> 
>> CSSComputedStyleDeclaration::getPropertyCSSValue() in WebKit (explicitly)
>> ignores them.   Should they stay or should they go?  Or perhaps they
>> should just be left alone?
>> 
>> Thanks,
>> - Hans
>> 
>> 
>> 
>> 
>>   
>> 
>> div.square {
>>   position: absolute;
>>   top: 150px;
>>   left: 150px;
>>   width: 100px;
>>   height: 100px;
>>   background-color: blue;
>>   -webkit-transform-origin-x: -150px;
>>   -webkit-transform-origin-y: -150px;
>>   -webkit-transition: -webkit-transform 0.5s;
>>   -moz-transform-origin-x: -150px;
>>   -moz-transform-origin-y: -150px;
>>   -moz-transition: -moz-transform 0.5s;
>>   -o-transform-origin-x: -150px;
>>   -o-transform-origin-y: -150px;
>>   -o-transition: -o-transform 0.5s;
>> }
>> 
>> div.square:hover {
>> -webkit-transform: rotate(45deg);
>> -webki-transition: -webkit-transform 0.5s;
>> -moz-transform: rotate(45deg);
>> -moz-transition: -moz-transform 0.5s;
>> -o-transform: rotate(45deg);
>> -o-transition: -o-transform 0.5s;
>> }
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Dirk Schulze]

> 
> Different developers will have different priorities. HD image data and async 
> readback both have potential benefits in image quality and nonblocking 
> responsiveness respectively. Here is an example of an application using 
> getImageData which would clearly benefit from HD, but it's not obvious that 
> async would be useful:
> 
> http://mudcu.be/sketchpad/

This seems to be a use case for SVG and not canvas :)

Dirk

> 
> Here is another where HD helps but benefits of async are unclear, since it 
> does a pixel read-write-modify cycle:
> 
> http://nerget.com/pressure/pressure.html
> 
> Tying HD to async may hurt the adoption of both by requiring developers to 
> take two different code change hits when they only care about one. In 
> particular, the async change is likely to be more invasive to code structure. 
>  If developers are discouraged, they may end up using neither. Thus, in my 
> opinion, these two enhancements to ImageData should stand and fall on their 
> own merits.
> 
> Regards,
> Maciej
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Dirk Schulze]

On Apr 16, 2012, at 4:30 PM, Maciej Stachowiak wrote:

> 
> On Apr 16, 2012, at 4:03 PM, Dirk Schulze wrote:
> 
>>> 
>>> Different developers will have different priorities. HD image data and 
>>> async readback both have potential benefits in image quality and 
>>> nonblocking responsiveness respectively. Here is an example of an 
>>> application using getImageData which would clearly benefit from HD, but 
>>> it's not obvious that async would be useful:
>>> 
>>> http://mudcu.be/sketchpad/
>> 
>> This seems to be a use case for SVG and not canvas :)
> 
> It's a raster-oriented paint app, not a vector-oriented draw app, so I don't 
> think SVG would be helpful.
This is off topic, but I disagree. The only thing that you want is a rasterized 
result at the end. In the meantime it can be object and vector based (and in 
high resolution) on the screen. This would even allow you to create high 
resolution PNGs. I see a lot more benefits, but we can discuss it on another 
place.

Dirk

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

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

Re: [webkit-dev] WebKit SVG chatroulette

[Dirk Schulze]

On Apr 26, 2012, at 11:49 AM, Philip Rogers wrote:

> If you don't work on SVG in WebKit you can stop reading now.
> 
> 
> WebKit,
> 
> Is there interest in a 1hr video chat with WebKit people interested in SVG as 
> a followup to the WebKit contributors meeting? A few active SVG contributors 
> weren't able to make the meeting and we have some really cool topics to talk 
> about (SVG2.0, RenderLayer work, etc.)
Great idea! Can you set up another table with possible topics?

Greetings,
Dirk

> 
> If this sounds interesting to you or you just want to say moin to #ksvg 
> friends, please add your name and availability:
> https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdGRVRmJsendBYnB1dFFacE1mdV9PUEE
> 
> Thanks,
> Philip
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[webkit-dev] Test the Web Forward

[Dirk Schulze]

Hello WebKit community,

We want to announce the W3C event "Test the Web Forward" hosted by Adobe. This 
hackathon builds off the Move the Web Forward initiative in order to help get 
developers more involved in contributing to the web platform we all work to 
define.

During this hackathon, attendees will be learning about certain CSS and SVG 
features that need more tests in order to progress through the standards 
pipeline.

Find more information on the official website http://testthewebforward.org/

Registration will open on June 1st and space is limited, so bookmark the dates 
(June 15th and 16th at the Adobe San Francisco office) and we hope to see you 
there!

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

Re: [webkit-dev] testharness Wiki page added

[Dirk Schulze]

On May 31, 2012, at 7:55 PM, Maciej Stachowiak wrote:

> 
> On May 31, 2012, at 5:51 PM, Jacob Goldstein  wrote:
> 
>> I haven't found that to be the case for the tests I have written for each 
>> suite, the output from testharness can be as simple as "PASS" or "FAIL", or 
>> include additional debug information defined by the test author.  That being 
>> said, my experience is likely more limited than yours.  Peter Linss, who 
>> wrote and maintains the W3C testharness, would likely be open to suggestions 
>> for improvement if there is anything specific that we want to change.   
> 
> The source is more verbose. The output is uglier and less clear, at least by 
> default. "PASS" and "FAIL" is not as good as what our test driver does by 
> default, because you can't as easily tell what passed or failed or why. Our 
> own harness tells you the expression the test evaluated that failed, and what 
> the expected result was, so it's much quicker to debug a failure.
> 
> I have given my feedback to James Graham before, including showing him how 
> our test harness works. At the time, he was not open to making changes, in 
> part because of details of Opera's internal testing setup and in part because 
> "eval is evil". I really would rather not reduce all our DOM tests to the 
> Opera-driven level of source legibility and output quality.
I think it is time not to discuss it privately anymore. This is the test suite 
that is/will be used by the CSS WG. Therefore, if there are reasonable 
suggestions for improvement, we should discuss it on public mailing lists. 
webkit-dev is a great start, but since it is used by CSS WG and since all 
contributors, not just opera contributors, need to use it on the CSS WG test 
suite, it should be discussed on the CSS WG side. The responsible mailing list 
should be public-css-testsuite.

> 
> Let me give you an example. This zip file contains an actual w3c test case, 
> and a webkit-style conversion of the same test:
> 
> 
> 
> I have deliberately introduced the same failure into both. Which one do you 
> think would be easier to debug?
I agree, the output of the WebKit harness seems to be more useful and better 
for debugging. But I used to use the WebKit testing harness a lot. So my 
impressions are not independent.

Greetings,
Dirk

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

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

Re: [webkit-dev] SVG video chat (2)

[Dirk Schulze]

That would be great, but please also provide different times. I am not 
available from 9 to 12 mostly. So I have to say no to all provided times. 
Before or after that is fine.

Greetings,
Dirk

On Jun 7, 2012, at 9:48 AM, Philip Rogers wrote:

> Last month we had a video chat with the SVG team in WebKit and it was very 
> well received. If there are other highly-coupled, highly-distributed 
> sub-components of WebKit I would highly recommend setting one of these up.
> 
> 
> SVG,
> 
> The last video chat went great and as a group we decided to do it again. If 
> you'd like to join please add your name, availability, and topics you'd like 
> to discuss to the spreadsheet:
> https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdDQ3RUM0bzlGZUpENnAtTHh5aFJBU0E
> 
> Thanks,
> Philip

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

Re: [webkit-dev] Delaying Applying CSS Effects

[Dirk Schulze]

In SVG we have SVGResourcesCache which takes care of that.

Greetings,
Dirk

On Jul 24, 2012, at 3:56 PM, Dean Jackson wrote:

> 
> On 25/07/2012, at 6:09 AM, Keyar Hood  wrote:
> 
>> I am working on https://bugs.webkit.org/show_bug.cgi?id=90405
>> 
>> The problem is that when doing SVG filters in CSS using URL references, if 
>> the target SVG filter is after the element that the filter is to be applied 
>> to (the filtered element), then the filter will not be applied.
>> 
>> Looking at the code, a getElementByID() call is made when looking for the 
>> target SVG filter. However, this does not work when the target SVG filter is 
>> after the filtered element. I believe this is because the DOM element for 
>> the target SVG filter does not exist yet.
>> 
>> I am wondering if there is some way to delay resolving these CSS effects 
>> until after the DOM has finished loading.
> 
> Your analysis sounds right. I think we'll have to do exactly that: delay 
> calling buildFilterEffectRenderer until the document has loaded.
> 
> Dean
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Dirk Schulze]

On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:

> Eric Seidel points out that SVG uses multiple inheritance in its DOM
> interfaces.  However, the situation there is a bit different.
> Although SVGSVGElement implements SVGLocatable, there aren't any
> interfaces with methods that return SVGLocatable, which means we don't
> need to implement toJS(SVGLocatable*).
SVG 2 will use WebIDL. Therefore we also reorganize our inheritance behavior. 
Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED soon.

Greetings,
Dirk

> 
> He also points out that Node inherits from EventTarget, which already
> contains a virtual interfaceName() function similar to that used by
> Event.  That pushes us further towards using a common DOMInterface
> base class because introducing Region::interfaceName would mean that
> Element would see both EventTarget::interfaceName and
> Region::interfaceName.
> 
> Adam
> 
> 
> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>> The CSS Regions specification [1] defines a CSSOM interface named
>> Region, which can be mixed into interfaces for other objets that can
>> be CSS regions.  That means that Region introduces a form of multiple
>> inheritance into the DOM.  For example, Element implements Region but
>> Node does not implement Region.
>> 
>> There's a patch up for review that implements Region using C++
>> multiple inheritance [2]:
>> 
>> - class Element : public ContainerNode {
>> + class Element : public ContainerNode, public CSSRegion {
>> 
>> One difficulty in implementing this feature how to determine the
>> correct JavaScript wrapper return for a given Region object.
>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>> an Element if the Region pointer actually points to an Element
>> instance.
>> 
>> We've faced a similar problem elsewhere in the DOM when implementing
>> normal single inheritance.  For example, there are many subclass of
>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>> subtype.  To solve the same problem, CSSRule has a m_type member
>> variable and a bevy of isFoo() functions [3].
>> 
>> A) Should we push back on the folks writing the CSS Regions
>> specification to avoid using multiple inheritance?  As far as I know,
>> this is the only instance of multiple inheritance in the platform.
>> Historically, EventTarget used multiple inheritance, but that's been
>> fixed in DOM4 [4].
>> 
>> B) If CSS Regions continues to require multiple inheritance, should we
>> build another one-off RTTI replacement to implement toJS(Region*), or
>> should we improve our bindings to implement this aspect of WebIDL more
>> completely?
>> 
>> One approach to implementing toJS in a systematic way is to introduce
>> a base class DOMInterface along these lines:
>> 
>> class DOMInterface {
>> public:
>>virtual const AtomicString& primaryInterfaceName() = 0;
>> }
>> 
>> That returns the name of the primary interface (i.e., as defined by
>> WebIDL [5]).  When implementing toJS, we'd then call
>> primaryInterfaceName to determine which kind of wrapper to use.
>> 
>> One downside of this approach is that it introduces a near-universal
>> base class along the lines of IUnknown [6] or nsISupports [7].  I
>> don't think any of us want WebKit to grow an implementation of
>> XPCOM...
>> 
>> I welcome any thoughts you have on this topic.
>> 
>> Thanks,
>> Adam
>> 
>> [1] http://dev.w3.org/csswg/css3-regions/
>> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>> [3] 
>> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>> [4] http://www.w3.org/TR/dom/#node
>> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>> [6] 
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Multiple inheritance in the DOM

[Dirk Schulze]

On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:

> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
>> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>> interfaces.  However, the situation there is a bit different.
>>> Although SVGSVGElement implements SVGLocatable, there aren't any
>>> interfaces with methods that return SVGLocatable, which means we don't
>>> need to implement toJS(SVGLocatable*).
>> 
>> SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
>> behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED 
>> soon.
> 
> Do you anticipate adding properties or functions that return
> interfaces like SVGLocatable?
Here is a Wiki what we plan to do: 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization

It might not reflect all changes that we discussed during the SVG WG meeting 
today.

Greetings,
Dirk

> 
> Adam
> 
> 
>>> He also points out that Node inherits from EventTarget, which already
>>> contains a virtual interfaceName() function similar to that used by
>>> Event.  That pushes us further towards using a common DOMInterface
>>> base class because introducing Region::interfaceName would mean that
>>> Element would see both EventTarget::interfaceName and
>>> Region::interfaceName.
>>> 
>>> Adam
>>> 
>>> 
>>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>>>> The CSS Regions specification [1] defines a CSSOM interface named
>>>> Region, which can be mixed into interfaces for other objets that can
>>>> be CSS regions.  That means that Region introduces a form of multiple
>>>> inheritance into the DOM.  For example, Element implements Region but
>>>> Node does not implement Region.
>>>> 
>>>> There's a patch up for review that implements Region using C++
>>>> multiple inheritance [2]:
>>>> 
>>>> - class Element : public ContainerNode {
>>>> + class Element : public ContainerNode, public CSSRegion {
>>>> 
>>>> One difficulty in implementing this feature how to determine the
>>>> correct JavaScript wrapper return for a given Region object.
>>>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>>>> an Element if the Region pointer actually points to an Element
>>>> instance.
>>>> 
>>>> We've faced a similar problem elsewhere in the DOM when implementing
>>>> normal single inheritance.  For example, there are many subclass of
>>>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>>>> subtype.  To solve the same problem, CSSRule has a m_type member
>>>> variable and a bevy of isFoo() functions [3].
>>>> 
>>>> A) Should we push back on the folks writing the CSS Regions
>>>> specification to avoid using multiple inheritance?  As far as I know,
>>>> this is the only instance of multiple inheritance in the platform.
>>>> Historically, EventTarget used multiple inheritance, but that's been
>>>> fixed in DOM4 [4].
>>>> 
>>>> B) If CSS Regions continues to require multiple inheritance, should we
>>>> build another one-off RTTI replacement to implement toJS(Region*), or
>>>> should we improve our bindings to implement this aspect of WebIDL more
>>>> completely?
>>>> 
>>>> One approach to implementing toJS in a systematic way is to introduce
>>>> a base class DOMInterface along these lines:
>>>> 
>>>> class DOMInterface {
>>>> public:
>>>>   virtual const AtomicString& primaryInterfaceName() = 0;
>>>> }
>>>> 
>>>> That returns the name of the primary interface (i.e., as defined by
>>>> WebIDL [5]).  When implementing toJS, we'd then call
>>>> primaryInterfaceName to determine which kind of wrapper to use.
>>>> 
>>>> One downside of this approach is that it introduces a near-universal
>>>> base class along the lines of IUnknown [6] or nsISupports [7].  I
>>>> don't think any of us want WebKit to grow an implementation of
>>>> XPCOM...
>>>> 
>>>> I welcome any thoughts you have on this topic.
>>>> 
>>>> Thanks,
>>>> Adam
>>>> 
>>>> [1] http://dev.w3.org/csswg/css3-regions/
>>>> [2] https://bugs.webkit.org/show_bug.cgi?id=91076
>>>> [3] 
>>>> http://trac.webkit.org/browser/trunk/Source/WebCore/css/CSSRule.h?rev=123653#L65
>>>> [4] http://www.w3.org/TR/dom/#node
>>>> [5] http://www.w3.org/TR/WebIDL/#dfn-primary-interface
>>>> [6] 
>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms680509(v=vs.85).aspx
>>>> [7] https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsISupports
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Kerning not working for SVG font when included in HTML file using @font-face

[Dirk Schulze]

Thank you very much for reporting the bug Tony. In this case opening a bug 
report at http://bugs.webkit.org may be better.

Greetings,
Dirk

On Aug 1, 2012, at 9:26 AM, Peter Beverloo  wrote:

> Please use the webkit-h...@lists.webkit.org mailing list for questions such 
> as this one, as webkit-dev is intended as a forum for WebKit developers. In 
> general, if exactly the same code behaves differently in WebKit compared to 
> other browsers, or WebKit's implementation is different from what the 
> specification says, you're always welcome to file a bug on 
> http://bugs.webkit.org/.
> 
> Thanks,
> Peter
> 
> On Wed, Aug 1, 2012 at 5:23 PM, tony  wrote:
> Hi,
> I created a SVG font file and wanted to try kerning between two glyphs (V and 
> G in the attached file).
> The kerning works when open the SVG in browser but does not work if i include 
> it in HTML styles using @font-face.
> Please let me know if i am doing something wrong or is it a bug in webkit.
> 
> PS: The same SVG font file when converted to ttf and the ttf refered to using 
> @font-face in HTML works fine in Firefox14.
> 
> Thanks
> Tony 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

[Dirk Schulze]

On Aug 12, 2012, at 6:26 PM, Florin Malita  wrote:

> And down it goes again…
It is down for me as well…

Dirk

PS: Sorry, I always wanted to that :D

> 
> On Fri, Aug 10, 2012 at 11:14 AM, Levi Weintraub  wrote:
> We're back!
> 
> 
> On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo  wrote:
> It's been down for the past hour, again.  Just a nudge in case it slipped 
> through.
> 
> Peter
> 
> 
> On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba  
> wrote:
> Hi,
> 
> bugs.webkit.org and trac.webkit.org is unavailable again. :(
> Could you check it, please?
> 
> br,
> Ossy
> 
> Osztrogonac Csaba írta:
> 
> It seems bugs.webkit.org and trac.webkit.org is unavailable
> now. (at least from Hungary) Have you got any idea what happened?
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Is the New XMLParser dead?

[Dirk Schulze]

On Aug 27, 2012, at 4:28 PM, Adam Barth  wrote:

> On Mon, Aug 27, 2012 at 4:02 PM, Maciej Stachowiak  wrote:
>> On Aug 27, 2012, at 3:48 PM, Adam Barth  wrote:
>>> On Mon, Aug 27, 2012 at 3:06 PM, Maciej Stachowiak  wrote:
 On Aug 27, 2012, at 2:45 PM, Eric Seidel  wrote:
> Checking back in:
> 
> Curious if this effort is still underway.  Adam and I would like to
> delete the New XML Parser if it's not needed in order to simplify the
> HTML 5 Parser again. :)
 
 We do tentatively plan to get back to it (the original implementor is 
 currently working full-time at Apple on the WebKit team).
>>> 
>>> As far as I can tell, no one has worked on the NEWXML code in over a
>>> year, the implementation doesn't work, and the code is disabled by all
>>> ports.  It seems like we should remove it from trunk.  We can retore
>>> it if/when someone is interested in working on it again.
>> 
>> What you describe as the current status is (afaik) correct. The data point I 
>> provided (since Eric asked) is that we do in fact plan to get back to it.
>> 
 As far as simplifying the HTML5 parser - isn't most of the foundational 
 work that touches the HTML5 parser also required for WebVTT, as mentioned 
 by me in the email you quote below? Is there a big simplicity win to be 
 had without breaking WebVTT? If so, we can think about whether removing 
 the scaffolding and reconstructing it when needed is worthwhile.
>>> 
>>> This is a separate issue.
>> 
>> If there's a reason to remove it other than "simplify the HTML5 parser 
>> again", then certainly we can consider it. But that was the only reason Eric 
>> cited, so I wanted to check if it's actually the case, in light of WebVTT. I 
>> am still curious about the answer. But I'd be happy to discuss other reasons 
>> instead.
> 
> My understanding is that we don't typically leave broken, unused code
> in trunk unless someone is actively working on it.  Having this code
> around has costs and little benefit:
> 
> 1) The code needs to be maintained.
> 2) The code confuses contributors who don't know that it's dead.
> 
> By contrast, if someone wants to work on this code again, they can
> just revert the patch that removed it.  They might need to do some
> maintenance work at that point, but that's work that otherwise would
> have to have been done by someone else.
Ha! So the reason for removing the code is simplifying the HTML5 parser, just 
to undo the simplification once the original writer has the time to come back 
to it. Seems like well spend time :)

Greetings,
Dirk

> 
> As for VTT, I suspect that the VTT parser doesn't need all the
> complexity that the HTML parser needs.  It's doing a much simpler task
> and likely can be made much simpler by not try to share code with the
> HTML parser at all.
> 
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] CSS Masking in WebKit

[Dirk Schulze]

Hi WebKit folks,

The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. 
Basically the spec aims to specify the behavior of 
-webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath on 
Firefox.

I would like to implement the specification in the next weeks and months. Since 
masking and clipping are basic operations that use the existing capabilities in 
all graphic libraries, and sine we are using it heavily internally in WebKit 
already, I do not plan to introduce a new compiler flag. 

However, some features will be covered by existing compiler flags like SVG Mask 
and SVG ClipPath, allowing to disable these parts.

I created a master bug that covers the work [2].

Greetings,
Dirk

[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
[2] https://bugs.webkit.org/show_bug.cgi?id=95389
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CSS Masking in WebKit

[Dirk Schulze]

Hi Dave,

On Aug 31, 2012, at 11:57 AM, David Hyatt  wrote:

> This is great! I'd like to be the goto reviewer for any changes you make on 
> the CSS Masking side, since I implemented the original code. I also want to 
> be kept in the loop if any changes are made to the way any of the 
> -webkit-mask-* properties are specified. There are some interesting 
> differences (especially in default values) when compared with the 
> corresponding background/border-image properties, and I want to make sure all 
> of that is well understood.
I try to be careful and definitely keep you in the loop for -webkit-mask* 
related patches. Thank you for your interest!

> 
> Also, it's important to make sure if there are any deviations/changes, that 
> the -webkit-prefixed versions of these properties don't change behavior. 
> Backwards compatibility is extremely important here. You'll notice that the 
> way I preserved backwards compatibility on border-image for example was to go 
> ahead and implement the unprefixed versions. I don't really have a good 
> suggestion for how to do that here... it's possible a new prefix will be 
> necessary.  It all depends on if any changes are made that would break 
> existing code.
There is indeed one change in the Spec, that differs to the behavior in WebKit. 
The CSS WG resolved to remove -webkit-mask-attachment from the specification 
(unless it is requested by developers to add it again). This itself doesn't 
affect the behavior on WebKit much - rendering wise. However, it influences the 
syntax of the the shorthand -webkit-mask, which doesn't take  as 
type anymore.

Greetings,
Dirk

> 
> dave
> (hy...@apple.com)
> 
> On Aug 29, 2012, at 5:41 PM, Dirk Schulze wrote:
> 
>> Hi WebKit folks,
>> 
>> The CSS WG and SVG WG agreed to work on a CSS Masking specification [1]. 
>> Basically the spec aims to specify the behavior of 
>> -webkit-mask/-webkit-box-mask on WebKit browsers and SVG Mask/ SVG ClipPath 
>> on Firefox.
>> 
>> I would like to implement the specification in the next weeks and months. 
>> Since masking and clipping are basic operations that use the existing 
>> capabilities in all graphic libraries, and sine we are using it heavily 
>> internally in WebKit already, I do not plan to introduce a new compiler 
>> flag. 
>> 
>> However, some features will be covered by existing compiler flags like SVG 
>> Mask and SVG ClipPath, allowing to disable these parts.
>> 
>> I created a master bug that covers the work [2].
>> 
>> Greetings,
>> Dirk
>> 
>> [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
>> [2] https://bugs.webkit.org/show_bug.cgi?id=95389
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] String::operator+= considered harmful

[Dirk Schulze]

I thought we had efforts to make String::operator+= use StringBuilder somehow? 
I can remember that we had a discussion on webkit-dev and definitely on 
bugzilla about improving String::operator+= instead of replacing it with 
StringBuilder.

Greetings,
Dirk

On Sep 4, 2012, at 4:22 PM, Adam Barth  wrote:

> As part of the work to deploy efficient string patterns [1] throughout
> WebKit, Benjamin and I noticed a bunch of very inefficient code that
> uses operator+= with Strings:
> 
> String foo;
> for (...)
>  foo += [...];
> return foo;
> 
> This pattern is particularly inefficient because += mallocs an
> entirely new buffer for the result and copies the the string into the
> new buffer.  That means that this pattern makes O(n) calls to malloc
> and does O(n^2) work.  A more efficient pattern is to use
> StringBuilder:
> 
> StringBuilder foo;
> for (...)
>  foo.append([...]);
> return foo.toString();
> 
> I'm in the process of going through WebCore and removing all callers
> of WTF::String::operator+=.  Once that's complete, my plan is to
> remove WTF::String::operator+= from WTFString.h.  Hopefully that will
> nudge contributors and reviewers towards more efficient string
> patterns.
> 
> Removing operator+= will likely require changes to a number of
> port-specific files.  I'll do my best to remove these, but I might
> need some help from maintainers of individual ports.  If you're
> interested in helping out, please let me know.
> 
> Many thanks,
> Adam
> 
> [1] http://trac.webkit.org/wiki/EfficientStrings
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] String::operator+= considered harmful

[Dirk Schulze]

With a short search in the logs I found optimizations for  at least operator+, 
but didn't search further:

http://trac.webkit.org/changeset/86330
https://bugs.webkit.org/show_bug.cgi?id=58420

Greetings,
Dirk

On Sep 4, 2012, at 4:31 PM, Adam Barth  wrote:

> Do you have a proposal for how that would work and/or a link to the
> previous discussion?
> 
> Adam
> 
> 
> On Tue, Sep 4, 2012 at 4:27 PM, Dirk Schulze  wrote:
>> I thought we had efforts to make String::operator+= use StringBuilder 
>> somehow? I can remember that we had a discussion on webkit-dev and 
>> definitely on bugzilla about improving String::operator+= instead of 
>> replacing it with StringBuilder.
>> 
>> Greetings,
>> Dirk
>> 
>> On Sep 4, 2012, at 4:22 PM, Adam Barth  wrote:
>> 
>>> As part of the work to deploy efficient string patterns [1] throughout
>>> WebKit, Benjamin and I noticed a bunch of very inefficient code that
>>> uses operator+= with Strings:
>>> 
>>> String foo;
>>> for (...)
>>> foo += [...];
>>> return foo;
>>> 
>>> This pattern is particularly inefficient because += mallocs an
>>> entirely new buffer for the result and copies the the string into the
>>> new buffer.  That means that this pattern makes O(n) calls to malloc
>>> and does O(n^2) work.  A more efficient pattern is to use
>>> StringBuilder:
>>> 
>>> StringBuilder foo;
>>> for (...)
>>> foo.append([...]);
>>> return foo.toString();
>>> 
>>> I'm in the process of going through WebCore and removing all callers
>>> of WTF::String::operator+=.  Once that's complete, my plan is to
>>> remove WTF::String::operator+= from WTFString.h.  Hopefully that will
>>> nudge contributors and reviewers towards more efficient string
>>> patterns.
>>> 
>>> Removing operator+= will likely require changes to a number of
>>> port-specific files.  I'll do my best to remove these, but I might
>>> need some help from maintainers of individual ports.  If you're
>>> interested in helping out, please let me know.
>>> 
>>> Many thanks,
>>> Adam
>>> 
>>> [1] http://trac.webkit.org/wiki/EfficientStrings
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] String::operator+= considered harmful

[Dirk Schulze]

Yes, looks like the efforts didn't went further. Anyway, is there no 
possibility to improve operator+= further? It is very likely that even future 
code will land with this operator instead of StringBuilder. I think it is 
better to try to change the operator (if possible) instead of people.

Greetings,
Dirk

On Sep 4, 2012, at 4:41 PM, Adam Barth  wrote:

> Ah, you're think of operator+, which is now quite efficient.  This
> thread is about operator+=, which is sadly slower than molasses.
> 
> Adam
> 
> 
> On Tue, Sep 4, 2012 at 4:38 PM, Dirk Schulze  wrote:
>> With a short search in the logs I found optimizations for  at least 
>> operator+, but didn't search further:
>> 
>> http://trac.webkit.org/changeset/86330
>> https://bugs.webkit.org/show_bug.cgi?id=58420
>> 
>> Greetings,
>> Dirk
>> 
>> On Sep 4, 2012, at 4:31 PM, Adam Barth  wrote:
>> 
>>> Do you have a proposal for how that would work and/or a link to the
>>> previous discussion?
>>> 
>>> Adam
>>> 
>>> 
>>> On Tue, Sep 4, 2012 at 4:27 PM, Dirk Schulze  wrote:
>>>> I thought we had efforts to make String::operator+= use StringBuilder 
>>>> somehow? I can remember that we had a discussion on webkit-dev and 
>>>> definitely on bugzilla about improving String::operator+= instead of 
>>>> replacing it with StringBuilder.
>>>> 
>>>> Greetings,
>>>> Dirk
>>>> 
>>>> On Sep 4, 2012, at 4:22 PM, Adam Barth  wrote:
>>>> 
>>>>> As part of the work to deploy efficient string patterns [1] throughout
>>>>> WebKit, Benjamin and I noticed a bunch of very inefficient code that
>>>>> uses operator+= with Strings:
>>>>> 
>>>>> String foo;
>>>>> for (...)
>>>>> foo += [...];
>>>>> return foo;
>>>>> 
>>>>> This pattern is particularly inefficient because += mallocs an
>>>>> entirely new buffer for the result and copies the the string into the
>>>>> new buffer.  That means that this pattern makes O(n) calls to malloc
>>>>> and does O(n^2) work.  A more efficient pattern is to use
>>>>> StringBuilder:
>>>>> 
>>>>> StringBuilder foo;
>>>>> for (...)
>>>>> foo.append([...]);
>>>>> return foo.toString();
>>>>> 
>>>>> I'm in the process of going through WebCore and removing all callers
>>>>> of WTF::String::operator+=.  Once that's complete, my plan is to
>>>>> remove WTF::String::operator+= from WTFString.h.  Hopefully that will
>>>>> nudge contributors and reviewers towards more efficient string
>>>>> patterns.
>>>>> 
>>>>> Removing operator+= will likely require changes to a number of
>>>>> port-specific files.  I'll do my best to remove these, but I might
>>>>> need some help from maintainers of individual ports.  If you're
>>>>> interested in helping out, please let me know.
>>>>> 
>>>>> Many thanks,
>>>>> Adam
>>>>> 
>>>>> [1] http://trac.webkit.org/wiki/EfficientStrings
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Anyone willing to update webkit.org?

[Dirk Schulze]

On Sep 18, 2012, at 7:04 PM, Eric Seidel  wrote:

> I was noticing today that http://www.webkit.org/ is quite old and out
> of date.  What xenon built 6 years ago, has stood up remarkably well,
> but it may be time for a refresh.
> (It also has no high-dpi support.)
> 
> I'm aware that I have the ability to change it.  But I'm also inviting
> others to do so:
> http://trac.webkit.org/browser/trunk/Websites/webkit.org
> 
> In particular:
> - It mentions nothing of Safari on iOS or Chrome (which must be some
> huge fraction of our userbase by now)
> - Could link to numerous other sites showing information about WebKit
> (cia, ohloh, svnsearch)
> - Projects like "SVG" really aren't the current focus. :)
They are not? Maybe not for you :)

Dirk

> 
> I'm sure this list is full of individuals with infinitely more visual
> design sense than I.  So I invite your patches, my reviewing and
> committing fingers stand ready. :)
> 
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] New Feature: Canvas Path object

[Dirk Schulze]

Hi WebKit,

I would like to ask if there are objections to implement the canvas Path object.

The HTML Canvas specification and the WHAT WG HTML specification define the 
Path object [1][2]. The Path object and the CanvasRenderingContext2D share some 
graphics operations[3]: 

- closePath
- lineTo
- moveTo
- arc
- arcTo
- ellipse (not implemented yet)
- quadraticCurveTo
- cubicCurveTo
- rect

But instead of drawing onto a Canvas, the operations get applied to a Path 
object. Furthermore the object allows adding other Paths with transforms. A 
Path object can then be drawn onto a Canvas.

I opened https://bugs.webkit.org/show_bug.cgi?id=97333 for a patch and detailed 
discussions.

Greetings,
Dirk

[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects
[2] http://dev.w3.org/html5/2dcontext/#path-objects
[3] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New Feature: Canvas Path object

[Dirk Schulze]

I know of at least one JS library that uses Path as object (paper.js). But the 
definition can be overridden. It is unlikely that this will break content, as 
long as the library does not want to use both. Other then that, the SVG WG 
wants to reuse the Path object in SVG and CanvasObject might confuse people but 
this seems unlikely as well.

Greetings,
Dirk

Sent from my iPhone

On Sep 23, 2012, at 6:22 AM, "Elliott Sprehn" 
mailto:espr...@chromium.org>> wrote:


On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze 
mailto:dschu...@adobe.com>> wrote:
Hi WebKit,

I would like to ask if there are objections to implement the canvas Path object.


Do we have metrics on how often people already have things named Path? All 
other canvas objects have a prefix like CanvasGradient and CanvasPattern, this 
thing seems inconsistent and more likely to break existing pages.

- E

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

Re: [webkit-dev] New Feature: Canvas Path object

[Dirk Schulze]

On Sep 24, 2012, at 12:03 PM, "Rik Cabanier" 
mailto:caban...@gmail.com>> wrote:



On Mon, Sep 24, 2012 at 10:27 AM, Darin Adler 
mailto:da...@apple.com>> wrote:
On Sep 22, 2012, at 9:21 PM, Elliott Sprehn 
mailto:espr...@chromium.org>> wrote:

> On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze 
> mailto:dschu...@adobe.com>> wrote:
>
>> I would like to ask if there are objections to implement the canvas Path 
>> object.
>
> Do we have metrics on how often people already have things named Path? All 
> other canvas objects have a prefix like CanvasGradient and CanvasPattern, 
> this thing seems inconsistent and more likely to break existing pages.

Dirk, given the fact that you quite logically referred to this as “the canvas 
Path object” when mentioning it to us, and the fact that both CanvasGradient 
and CanvasPattern objects exist, CanvasPath sure does seem like a nice name for 
this. Someone should make that suggestion on the WebApps mailing list!
I am interested in the feature, not the name. I am fine with naming it 
CanvasPath. Remember that Path is not limited to Canvas, other then for 
instance SVGPathElement. I just want to avoid that people come to the 
impression that this can just be used for Canvas.




A difference though is that the path object doesn't have to be associated with 
a canvas. It is/will be useful with other features such as SVG as well.
I feel uneasy with the generic name too; maybe a DOM/HTML/JS prefix is better.

DOM and HTML will lead to the same wrong conclusions IMO. And JS seems unusual 
as prefix.

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

Re: [webkit-dev] New Feature: Canvas Path object

[Dirk Schulze]

This mailing list seems to be wrong for this kind of discussion. You opened a 
thread on whatgwg mailing list. Your concerns should be discussed there.

Greetings,
Dirk

Sent from my iPhone

On Sep 24, 2012, at 3:15 PM, "Elliott Sprehn" 
mailto:espr...@chromium.org>> wrote:


On Mon, Sep 24, 2012 at 3:56 PM, Eric Seidel 
mailto:e...@webkit.org>> wrote:
My understanding is that a name collision would only affect the
ability of existing software to use the new Path.  It would not break
existing software.  window.Path would just be aliased by the page, no?


Nope, if someone had  previously and accessed it as just 
"Path", we'll break their page because now Path is this canvas object, not the 
HTMLInputElement.

Intuitively I feel like using the ID of "Path" can't be that uncommon, and 
accessing ids like this was fairly common in a number of apps and code 
generators I've worked on...

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

Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?

[Dirk Schulze]

On Monday, October 1, 2012, Gyuyoung Kim wrote:

> Hello WebKit folks,
>
> There were build warning related to unused parameter nowadays. I think
> there are three solutions. One is to remove parameter,
> another is to use UNUSED_PARAM macro and the other is to use /* */ in
> parameters.
>
> I like to use UNUSED_PARAM macro except for primitive parameters
> personally, for example
>
> void foo(RenderObject* object, int /*width*/, int /*height*/) {
> UNUSED_PARAM(object);
> }
>
> I'd like to know what webkittens think about this.
>
>>
>> If it is crystal clear what the parameters stand for, omit them. If not,
you find them commented out. UNUSED_PARAM is used when just some platforms
of flagged features use parameters, others not.

Dirk


> Cheers,
> Gyuyoung
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] CSS and CORS

[Dirk Schulze]

Hi WebKit folks,

I have a question to origin restriction and CSS. First the context:

CSS Masking[1] aims to combine the two different 'mask' property 
implementations from WebKit and Firefox. To make it short, 'mask' takes an URL 
and this can either be a reference to an image, or to an  element:



…



img {
mask: url(#mask); /* references an SVG Mask element for masking 
operation (Firefox), OR */
-webkit-mask: url(test.png); /" takes a reference to an image and 
operates the masking with the image (WebKit) */



CSS Masking tries to make both possible in the future.

The problem is, that a  can be in an external SVG file and be referenced 
by SVG fragments: url(http://external.com/mask.svg#mask). It would still not be 
sure it the fragment points to a graphical element like a  (then the SVG 
file would be interpreted as image) or if it references a  element, in 
which case it will be an external resource. You need to download the file and 
parse it to know that.

Does it matter to know if it is an external resource or image before 
downloading?

A  element can have events, which run JavaScript: . Running the  element will fire 
the event, which is maybe a violation against CORS, since the SVG file can come 
from a different origin.

For images, we don't care about the origin, don't run scripts and don't fire 
events.

My question is if we have already an CSS property, widely implemented in 
WebKit, where CORS matters? When do we decide not to go on with the 
interpretation of a resource because of violation of CORS? Before we even 
download the resource? After we may already parsed it?

Firefox does care about that before parsing and does not load the entire SVG 
file if it is from a different origin. Since Firefox does not support image 
references for 'mask', they always assume that the reference is an external 
reference and not an image.

Opera does not care about the origin, but scripts are not executed and events 
don't fire.

Greetings,
Dirk

[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property

PS: WebKit has support for 'mask' property with referencing of  elements. 
Currently, external files are not supported. The mask element must be in the 
same document.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CSS and CORS

[Dirk Schulze]

On Oct 26, 2012, at 9:04 PM, Adam Barth  wrote:

> On Fri, Oct 26, 2012 at 9:08 AM, Dirk Schulze  wrote:
>> Hi WebKit folks,
>> 
>> I have a question to origin restriction and CSS. First the context:
>> 
>> CSS Masking[1] aims to combine the two different 'mask' property 
>> implementations from WebKit and Firefox. To make it short, 'mask' takes an 
>> URL and this can either be a reference to an image, or to an  element:
>> 
>> 
>>
>>…
>>
>> 
>> 
>> img {
>>mask: url(#mask); /* references an SVG Mask element for masking 
>> operation (Firefox), OR */
>>-webkit-mask: url(test.png); /" takes a reference to an image and 
>> operates the masking with the image (WebKit) */
>> 
>> 
>> 
>> CSS Masking tries to make both possible in the future.
>> 
>> The problem is, that a  can be in an external SVG file and be 
>> referenced by SVG fragments: url(http://external.com/mask.svg#mask). It 
>> would still not be sure it the fragment points to a graphical element like a 
>>  (then the SVG file would be interpreted as image) or if it references 
>> a  element, in which case it will be an external resource. You need to 
>> download the file and parse it to know that.
>> 
>> Does it matter to know if it is an external resource or image before 
>> downloading?
> 
> Ouch.  That sounds like a bad constraint.  How do you plan to
> implement that?  I guess you'd need to load the SVG as an SVGImage and
> then either extract the path or the bitmap depending if there is an
> element with a given ID?  At what point do you check for the ID?  For
> example, do you want for DOMContentLoaded, or do you wait to see if an
> ID gets added by JavaScript executing in the page?  Can mask.svg
> execute JavaScript?  (Normally we ban the execution of JavaScript
> inside SVGImage.)
We could load the external file as a document (similar to iframe), check for 
the header first, if it is an SVG document we check the element if it is a mask 
or not. That was at least my naive idea. :)

> 
>> A  element can have events, which run JavaScript: > onload="console.log('CORS? Of course!')">. Running the  element will 
>> fire the event, which is maybe a violation against CORS, since the SVG file 
>> can come from a different origin.
> 
> I see!  If the  element can execute JavaScript, then we cannot
> load the resource in an SVGImage because we forbid JavaScript
> execution in an SVGImage.  Where do you plan to load mask.svg?
Yes. But I just learned that Gecko never executes scripts on external 
resources. External references don't have a browser context in Gecko and 
therefore don't run JavaScript. Opera does support scripts if it is from the 
same origin. However, this is unspecified in SVG and I am working towards 
finding a common and secure solution. The approach from Gecko seems to be sane.

> 
>> For images, we don't care about the origin, don't run scripts and don't fire 
>> events.
> 
> Correct.
> 
>> My question is if we have already an CSS property, widely implemented in 
>> WebKit, where CORS matters?
> 
> CORS is supposed to matter for @font-face.  I'm not sure whether it
> does in our current implementation.  In any case, it's easy to add
> CORS support for a load.  You can look at how the crossorigin
> attribute for  works.
> 
>> When do we decide not to go on with the interpretation of a resource because 
>> of violation of CORS? Before we even download the resource? After we may 
>> already parsed it?
> 
> The CORS go/no-go decision happens when we receive the response
> headers, before we start parsing the resource.
> 
>> Firefox does care about that before parsing and does not load the entire SVG 
>> file if it is from a different origin. Since Firefox does not support image 
>> references for 'mask', they always assume that the reference is an external 
>> reference and not an image.
> 
> That seems vastly more sane.  Supporting both images and 
> elements with the same syntax seems very difficult, if not impossible
> given the constraints that we need to execute JavaScript for the
>  case.
Yes, the scripting part is a bit odd. I think following Gecko and don't allow 
scripting on any external document seems sane.

> 
>> Opera does not care about the origin, but scripts are not executed and 
>> events don't fire.
> 
> Can we do that?  Note: You still need to sorry about CORS because this
> API lets you query for whether a document contains an element of a
> given ID

Re: [webkit-dev] Adding blending mode to WebKit canvas

[Dirk Schulze]

On Nov 9, 2012, at 4:39 PM, Rik Cabanier  wrote:

> Hi,
> 
> I'd like to add support for blending modes to Canvas.
> The spec for this feature can be found here: 
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending
> 
> The implementation will be tracked by a meta bug: 
> https://bugs.webkit.org/show_bug.cgi?id=100069
> I also attached a large patch that shows how this feature can be implemented.

Looking at your patches on bug 100069 and bug 101804, I actually have some 
questions. If I understand your API changes correctly, the 
'globalCompositeOperation' property gets more keywords. The new keywords will 
be the same as for the 'blend-mode' property of the CSS Compositing spec. Does 
it mean that blend mode always will use the compositing operator 'source-over'?

The example implementation of GraphicsContext::setPlatformCompositeOperation on 
CG indicates that it would be possible to combine blend modes with different 
compositing operators in CG already. If you set both with the same property 
'globalCompositeOperation', it won't be possible to mix them in the future. If 
more implementations are capable to support mixing alpha compositing and 
blending, the property can not be changed anymore. 

Wouldn't it be better to add a new property to canvas for blending? At the 
beginning, implementations are just require to use different blend modes in 
combination with 'source-over'. Btw. why is this addition in CSS Compositing 
and not in the Canvas spec?

Greetings,
Dirk


> 
> Please let me know of any concerns.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Adding blending mode to WebKit canvas

[Dirk Schulze]

On Sunday, November 11, 2012, Rik Cabanier wrote:

>
>
> On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak 
> 
> > wrote:
>
>>
>> On Nov 11, 2012, at 6:59 PM, Rik Cabanier 
>> >
>> wrote:
>>
>>
>>
>>
>>>
>>> Wouldn't it be better to add a new property to canvas for blending? At
>>> the beginning, implementations are just require to use different blend
>>> modes in combination with 'source-over'.
>>
>>
>> That could work too.
>> There was a mailing list conversation about this a couple of months ago,
>> and people were evenly split on the subject.
>>
>> The vast majority of cases will use 'source-over' in combination with
>> blending so maybe it's best to keep it simple...
>>
>>
>> It doesn't make sense to me for blend mode and composite operator to be
>> separate in CSS, but combined in Canvas. Either there are valid use cases
>> for specifying them separately or there are not. I cannot imagine how this
>> could differ between Canvas and CSS.
>>
>
To be fair, the 'globalCompositOperator' property mixed the compositing
modes with some blend modes already. Which is the fault of the WebKit
implementation. IIRC they have been removed from the Canvas part of the
HTML spec for some time, but were added later again. Now we have multiple
independent implementations that support all currently specified operators.

Greetings,
Dirk


>
>> There are cases where it makes sense to have them as separate properties.
> To be honest, the main reason that the Canvas proposal combines them, is
> because it is not possible to implement this efficiently using Core
> Graphics.
>
> If we break it up in 2 operations, we have to document the correct
> behavior (= blending does not force source-over for blending) because the
> spec can't be changed later.
> This means that Safari and Firefox for Mac can only implement part of the
> spec...
>
> I prefer to have a consistent implementation that can be extended later as
> opposed to a 'correct' API that is inconsistently implemented.
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding blending mode to WebKit canvas

[Dirk Schulze]

On Nov 11, 2012, at 10:09 PM, "Rik Cabanier" 
mailto:caban...@gmail.com>> wrote:



On Sun, Nov 11, 2012 at 9:52 PM, Dirk Schulze 
mailto:k...@webkit.org>> wrote:


On Sunday, November 11, 2012, Rik Cabanier wrote:


On Sun, Nov 11, 2012 at 8:43 PM, Maciej Stachowiak  wrote:

On Nov 11, 2012, at 6:59 PM, Rik Cabanier  wrote:




Wouldn't it be better to add a new property to canvas for blending? At the 
beginning, implementations are just require to use different blend modes in 
combination with 'source-over'.

That could work too.
There was a mailing list conversation about this a couple of months ago, and 
people were evenly split on the subject.

The vast majority of cases will use 'source-over' in combination with blending 
so maybe it's best to keep it simple...

It doesn't make sense to me for blend mode and composite operator to be 
separate in CSS, but combined in Canvas. Either there are valid use cases for 
specifying them separately or there are not. I cannot imagine how this could 
differ between Canvas and CSS.

To be fair, the 'globalCompositOperator' property mixed the compositing modes 
with some blend modes already. Which is the fault of the WebKit implementation. 
IIRC they have been removed from the Canvas part of the HTML spec for some 
time, but were added later again. Now we have multiple independent 
implementations that support all currently specified operators.

Is this the 'darker' compositing mode or are there others?

Lighter and darker, yes.

Greetings
Dirk

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

Re: [webkit-dev] WebKit + OpenCL

[Dirk Schulze]

On Nov 23, 2012, at 2:43 PM, Andreas Kling  wrote:

> Hi folks,
> 
> Do we really think it's a good idea to add yet another implementation of 
> filters?
> 
> We already have generic, NEON-optimized and WTF::ParallelJobs (which includes 
> generic, OpenMP and libdispatch backends) implementations of this code, and 
> now we're adding OpenCL too.
> 
> On the WebKit Project Goals page , 
> it states that:
> 
> "WebKit is an engineering project not a science project. For new features to 
> be adopted into WebKit, we strongly prefer for the technology or at least the 
> use case for it to be proven."
> 
> Correct me if I'm wrong, but we don't see much use of these features on the 
> web. I understand that there's a bit of a chicken/egg problem where a feature 
> won't be interesting to content creators until it performs well enough, but 
> it seems like we could at least decide on a single path forward instead of 
> repeatedly forking the code.

I designed the current SVG Filters implementation in a way that hopefully make 
it possible to implement HW accelerated filters on top of it. Skia and NEON 
already go this path. I am not defending the OpenCL implementation for SVG 
Filters per se, but different platform dependent solutions were expected and 
wanted. Software filters were designed to be a fallback if an implementation 
does not provide HW acceleration (yet). I hope that we see a Core Image version 
of filters in the near future as well. The code for that is in the history of 
the repository already.

Greetings,
Dirk

> 
> -Kling
> 
> On Nov 21, 2012, at 7:30 PM, Zoltan Herczeg  wrote:
> 
>> Hi,
>> 
>> we start upstreaming some OpenCL optimizations into WebKit.
>> 
>> This is the master bug:
>> https://bugs.webkit.org/show_bug.cgi?id=70099
>> 
>> Regards,
>> Zoltan
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 4:51 AM, Alexis Menard  wrote:

> Hi everyone,
> 
> I wanted to let you know that I have added the new CSS3
> background-position offsets support to WebKit.
> 
> This support is behind the ENABLE_CSS3_BACKGROUND feature define and
> it's disabled by default on all ports. I took the conservative
> approach despite it's a cool feature.
> 
> Long story short, it allows you to specify three or four values to
> background-position. It's a nice addition as you can now position the
> images using length or values in relation to any of the four corners
> of elements, not just the top left corner.
> 
> Opera, IE10 and Firefox implements this feature already (though the
> latter returns weird results using getComputedStyle).
> 
> It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
> two patches landed (parsing and rendering) are
> http://trac.webkit.org/changeset/135632 and
> http://trac.webkit.org/changeset/136378.
> 
> I believe the  type (3-4 values) could be/or is used in
> other cases so we can reuse the parsing code for four/three values if
> needed. I will investigate this afterwards and make appropriate
> patches.

I really hope that we don't use it any where else again (with the exception of 
-webkit-mask-position which should have same behavior as background-position). 
This is the use case for the calc() function. Sadly the calc() function came to 
late for CSS3 Backgrounds.

That said, great work regarding the interoperability with other browsers.

Greetings,
Dirk


> 
> I plan to enable it by default on Qt and EFL ports this week. If
> somebody wants me to enable it on their ports please tell me, I'll be
> happy to do it.
> 
> Looking forward to your comments.
> 
> Spec : http://www.w3.org/TR/css3-background/#the-background-position
> 
> -- 
> Software Engineer @
> Intel Open Source Technology Center
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 5:31 AM, Alexis Menard  wrote:

> On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze  wrote:
>> 
>> On Dec 3, 2012, at 4:51 AM, Alexis Menard  wrote:
>> 
>>> Hi everyone,
>>> 
>>> I wanted to let you know that I have added the new CSS3
>>> background-position offsets support to WebKit.
>>> 
>>> This support is behind the ENABLE_CSS3_BACKGROUND feature define and
>>> it's disabled by default on all ports. I took the conservative
>>> approach despite it's a cool feature.
>>> 
>>> Long story short, it allows you to specify three or four values to
>>> background-position. It's a nice addition as you can now position the
>>> images using length or values in relation to any of the four corners
>>> of elements, not just the top left corner.
>>> 
>>> Opera, IE10 and Firefox implements this feature already (though the
>>> latter returns weird results using getComputedStyle).
>>> 
>>> It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
>>> two patches landed (parsing and rendering) are
>>> http://trac.webkit.org/changeset/135632 and
>>> http://trac.webkit.org/changeset/136378.
>>> 
>>> I believe the  type (3-4 values) could be/or is used in
>>> other cases so we can reuse the parsing code for four/three values if
>>> needed. I will investigate this afterwards and make appropriate
>>> patches.
>> 
>> I really hope that we don't use it any where else again (with the exception 
>> of -webkit-mask-position which should have same behavior as 
>> background-position). This is the use case for the calc() function. Sadly 
>> the calc() function came to late for CSS3 Backgrounds.
> 
> -webkit-mask-position should behave the same way as
> background-position? Even if I add feature to the latter? Why so?

Because -webkit-mask and background share the same properties and syntax. Why 
should it be different on -webkit-mask-position? (Btw. CSS Masking already 
adapted the background-position syntax for mask-position[1])

> 
> it seems like transform-origin supports something similar. I need to look at 
> it.
> 
> http://www.w3.org/TR/css3-transforms/#transform-origin-property

It definitely does not :)

Greetings,
Dirk

[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position

> 
>> 
>> That said, great work regarding the interoperability with other browsers.
>> 
>> Greetings,
>> Dirk
>> 
>> 
>>> 
>>> I plan to enable it by default on Qt and EFL ports this week. If
>>> somebody wants me to enable it on their ports please tell me, I'll be
>>> happy to do it.
>>> 
>>> Looking forward to your comments.
>>> 
>>> Spec : http://www.w3.org/TR/css3-background/#the-background-position
>>> 
>>> --
>>> Software Engineer @
>>> Intel Open Source Technology Center
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> 
> 
> -- 
> Software Engineer @
> Intel Open Source Technology Center
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 6:12 AM, "Alexis Menard"  wrote:

> On Mon, Dec 3, 2012 at 10:42 AM, Dirk Schulze  wrote:
>> 
>> On Dec 3, 2012, at 5:31 AM, Alexis Menard  wrote:
>> 
>>> On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze  wrote:
>>>> 
>>>> On Dec 3, 2012, at 4:51 AM, Alexis Menard  wrote:
>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> I wanted to let you know that I have added the new CSS3
>>>>> background-position offsets support to WebKit.
>>>>> 
>>>>> This support is behind the ENABLE_CSS3_BACKGROUND feature define and
>>>>> it's disabled by default on all ports. I took the conservative
>>>>> approach despite it's a cool feature.
>>>>> 
>>>>> Long story short, it allows you to specify three or four values to
>>>>> background-position. It's a nice addition as you can now position the
>>>>> images using length or values in relation to any of the four corners
>>>>> of elements, not just the top left corner.
>>>>> 
>>>>> Opera, IE10 and Firefox implements this feature already (though the
>>>>> latter returns weird results using getComputedStyle).
>>>>> 
>>>>> It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
>>>>> two patches landed (parsing and rendering) are
>>>>> http://trac.webkit.org/changeset/135632 and
>>>>> http://trac.webkit.org/changeset/136378.
>>>>> 
>>>>> I believe the  type (3-4 values) could be/or is used in
>>>>> other cases so we can reuse the parsing code for four/three values if
>>>>> needed. I will investigate this afterwards and make appropriate
>>>>> patches.
>>>> 
>>>> I really hope that we don't use it any where else again (with the 
>>>> exception of -webkit-mask-position which should have same behavior as 
>>>> background-position). This is the use case for the calc() function. Sadly 
>>>> the calc() function came to late for CSS3 Backgrounds.
>>> 
>>> -webkit-mask-position should behave the same way as
>>> background-position? Even if I add feature to the latter? Why so?
>> 
>> Because -webkit-mask and background share the same properties and syntax. 
>> Why should it be different on -webkit-mask-position? (Btw. CSS Masking 
>> already adapted the background-position syntax for mask-position[1])
> 
> Ok sure. Then I will make -webkit-mask-position to behave the same per
> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position
> . I did know they share the code but I didn't know how far. Thanks for
> pointing it out.
> 
>> 
>>> 
>>> it seems like transform-origin supports something similar. I need to look 
>>> at it.
>>> 
>>> http://www.w3.org/TR/css3-transforms/#transform-origin-property
>> 
>> It definitely does not :)
> 
> Sorry about that I read super quickly and based my thought of one of
> the test of css3test.com which expect "right 10px bottom 20px" and
> https://bugs.webkit.org/show_bug.cgi?id=37514#c8 . I'm not sure what
> is valid or not. Maybe Simon could tell us.

Simon and I discussed it with the CSS WG and we came to the conclusion that we 
should not introduce the background-position syntax somewhere else in favor for 
calc(). -webkit-mask is so similar to background, that people have the 
expectations to behave the same. This is why -webkit-mask-position is an 
exception.

Greetings
Dirk

> 
>> 
>> Greetings,
>> Dirk
>> 
>> [1] 
>> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position
>> 
>>> 
>>>> 
>>>> That said, great work regarding the interoperability with other browsers.
>>>> 
>>>> Greetings,
>>>> Dirk
>>>> 
>>>> 
>>>>> 
>>>>> I plan to enable it by default on Qt and EFL ports this week. If
>>>>> somebody wants me to enable it on their ports please tell me, I'll be
>>>>> happy to do it.
>>>>> 
>>>>> Looking forward to your comments.
>>>>> 
>>>>> Spec : http://www.w3.org/TR/css3-background/#the-background-position
>>>>> 
>>>>> --
>>>>> Software Engineer @
>>>>> Intel Open Source Technology Center
>>>>> ___
>>>>> webkit-dev mailing list
>>>>> webkit-dev@lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>>> 
>>> 
>>> --
>>> Software Engineer @
>>> Intel Open Source Technology Center
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> -- 
> Software Engineer @
> Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 8:43 AM, Simon Fraser  wrote:

> On Dec 3, 2012, at 4:51 AM, Alexis Menard wrote:
> 
>> I plan to enable it by default on Qt and EFL ports this week. If
>> somebody wants me to enable it on their ports please tell me, I'll be
>> happy to do it.
> 
> I think it's preferable to enable for all ports if you think it's ready. In 
> general, features
> should be enabled on trunk for everyone. Ports can turn off features in their
> shipping branches if they so choose.

Why does this feature have a flag at all? background-position with up to 4 
arguments is specified with CSS3 background and borders. There are three major 
implementations with this feature. So we are just catching up. If the future 
works as expected (and we should have tests that verify it), then we should 
remove the flag completely.

Greetings,
Dirk

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

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

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 12:07 PM, Benjamin Poulain  wrote:

> On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze  wrote:
> Why does this feature have a flag at all? background-position with up to 4 
> arguments is specified with CSS3 background and borders. There are three 
> major implementations with this feature. So we are just catching up. If the 
> future works as expected (and we should have tests that verify it), then we 
> should remove the flag completely.
> 
> Sounds like good practice to me.
> 
> Why _not_ start that feature with a flag then remove the flag when fully 
> ready/tested???

Depends on the future. But for such a small patch, a new flag seems to be 
overdone. I looked into the patch, and adding the flag caused more code, then 
the actual feature (even if the computed style is missing). I believe we should 
remove the flag ASAP. Flags are for bigger new features of features that likely 
will change IMO. Both seems not to be the case for background-position.

Greetings,
Dirk

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

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

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 1:15 PM, Benjamin Poulain  wrote:

> On Mon, Dec 3, 2012 at 12:59 PM, Dirk Schulze  wrote:
> Depends on the future. But for such a small patch, a new flag seems to be 
> overdone. I looked into the patch, and adding the flag caused more code, then 
> the actual feature (even if the computed style is missing). I believe we 
> should remove the flag ASAP. Flags are for bigger new features of features 
> that likely will change IMO. Both seems not to be the case for 
> background-position.
> 
> See http://trac.webkit.org/wiki/AddingFeatures
> 

"The policy for adding new (major) features to WebKit is:"

major says everything IMO. background-position is not a major feature.

However, to stay at the topic: Is there anything blocking 'background-position' 
with the new syntax? Any objections to remove the flags? If yes, I would like 
to know more about the problems.

Greetings,
Dirk

> I personally appreciate when authors take the time to have feature flags 
> until the feature is finished. It has many advantages for making releases.
> 
> Benjamin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Dirk Schulze]

On Dec 3, 2012, at 2:54 PM, Alexis Menard  wrote:

> 
> On Dec 3, 2012 6:21 PM, "Dirk Schulze"  wrote:
> >
> >
> > On Dec 3, 2012, at 1:15 PM, Benjamin Poulain  wrote:
> >
> > > On Mon, Dec 3, 2012 at 12:59 PM, Dirk Schulze  wrote:
> > > Depends on the future. But for such a small patch, a new flag seems to be 
> > > overdone. I looked into the patch, and adding the flag caused more code, 
> > > then the actual feature (even if the computed style is missing). I 
> > > believe we should remove the flag ASAP. Flags are for bigger new features 
> > > of features that likely will change IMO. Both seems not to be the case 
> > > for background-position.
> > >
> > > See http://trac.webkit.org/wiki/AddingFeatures
> > >
> >
> > "The policy for adding new (major) features to WebKit is:"
> >
> > major says everything IMO. background-position is not a major feature.
> >
> > However, to stay at the topic: Is there anything blocking 
> > 'background-position' with the new syntax? Any objections to remove the 
> > flags? If yes, I would like to know more about the problems.
> >
> 
> I can still remove the flag when everything is done. Probably tomorrow or so.

I think it is reasonable to do this if no one objects till tomorrow.

Greetings,
Dirk

> 
> > Greetings,
> > Dirk
> >
> > > I personally appreciate when authors take the time to have feature flags 
> > > until the feature is finished. It has many advantages for making releases.
> > >
> > > Benjamin
> > > ___
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > http://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Proposal: Add webkitFillRule to canvas

[Dirk Schulze]

On Jan 4, 2013, at 5:24 PM, Rik Cabanier  wrote:

> 
> 
> On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson  wrote:
> On Fri, 4 Jan 2013, Rik Cabanier wrote:
> >
> > I think this feature was rushed in the spec.
> 
> The specing is usually the first step. You can't rush to spec. :-)
> 
> In this particular case, though, it was the third or fourth step. The
> discussion has been open since June 2011. It's not like people didn't have
> time to comment. It's been shipping in a browser for over a year.
> 
> Any solution we come up with to the issues that were raised regarding Path
> will almost certainly be done in a way that builds on context.fillRule,
> not in a way that removes context.fillRule.
>  
> I was not aware of that discussion.
> There are good reasons to make the fill rule part of the fill operation 
> itself. It does not make sense in the graphic state.
> 
> How about EOClip? That is a construct that is far more used than eofill. Will 
> that get its own parameter too?

It will use the same property, since there is no difference. That is why the 
name could be a bit misleading. windingRule would be a bit more independent of 
the fill operation.

> How about the interaction of stroking and this parameter (if you follow the 
> spec's wording for stroking)?

This needs to change as well to match the new behavior. This is more a 
specification problem and no implementation problem.

> How about ispointinpath? Will that follow the winding rule in the graphic 
> state?

It would depend on the fillRule that you set on the context.

> How about hit regions? How can you specify the winding there?

This is a good point. But it depends if hit region will be implemented as 
specified.

> 
> It's better to follow what almost every other graphics library has done: Add 
> an EOFill and an EOClip.
> I volunteer to add it to Mozilla if it helps.

That is not fully correct. Just Qt and Skia make it explicitly on the Path 
object (which is not necessarily depending on the fill operation itself). CG 
does not bundle EOfill with a path, instead you set it during painting. Which 
is partly as done by the specification, with the exception that it is not part 
of the graphic state, but also not part of the path logic. Cairo graphics has 
the fill rule as part of the graphic state IIRC.

This discussion is a bit misplaced on webkit-dev. Could you continue it on the 
WHAT WG mailing list please?

I would just agree with Rik here, that we should wait a bit more time before 
implementing it in WebKit. Even if following the Firefox implementation and the 
needs of PDF.js is a good reason for implementing as suggested by the spec.

Greetings,
Dirk


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

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

Re: [webkit-dev] Proposal: Add webkitFillRule to canvas

[Dirk Schulze]

On Jan 4, 2013, at 7:28 PM, "Rik Cabanier" 
mailto:caban...@gmail.com>> wrote:



On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze 
mailto:dschu...@adobe.com>> wrote:

On Jan 4, 2013, at 5:24 PM, Rik Cabanier 
mailto:caban...@gmail.com>> wrote:

>
>
> On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson 
> mailto:i...@hixie.ch>> wrote:
> On Fri, 4 Jan 2013, Rik Cabanier wrote:
> >
> > I think this feature was rushed in the spec.
>
> The specing is usually the first step. You can't rush to spec. :-)
>
> In this particular case, though, it was the third or fourth step. The
> discussion has been open since June 2011. It's not like people didn't have
> time to comment. It's been shipping in a browser for over a year.
>
> Any solution we come up with to the issues that were raised regarding Path
> will almost certainly be done in a way that builds on context.fillRule,
> not in a way that removes context.fillRule.
>
> I was not aware of that discussion.
> There are good reasons to make the fill rule part of the fill operation 
> itself. It does not make sense in the graphic state.
>
> How about EOClip? That is a construct that is far more used than eofill. Will 
> that get its own parameter too?

It will use the same property, since there is no difference. That is why the 
name could be a bit misleading. windingRule would be a bit more independent of 
the fill operation.

That is a problem. Now you will have to set the parameter before the clip and 
set it back again right after (since you can't use save/restore since it blows 
away the clip)

I don't see the problem here. That is how canvas works currently. fill() and 
clip() use the currentPath. Seems to be more natural to use the property then.



> How about the interaction of stroking and this parameter (if you follow the 
> spec's wording for stroking)?

This needs to change as well to match the new behavior. This is more a 
specification problem and no implementation problem.

I agree. However, user agents didn't have to really think about this before but 
they will have to in the future. Making it part of the state will make it much 
more difficult to implement cleanly.

Not at all, as demonstrated with the patch.



> How about ispointinpath? Will that follow the winding rule in the graphic 
> state?

It would depend on the fillRule that you set on the context.

> How about hit regions? How can you specify the winding there?

This is a good point. But it depends if hit region will be implemented as 
specified.

>
> It's better to follow what almost every other graphics library has done: Add 
> an EOFill and an EOClip.
> I volunteer to add it to Mozilla if it helps.

That is not fully correct. Just Qt and Skia make it explicitly on the Path 
object (which is not necessarily depending on the fill operation itself). CG 
does not bundle EOfill with a path, instead you set it during painting. Which 
is partly as done by the specification, with the exception that it is not part 
of the graphic state, but also not part of the path logic.

Core graphics has indeed no support for paths (just like the current canvas 
implementations)
However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the 
current path which is what I propose we should do.

No, because the path is already applied to the context. That makes the property 
so natural and easy to implement.


Cairo graphics has the fill rule as part of the graphic state IIRC.

This discussion is a bit misplaced on webkit-dev. Could you continue it on the 
WHAT WG mailing list please?

I agree. However, if people didn't follow that mailing list, they would think 
that everything is sorted out since Ian emailed this list to say that it is in 
the spec .

Right.



I would just agree with Rik here, that we should wait a bit more time before 
implementing it in WebKit. Even if following the Firefox implementation and the 
needs of PDF.js is a good reason for implementing as suggested by the spec.

If it's for PDF, then a graphic state variable is not the way to go since PDF 
does not have this either.

PDF.js - the JavaScript library. Not PDF the standard. And the library uses it 
already according to previous posts.

Greetings,
Dirk



Greetings,
Dirk


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


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

Re: [webkit-dev] Keeping up with new additions to canvas

[Dirk Schulze]

On Jan 7, 2013, at 4:18 AM, RGraph.net support  wrote:

> Hi,
> 
> Is watching this mailing list the best way to keep up-to-date with new
> additions to the WebKit canvas implementation (such as the canvas Path
> object or hit regions)? Or perhaps there's an  announcements list too?

Bigger new features like Path or hit region proposals need to get pronounced on 
this list. Smaller improvements (bug fixes) are not necessarily announced. 
There is no separate list beside webkit-changes for all changes to WebKit.

Greetings,
Dirk

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

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

Re: [webkit-dev] Keeping up with new additions to canvas

[Dirk Schulze]

On Jan 8, 2013, at 11:37 AM, Dean Jackson  wrote:

> As well as the other suggestions, you can look at bugs in the Canvas 
> component. e.g.
> 
> https://bugs.webkit.org/show_bug.cgi?id=82790

Marked as duplicate ;)

Dirk

> 
> We should probably have a owner bug to collect all the HTML5-ish Canvas 
> changes.


> 
> Dean
> 
> On 07/01/2013, at 11:18 PM, RGraph.net support  
> wrote:
> 
>> Hi,
>> 
>> Is watching this mailing list the best way to keep up-to-date with new
>> additions to the WebKit canvas implementation (such as the canvas Path
>> object or hit regions)? Or perhaps there's an  announcements list too?
>> 
>> Thanks!
>> 
>> -- 
>> Richard
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Dirk Schulze]

On Jan 8, 2013, at 2:57 PM, Sam Weinig  wrote:

> Hello webkit-dev,
> 
> We are making some changes to the development process for WebKit2. These 
> changes were announced to reviewers in advance, and I'd like to share them 
> with you now.
> 
> WebKit2 has a core set of functionality that is valuable to all ports, and 
> then aspects that are only of limited/specialized interest. It is becoming 
> increasingly difficult to improve and advance the core functionality while 
> maintaining the more peripheral aspects. In addition, changes to the core 
> often require significant expertise to evaluate, for instance to ensure that 
> the security and responsiveness goals of WebKit2 are met.
> 
> The changes are:
> 
> 1) WebKit2 now has owners. Only owners should review WebKit2 patches. While 
> we do not want to apply this concept across the whole WebKit project at this 
> time, for WebKit2 it is appropriate. The list of owners is documented in the 
> Owners file at the WebKit2 top level directory, and in committers.py.  
> 
> 2) Ports must keep themselves building. Non Apple Mac ports, if broken by 
> core functionality changes to WebKit2, are now responsible for fixing 
> themselves. We have asked those who run the EWS bots to make sure that 
> failing to build WebKit2 does not block the commit queue from committing.

I didn't see a settlement on this point of the proposal on previous 
discussions. Did you elaborate on the feedback that you got when you asked for 
that the first time? I think it is a question of fair play to not leave core 
build bots of other platforms broken. That is what we agreed on WebKit and I 
don't see the reason why it should be different on WebKit2 (which is a part of 
WebKit). That doesn't mean that the other suggestions aren't reasonable.

Greetings,
Dirk

> 
> 3) Over time, owners may remove peripheral functionality from the main 
> WebKit2 directory, such as support for features that aren't broadly 
> applicable. We will not do this immediately, and we will work with ports that 
> are interested in such features to create appropriate, maintainable 
> general-purpose mechanisms that can be used to implement them outside of core 
> WebKit2 code.
> 
> While we understand that this change will inconvenience some ports, we have 
> decided that forward progress of WebKit2 is a more important concern, and we 
> are moving forward with this change tonight.
> 
> - Sam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Int/FloatPoint and Int/FloatSize

[Dirk Schulze]

On Jan 9, 2013, at 5:40 PM, Simon Fraser  wrote:

> On Jan 9, 2013, at 4:52 PM, Steve Block  wrote:
> 
>>> I'm really not sure that this set of changes is going in the right 
>>> direction. What's driving them; some abstract sense of purity, or
>>> reducing the chances of introducing real bugs that we've seen in the past?
>> Some of both. I was investigating a bug where WebCore is generating
>> unexpected negative sizes. While looking into how this could happen, I
>> noticed that in some cases, negative sizes result from size types
>> being used to represent things that seem more like points. It seems
>> like it would be good to clean this up this misuse of size types, and
>> perhaps in the long term, we can avoid negative sizes altogether,
>> which would help avoid these kinds of bug in the future.
> 
> It seems like a lot of churn for relatively little gain. I'd rather our time 
> be focused
> on areas that actually benefit users of WebKit.

I agree with this concern. Another object for representing 2D vector data will 
cause more maintenance cost now and in the future. And I doubt that it gives a 
big enough benefit over defining when to use Point and Size today.

Greetings,
Dirk

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

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

Re: [webkit-dev] SVG external referencing not working as of latest chrome canary

[Dirk Schulze]

Hi Steve,

Thank you for your interest on WebKit. Of course we would like to fix as many 
bugs as possible in a time frame as short as possible. With limited resources, 
this does not work very well for some bugs. So we need to prioritize our work. 
Even if external resources might be a priority for you, it doesn't need to be 
for others. We currently focus on performance and security. And external 
references in SVG have their security issues on their own (why we are very 
careful on implementing them).

After all, WebKit is an open source project. Even if you already contributed by 
reporting bugs (thank you for that), you are very welcome to commit patches. I 
see that you may have limited time, as we do as well. A lot of people on this 
project still contribute in their spare time, even if they are employed to work 
on WebKit. Please join us to make webkit better. I am happy to review your SVG 
patches.

Greetings,
Dirk

On Jan 14, 2013, at 12:52 AM, "Steve Williams" 
mailto:stephen.j.h.willi...@googlemail.com>>
 wrote:

Hi Maciej,

1.  It's been on your bug database for ages hence filing another entry won't 
move anything forwards.
2. svg 1.1 spec seems a little over the top in places so not personally 
interested in full support - just the good stuff.
3. Have provided you with a minimal test case in the previous post.
4. "Cite real-world sites using the functionality to the relevant bugs."

? chicken and egg. that's not how we make progress ! I'll use it in our 
site when it works but can't until it does.
For now I have to iframe as a workaround but that sucks because iframes grab 
the entire rect for mouse input which means you can't subtly blend svg over 
html.

5. Like you, I am busy. I don't have time to fix this (really). Sorry,  
appreciate you don't like that but it is what it is.

6. Would be great if this could be advanced in priority to enable us to raise 
the bar, cross browser.

Am sure you won't appreciate this fired back at the mailing list & I realise 
I'm risking a ban when you've asked me not to do this, but I'm a bit of a rebel 
:)

Thanks for all your hard work.

FF has svg bugs too - different (lower priority niggles). Will go hassle them 
next. IE9 a bit wobbly too, but well ... :)

If basic support can be solidified cross browser, we have an interesting 
platform over & above html5.

Best regards,
Steve.

On 13/01/2013 21:37, Maciej Stachowiak wrote:

Hi Steve,

If you're interested in more complete SVG support, here are some things you can 
do:

(1) File bugs for any missing features that don't have bugs already.
(2) Create a meta-bug for "complete SVG 1.1 support" or what have you that's 
blocked by all the relevant feature bugs.
(3) Add useful reduced test cases to the relevant bugs.
(4) Cite real-world sites using the functionality to the relevant bugs.
(5) Work on implementing some of these features yourself.
(6) Persuade WebKit hackers that you know (offlist) to work on some of these 
features.
(7) Contact one of the vendors that works on WebKit via their developer 
relations channels and ask them to implement the features you care about.

If you are interested in more complete SVG support, I encourage you to do some 
or all of these things.

Note, however, that posting feature requests or advocacy for specific bugs is 
not really appropriate for this list. It's for talking about the development of 
WebKit itself, and no one uses requests on this list as a way to drive 
priorities.

I'm glad to see you are interested in WebKit's SVG support and I hope you will 
consider some of the possible steps above to improve it.

Cheers,
Maciej

On Jan 13, 2013, at 8:37 AM, Steve Williams 
mailto:stephen.j.h.willi...@googlemail.com>>
 wrote:

Hi all,


   I've done a little experimenting to see where we're at wrt to svg feature 
set and it seems webkit is lagging some way behind gecko.

Of particular concern is lack of external referencing capability through the 
svg use tag.

I attach a simple example that works in firefox for your consideration.

root.svg should link through to object.svg and render it.

It doesn't in latest chrome canary. You've had a bug filed on this for a long 
time but it's still unresolved so thought I'd mail.

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


"We are lowering the priority because this is not heavily used."

The feature is not used heavily because it doesn't work properly.


Never use lack of use as a reason to not do something :)

SVG is important because it's the lowest common denominator high spec graphics 
interface across all major browsers. Looks like you're behind ie9 in terms of 
implementation. You should at least match their implementation so we can raise 
the bar. Of course IE should implement webgl but until they do SVG is the best 
we've got across all mainstream browsers.

Thanks in advance for your consideration.

webkit is behind the curve in implementation of this web standard - please 
address this.

Best regards,
Steve Wil

Re: [webkit-dev] Is the New XMLParser dead?

[Dirk Schulze]

On Jan 18, 2013, at 6:19 AM, Steve Williams 
 wrote:

> No idea what this is about as I haven't studied your tree yet but here's 
> a couple of XML enhancements I'd like to see accepted by the mainstream 
> (including the webkit parser)
> 
> 1. default element close.
> 
> syntax:  
>[stuff]
>
> 
> currently you have to do :
> 
> 
>[stuff]
> 
> 
> which is overly verbose.
> 
> 
> 2. drop the requirement for quotes on attributes where the value doesn't 
> contain whitespace.
> 
> So   
> 
> rather than the bloaty  
> 
> Yeah I know those aren't in the current XML spec. Just sayin'.

The purpose of an XML parser is parse XML files according to the specification 
of XML. If you don't like the rules of XML, discuss it on the responsible W3C 
mailing lists. Your examples are not valid according to XML 1.0.

Greetings,
Dirk

> 
> - Steve
> 
> On 18/01/2013 00:15, Adam Barth wrote:
>> Maciej has asked that we keep it around until the end of February:
>> 
>> https://bugs.webkit.org/show_bug.cgi?id=100710
>> 
>> Adam
>> 
>> 
>> On Thu, Jan 17, 2013 at 4:10 PM, Ryosuke Niwa  wrote:
>>> Hi,
>>> 
>>> It has been 11 months since Eric initially raised the concern. Can we go
>>> ahead and remove the parser now?
>>> 
>>> - R. Niwa
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Dirk Schulze]

This is a followup to the multiple inheritance discussion.

Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not have 
multiple inheritances of interfaces that are exposed to bindings. But SVG2 
still uses the "implements" statement for "[NoInterfaceObject]" interfaces [2]. 
This should at least address your initial concern not to inherit from different 
interfaces exposed to bindings.

However, during a discussion on IRC I got the impression that we do not plan to 
support the "implements" statement because it can do "weird" things. If this is 
right, I would like to understand why this is the case? Have the concerns been 
submitted to the editor and the WG working on the WebIDL specification?

More and more specifications describe interfaces by using WebIDL, including 
HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general 
concerns on WebIDL, they should be addressed on the spec before leaving CR 
state. Not implementing WebIDL could not only block this specification in 
particular, but also all other specs relying on it. Or maybe worst, it gets a 
recommendation and we do not follow web standards anymore. It would be great to 
hear a clarification. Maybe it is just a misunderstanding on my site.

Greetings,
Dirk

[1] 
https://svgwg.org/svg2-draft/single-page.html#types-InterfaceSVGGraphicsElement
[2] http://www.w3.org/TR/WebIDL/#NoInterfaceObject


On Jul 25, 2012, at 9:13 PM, Dirk Schulze  wrote:

> 
> On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
> 
>> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
>>> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>>> interfaces.  However, the situation there is a bit different.
>>>> Although SVGSVGElement implements SVGLocatable, there aren't any
>>>> interfaces with methods that return SVGLocatable, which means we don't
>>>> need to implement toJS(SVGLocatable*).
>>> 
>>> SVG 2 will use WebIDL. Therefore we also reorganize our inheritance 
>>> behavior. Cameron, editor of WebIDL and SVG WG member, will update SVG 2 ED 
>>> soon.
>> 
>> Do you anticipate adding properties or functions that return
>> interfaces like SVGLocatable?
> Here is a Wiki what we plan to do: 
> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/IDL_interface_reorganization
> 
> It might not reflect all changes that we discussed during the SVG WG meeting 
> today.
> 
> Greetings,
> Dirk
> 
>> 
>> Adam
>> 
>> 
>>>> He also points out that Node inherits from EventTarget, which already
>>>> contains a virtual interfaceName() function similar to that used by
>>>> Event.  That pushes us further towards using a common DOMInterface
>>>> base class because introducing Region::interfaceName would mean that
>>>> Element would see both EventTarget::interfaceName and
>>>> Region::interfaceName.
>>>> 
>>>> Adam
>>>> 
>>>> 
>>>> On Wed, Jul 25, 2012 at 2:00 PM, Adam Barth  wrote:
>>>>> The CSS Regions specification [1] defines a CSSOM interface named
>>>>> Region, which can be mixed into interfaces for other objets that can
>>>>> be CSS regions.  That means that Region introduces a form of multiple
>>>>> inheritance into the DOM.  For example, Element implements Region but
>>>>> Node does not implement Region.
>>>>> 
>>>>> There's a patch up for review that implements Region using C++
>>>>> multiple inheritance [2]:
>>>>> 
>>>>> - class Element : public ContainerNode {
>>>>> + class Element : public ContainerNode, public CSSRegion {
>>>>> 
>>>>> One difficulty in implementing this feature how to determine the
>>>>> correct JavaScript wrapper return for a given Region object.
>>>>> Specifically, toJS(Region*) needs to return a JavaScript wrapper for
>>>>> an Element if the Region pointer actually points to an Element
>>>>> instance.
>>>>> 
>>>>> We've faced a similar problem elsewhere in the DOM when implementing
>>>>> normal single inheritance.  For example, there are many subclass of
>>>>> Event and toJS(Event*) needs to return a wrapper for the appropriate
>>>>> subtype.  To solve the same problem, CSSRule has a m_type member
>>>>> variable and a bevy of isFoo() functions [3].
>>>>> 
>>>>> A) Should we push back on the folks writing the CSS

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Dirk Schulze]

On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:

> On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  wrote:
>> This is a followup to the multiple inheritance discussion.
>> 
>> Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
>> have multiple inheritances of interfaces that are exposed to bindings. But 
>> SVG2 still uses the "implements" statement for "[NoInterfaceObject]" 
>> interfaces [2]. This should at least address your initial concern not to 
>> inherit from different interfaces exposed to bindings.
>> 
>> However, during a discussion on IRC I got the impression that we do not plan 
>> to support the "implements" statement because it can do "weird" things. If 
>> this is right, I would like to understand why this is the case?
> 
> We don't intend to support all the possible things that you can do
> with "implements."  With "implements", you can define arbitrarily
> complicated relationships between interfaces, including some that can
> be implemented only with a QueryInterface-like mechanism.  We're not
> going to implement QueryInterface, so we're not going to implement any
> specifications that require it.

This sounds that you consider having "implements" in our WebIDL interpreter, or 
at least would not block adding this per se. This was my concern in the first 
place, since this is already in use in a lot of specifications (just with 
[NoInterfaceObject] as far as I saw).

> 
>> Have the concerns been submitted to the editor and the WG working on the 
>> WebIDL specification?
> 
> I haven't submitted my concerns.  There's nothing particularly wrong
> with the WebIDL language, just like there's nothing particularly wrong
> with English just because you can use it to write a terrible poem.

Well, it seems to be a bit different. Your poem would still be valid as long as 
it follows the grammar and can still be read, even if it does not make sense to 
you. You suggest not supporting everything from WebIDL, which means not 
accepting the full specified grammar. I think this is a concern where you would 
like to see limitations to the current grammar and which should be discussed.

> 
>> More and more specifications describe interfaces by using WebIDL, including 
>> HTML5, Canvas, SVG2, Filter Effects and CSS Masking. If there are general 
>> concerns on WebIDL, they should be addressed on the spec before leaving CR 
>> state.
> 
> I don't have any concerns with the WebIDL language.  The WebIDL
> language is just a mechanism for writing precise specifications.
> 
>> Not implementing WebIDL could not only block this specification in 
>> particular, but also all other specs relying on it.
> 
> That's nonsense.  Just because we don't implement some crazy corner
> case of WebIDL that doesn't mean that we're unable to implement *all*
> specs that reply upon it.  For example, HTML and DOM use WebIDL and
> we're able to implement them just fine.

You suggest not implementing some corner cases. And as you say, we won't be 
able to support specifications relying on these corner cases. It rather seems 
you agree with my statement, even if it does not block former named 
specifications yet. I am not questioning your arguments to not support all 
corner cases of WebIDL. I am asking for an open discussion about particular 
cases on the relevant mailing lists (public-webapps for WebIDL) to address 
these concerns in the specification before leaving CR.

> 
>> Or maybe worst, it gets a recommendation and we do not follow web standards 
>> anymore. It would be great to hear a clarification. Maybe it is just a 
>> misunderstanding on my site.
> 
> There's no experiment that you can run using web content to detect
> whether we implement WebIDL.  All you can detect is whether we
> implement particular specifications that use WebIDL.  We can just
> simply not implement the specifications that require COM-like
> implementations and we can continue to lead a happy life.

This seems indeed a problem for WebIDL, since tests and testability is a 
requirement to leave CR. However, the WebApps WG might have a different thought.

Greetings,
Dirk

> 
> Adam
> 
> 
>> On Jul 25, 2012, at 9:13 PM, Dirk Schulze  wrote:
>>> On Jul 25, 2012, at 3:50 PM, Adam Barth wrote:
>>>> On Wed, Jul 25, 2012 at 3:44 PM, Dirk Schulze  wrote:
>>>>> On Jul 25, 2012, at 2:33 PM, Adam Barth wrote:
>>>>>> Eric Seidel points out that SVG uses multiple inheritance in its DOM
>>>>>> interfaces.  However, the situation there is a bit different.
>>>>>> Although SVGSVGE

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Dirk Schulze]

On Jan 25, 2013, at 4:23 PM, Maciej Stachowiak  wrote:

> 
> On Jan 25, 2013, at 4:13 PM, Adam Barth  wrote:
> 
>> On Fri, Jan 25, 2013 at 2:08 PM, Dirk Schulze  wrote:
>>> On Jan 25, 2013, at 9:14 AM, Adam Barth  wrote:
>>>> On Fri, Jan 25, 2013 at 8:11 AM, Dirk Schulze  wrote:
>>>>> This is a followup to the multiple inheritance discussion.
>>>>> 
>>>>> Adam, I checked the IDL files on SVG2 [1]. The interfaces for SVG2 do not 
>>>>> have multiple inheritances of interfaces that are exposed to bindings. 
>>>>> But SVG2 still uses the "implements" statement for "[NoInterfaceObject]" 
>>>>> interfaces [2]. This should at least address your initial concern not to 
>>>>> inherit from different interfaces exposed to bindings.
>>>>> 
>>>>> However, during a discussion on IRC I got the impression that we do not 
>>>>> plan to support the "implements" statement because it can do "weird" 
>>>>> things. If this is right, I would like to understand why this is the case?
>>>> 
>>>> We don't intend to support all the possible things that you can do
>>>> with "implements."  With "implements", you can define arbitrarily
>>>> complicated relationships between interfaces, including some that can
>>>> be implemented only with a QueryInterface-like mechanism.  We're not
>>>> going to implement QueryInterface, so we're not going to implement any
>>>> specifications that require it.
>>> 
>>> This sounds that you consider having "implements" in our WebIDL 
>>> interpreter, or at least would not block adding this per se. This was my 
>>> concern in the first place, since this is already in use in a lot of 
>>> specifications (just with [NoInterfaceObject] as far as I saw).
>> 
>> WebKit doesn't have an WebIDL interpretor.  We have a WebKitIDL
>> compiler.  If you spec something that requires a QueryInterface-like
>> mechanism in the implementation, we will not implement it regardless
>> of what language you write the specification in.  It's a conscious
>> design decision not to implement a COM-like (or XPCOM-like) system.
> 
> Setting aside the more general question, does the SVG2 set of interfaces 
> effectively require a QueryInterface-like mechanism? What limitations, if 
> any, on the use of "implements" would a spec have to follow to dodge this 
> bullet? SVG2 is still evolving, so I suspect it could adjust its use of 
> "implements" if it's an issue for us.

SVG2 does not require any inter process communication. The QueryInterface was 
an example of Adam what we should not implement. SVG2 uses WebIDL's 
"implements" statement for [NoInterfaceObject] interfaces, as the HTML 
specification is doing it. But SVG uses multiple "implements" statements per 
interface:

interface SVGViewSpec
 {
  readonly attribute SVGTransformList transform;
  readonly attribute SVGElement viewTarget;
  readonly attribute DOMString viewBoxString;
  readonly attribute DOMString preserveAspectRatioString;
  readonly attribute DOMString transformString;
  readonly attribute DOMString viewTargetString;
};
SVGViewSpec implements SVGFitToViewBox;
SVGViewSpec implements SVGZoomAndPan;

SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.

I hope that I am not mistaken and that this is not what you mean with 
QueryInterface.

> 
> If SVG2 does happen to avoid the problem, would we want to use "implements" 
> as the syntax in WebKitIDL or would we want a different syntax? I could see 
> arguments either way.

I think it would be desirable to follow WebIDL and the syntax of this 
specifications as long as the goals overlap.

> 
> (FWIW I agree that we don't want to end up in a position where we'd have to 
> implement a QI-like mechanism for the sake of the bindings, but I can't tell 
> from the conversation so far if this is an immediate issue with SVG2, or just 
> a possible issue with other potential uses of "implements").

If I understand Adam correctly, then the later. If there are problems with the 
SVG2 specification, then I am happy to talk with the SVG WG and find solutions. 
But the SVG WG still needs to cover the behavior of SVG 1.1 as much as possible.

Greetings,
Dirk

> 
> Regards,
> Maciej
> 

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

Re: [webkit-dev] WebIDL implementation plans (was: Re: Multiple inheritance in the DOM)

[Dirk Schulze]

On Jan 25, 2013, at 8:16 PM, Elliott Sprehn  wrote:

>> interface SVGViewSpec
>>  {
>>   readonly attribute SVGTransformList transform;
>>   readonly attribute SVGElement viewTarget;
>>   readonly attribute DOMString viewBoxString;
>>   readonly attribute DOMString preserveAspectRatioString;
>>   readonly attribute DOMString transformString;
>>   readonly attribute DOMString viewTargetString;
>> };
>> SVGViewSpec implements SVGFitToViewBox;
>> SVGViewSpec implements SVGZoomAndPan;
>> 
>> SVGFitToViewBox and SVGZoomAndPan are both NoInterfaceObjects.
>> 
>> I hope that I am not mistaken and that this is not what you mean with 
>> QueryInterface.
> 
> 
> Since they're NoInterfaceObjects we can just merge the idl into the file in 
> WebKit or use Supplemental in WebkitIDL. You've written it with multiple 
> implements to be DRY in the WebIDL, that's not a problem for WebKit.
> 
> See: HTMLInputElementFileSystem.

As far as I understood it, HTMLInputElementFileSystem extends HTMLInputElement. 
In WebIDL it would be:

HTMLInputElement implements HTMLInputElementFileSystem;

The problem is that SVGFitToViewBox and SVGZoomAndPan of the example above are 
implemented by a lot of other interfaces as well. Supplemental is just supposed 
to be set once per interface. That is why Supplemental doesn't work for SVG. 
The alternative would be to implement the attributes and operations of 
SVGFitToViewBox and SVGZoomAndPan into every class that implements them. This 
would be a lot of code copies. And these are not the only interfaces that would 
need to be merged.

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

[webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d

[Dirk Schulze]

Hi WebKit folks,

I would like to know if we can remove the following API's in the 
CanvasRenderingContext2d interface:

webkitDashArray
webkitLineDashOffset

Both were implemented 16 months ago and replaced by the following standardized, 
unprefixed operations and attributes 5 months ago:

setLineDash
getLineDash
lineDashOffset

Note that the webkit prefixed attributes were just implemented in 
JavaScriptCore, no support for V8. Some of the main reason for supporting these 
attributes 16 months ago were:

- Firefox  supported them
- PDF.js needed them for draw PDFs.

PDF.js checks for the existence of the standardized operations and attributes 
now and uses them if supported.

Would it be possible to clean up the code a bit more and remove the prefixed 
attributes?

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

Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d

[Dirk Schulze]

On Jan 30, 2013, at 1:12 PM, Dean Jackson  wrote:

> 
> On 30/01/2013, at 12:46 PM, Dirk Schulze  wrote:
> 
>> Would it be possible to clean up the code a bit more and remove the prefixed 
>> attributes?
> 
> I don't think they should be removed yet. As you mentioned, it's been 16 
> months which is at least one Safari release cycle. I'd prefer that we give a 
> console warning for now.

This sounds reasonable for me. Just as a note, if the next Safari release for 
iOS and Mac do not add this console warning, it may take another year before 
the code can be cleaned up. The impact is minimal so.

Greetings,
Dirk

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

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

Re: [webkit-dev] Adding blending mode to background images

[Dirk Schulze]

Hi Rik,

Can you just add an example for the better understanding please?

Greetings,
Dirk

On Feb 2, 2013, at 6:43 AM, Rik Cabanier  wrote:

> Hi,
> 
> I'd like to add support for blending of background images.
> The spec for this feature can be found here: 
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#background-blend-mode
> 
> The implementation will be tracked by a meta bug: 
> https://bugs.webkit.org/show_bug.cgi?id=108546
> 
> Please let me know of any concerns.
> ___
> 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] Adding blending mode to background images

[Dirk Schulze]

On Feb 2, 2013, at 8:01 AM, Benjamin Poulain  wrote:

> On Fri, Feb 1, 2013 at 12:44 PM, Rik Cabanier  wrote:
> background-image: url(a.png), url(b.png);
> -webkit-background-blend-mode: screen, screen;
> 
> Out of curiosity:
> 
> I am probably way too late for the party, but why not blend 
> surface-to-surface? E.g.
> background-image: blend(url(foo.png), url(bar.png), difference).
> 
> This is in order to easily stack them:
> background-image: blend(blend(url(foo.png), url(bar.png), difference), 
> url(giraffe.gif), screen).

I like the idea, but it has the big disadvantage that you can not repeat an 
image, change origin and size before blending with the next layer.

Greetings,
Dirk

> 
> Although, maybe we don't want that as it could get more difficult to 
> optimize...
> 
> 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] Opera and WebKit

[Dirk Schulze]

Very mixed feelings. Presto is a great engine. It is really hard to loose a 
browser engine such as Presto from a lot of perspectives. My tributes to 
Presto, an awesome competitor in the browser market, and the developers of 
Presto.

Thanks for the announcement on the WebKit-dev mailing list.  Opera is very 
welcome to the WebKit community. Lets take some steps into the future of the 
web together.

Greetings,
Dirk

On Feb 13, 2013, at 12:08 AM, "Håkon Wium Lie"  wrote:

> Dear WebKit community,
> 
> Many of us have met through various web standards efforts, such as
> W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
> forum for us: the webkit-dev mailing list.
> 
> We have known WebKit and its KTHML predecessor for some time. Lars
> Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
> years. TrollTech and Opera shared a building in Oslo, a building which
> has earned its place in the rendering engine hall of fame.
> 
> Some of our best programmers have been working on the WebKit code for
> a while, and today we have announced that we will be using the WebKit
> engine in the future [1]. We will also submit our code; switching from
> Presto to WebKit frees up resources and allows us to contribute to the
> WebKit platform.
> 
> The first contributions from our side will be in multi-column layout
> [2]. We have experimented with combining multicol layout with
> page floats and column spans [3]; in 10 lines of CSS code one can
> create amazingly beautiful, scaleable and responsive paged
> presentations [4].
> 
> We hope to work with you to further strengthen the open web that we
> all believe in.
> 
>   [1] http://www.opera.com/press/releases/2013/02/13/
>   [2] http://www.w3.org/TR/css3-multicol/
>   [3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
>   [4] http://people.opera.com/howcome/2013/02-reader
> 
> Cheers,
> 
> Håkon Wium Lie
> CTO Opera Software
> http://people.opera.com/howcome
> ___
> 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] Opera and WebKit

[Dirk Schulze]

I interprete 'Chromium' as V8 and not JSC.

Dirk

2013/2/13 Oliver Hunt 

> Welcome to webkit!
>
> Are you still going to be using Carakan?  Or are you planning on using
> WebKit's ES engine?  If so are there any Carakan<->JSC compatibility issues
> we should be aware of?
>
> --Oliver
>
> On Feb 13, 2013, at 12:06 AM, Håkon Wium Lie  wrote:
>
> > Dear WebKit community,
> >
> > Many of us have met through various web standards efforts, such as
> > W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
> > forum for us: the webkit-dev mailing list.
> >
> > We have known WebKit and its KTHML predecessor for some time. Lars
> > Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
> > years. TrollTech and Opera shared a building in Oslo, a building which
> > has earned its place in the rendering engine hall of fame.
> >
> > Some of our best programmers have been working on the WebKit code for
> > a while, and today we have announced that we will be using the WebKit
> > engine in the future [1]. We will also submit our code; switching from
> > Presto to WebKit frees up resources and allows us to contribute to the
> > WebKit platform.
> >
> > The first contributions from our side will be in multi-column layout
> > [2]. We have experimented with combining multicol layout with
> > page floats and column spans [3]; in 10 lines of CSS code one can
> > create amazingly beautiful, scaleable and responsive paged
> > presentations [4].
> >
> > We hope to work with you to further strengthen the open web that we
> > all believe in.
> >
> >   [1] http://www.opera.com/press/releases/2013/02/13/
> >   [2] http://www.w3.org/TR/css3-multicol/
> >   [3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
> >   [4] http://people.opera.com/howcome/2013/02-reader
> >
> > Cheers,
> >
> > Håkon Wium Lie
> > CTO Opera Software
> > http://people.opera.com/howcome
> > ___
> > 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] Enable CANVAS_PATH by default

[Dirk Schulze]

Hi WebKit folks,

I worked on the Path interface defined by the Canvas spec of W3C and WHATWG 
[1][2] for the last couple of weeks.

Summary:
Canvas supports a new DOM interface called Path. The Path interface takes a 
series of very well known path methods like moveTo, lineTo, cubicCurveTo, rect 
and allows to create and keep a path independent of a Canvas context. 
Additionally, I added the attribute 'currentPath' to the Canvas context to 
provide read and write access to the current path created on the Canvas 
context. Code snippet:

var path = new Path();
path.rect(0,0,100,100);

var ctx = canvas.getContext('2d');
ctx.currentPath = path;
ctx.lineTo(200,200);
ctx.closePath();

var path2 = ctx.currentPath; // path2 != path

Not implemented are addText, addPath,  addPathByStrokingText. Another proposal 
from Rik Cabanier[3] seems to address the idea behind these methods better.

I would like to ask to enable CANVAS_PATH by default on trunk. Ports can 
opt-out the flag again. More information about some implementation details in a 
short article[4]. If there are any concerns, suggestions or questions, I am 
happy to answer them.

Greetings,
Dirk

[1] http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#path-objects
[2] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects
[3] http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
[4] http://dschulze.com/blog/articles/10/html-canvas-path-object-in-webkit
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Deprecating JS interface

[Dirk Schulze]

Hi,

There are several steps on deprecating features[1]. My question is about 
deprecating a whole interface and throwing warnings that the feature is 
deprecated. 

If I have the following interface for deprecation:

[Constructor]
interface Bla {
attribute bar;
void foo();
}

Should I just throw the deprecation warning on calling the constructor (and any 
method/attribute creating the object), or on calling foo and bar as well?

Greetings,
Dirk

[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 16, 2013, at 6:54 PM, Adam Barth  wrote:

> It's much easier to discuss a concrete example.  Which interface are
> you interested in deprecating?

I can understand that it is easier to discuss on a concrete example, even if I 
would like to discuss this in a general scope. We have multiple interfaces that 
we may want to deprecate at some point.

A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in 
WebCore yet but hopefully replaced by a standardized Matrix interface in the 
future[2]. This new interface will not be fully compatible to WebKitCSSMatrix 
and I would like to warn authors before they actually start using it.

Again, I think it would be better to discuss this in a wider scope but am happy 
to discuss it on the concrete example as well. This actually might make it 
easier to come up with general rules in the future.

Greetings,
Dirk

[1] https://bugs.webkit.org/show_bug.cgi?id=110048
[2] https://bugs.webkit.org/show_bug.cgi?id=110001
> 
> Adam
> 
> 
> On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze  wrote:
>> Hi,
>> 
>> There are several steps on deprecating features[1]. My question is about 
>> deprecating a whole interface and throwing warnings that the feature is 
>> deprecated.
>> 
>> If I have the following interface for deprecation:
>> 
>> [Constructor]
>> interface Bla {
>>attribute bar;
>>void foo();
>> }
>> 
>> Should I just throw the deprecation warning on calling the constructor (and 
>> any method/attribute creating the object), or on calling foo and bar as well?
>> 
>> Greetings,
>> Dirk
>> 
>> [1] http://trac.webkit.org/wiki/DeprecatingFeatures
>> ___
>> 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] Deprecating JS interface

[Dirk Schulze]

On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:

> 
> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
> 
>> 
>> On Feb 16, 2013, at 6:54 PM, Adam Barth  wrote:
>> 
>>> It's much easier to discuss a concrete example.  Which interface are
>>> you interested in deprecating?
>> 
>> I can understand that it is easier to discuss on a concrete example, even if 
>> I would like to discuss this in a general scope. We have multiple interfaces 
>> that we may want to deprecate at some point.
>> 
>> A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in 
>> WebCore yet but hopefully replaced by a standardized Matrix interface in the 
>> future[2]. This new interface will not be fully compatible to 
>> WebKitCSSMatrix and I would like to warn authors before they actually start 
>> using it.
> 
> Since you're the one designing the new interface (or at least you are the 
> spec editor), why don't you just make it compatible? Breaking changes to 
> existing Web APIs should only be done as a last resort, and I don't 
> understand the justification for doing it here.

It is a proposal so far and no draft yet. Technically, I am not the editor of 
it so. The proposal has quite some way to go (hopefully not too much) and I do 
not plan to land anything in this direction as long as the responsible WGs did 
not agree on continuing with the proposal and the general direction. I will 
post a separate mail with the actual feature implementation announcement when 
the time comes.

> Then we have a much simper transition story, and WebKitCSSMatrix can be 
> aliased to the new class.

I indeed tried to preserve the behavior of WebKitCSSMatrix as much as possible. 
I got an action of the SVG WG to work on a replacement for SVGMatrix. The 
highest priority was to preserver the behavior of SVGMatrix (which is 
definitely actively used by web content) and provide a basic interface that can 
be used beyond just SVG. There are a lot of use cases in the near future for a 
generalized matrix IMO. SVG, CSS Transforms, Canvas and WebGL are the obvious 
once. A specification interoperable format to share transformation data seems 
extremely desirable. I encourage everyone who is interested to look at the 
proposal and give feedback.

> 
>> 
>> Again, I think it would be better to discuss this in a wider scope but am 
>> happy to discuss it on the concrete example as well. This actually might 
>> make it easier to come up with general rules in the future.
> 
> I think spamming the console is not a useful thing to do for interfaces that 
> actually have significant usage in the wild. A more productive step would be 
> to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going 
> to be able to remove it.

I agree that we need more metrics to discuss the next active steps on 
WebKitCSSMatrix and I already uploaded a patch to add it to the 
FeatureObserver[1].

The question remains: How do we want to continue with deprecating WebKit 
specific features in the long term. Especially when we have a standard 
compliant replacement. It is extremely hard to maintain all different 
behaviors. So far we have multiple implementations of background, flex-box, 
gradients to name some. This doesn't scale very well and there will be a time 
where we can not guarantee for the correct functioning of old features. This is 
a problem that other browsers like IE are focused for quite some time as well 
(not necessarily successfully). As long as we are concerned to deprecate and 
remove features, we increase the complexity of the code base. Less and less 
reviewers will be able to determine the behavior of patches to the general code 
base, while we increase the feature count and interoperability between modules 
more and more. There is no other way then to risk breaking content that relies 
on non-standardized behavior of platforms. And we should formalize this t
 o give a bit more reliability to web authors. The last section on [2] is too 
vague at the moment.

Greetings,
Dirk

[1] https://bugs.webkit.org/show_bug.cgi?id=110002
[2] http://trac.webkit.org/wiki/DeprecatingFeatures


> 
> Regards,
> Maciej
> 
> ___
> 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] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 12:08 AM, Adam Barth  wrote:

> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
>>> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
>>>> On Feb 16, 2013, at 6:54 PM, Adam Barth  wrote:
>>>> 
>>>>> It's much easier to discuss a concrete example.  Which interface are
>>>>> you interested in deprecating?
>>>> 
>>>> I can understand that it is easier to discuss on a concrete example, even 
>>>> if I would like to discuss this in a general scope. We have multiple 
>>>> interfaces that we may want to deprecate at some point.
>>>> 
>>>> A concrete example I thought about is WebKitCSSMatrix[1]. It is not used 
>>>> in WebCore yet but hopefully replaced by a standardized Matrix interface 
>>>> in the future[2]. This new interface will not be fully compatible to 
>>>> WebKitCSSMatrix and I would like to warn authors before they actually 
>>>> start using it.
>>> 
>>> Since you're the one designing the new interface (or at least you are the 
>>> spec editor), why don't you just make it compatible? Breaking changes to 
>>> existing Web APIs should only be done as a last resort, and I don't 
>>> understand the justification for doing it here.
>> 
>> It is a proposal so far and no draft yet. Technically, I am not the editor 
>> of it so. The proposal has quite some way to go (hopefully not too much) and 
>> I do not plan to land anything in this direction as long as the responsible 
>> WGs did not agree on continuing with the proposal and the general direction. 
>> I will post a separate mail with the actual feature implementation 
>> announcement when the time comes.
>> 
>>> Then we have a much simper transition story, and WebKitCSSMatrix can be 
>>> aliased to the new class.
>> 
>> I indeed tried to preserve the behavior of WebKitCSSMatrix as much as 
>> possible. I got an action of the SVG WG to work on a replacement for 
>> SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix 
>> (which is definitely actively used by web content) and provide a basic 
>> interface that can be used beyond just SVG. There are a lot of use cases in 
>> the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas 
>> and WebGL are the obvious once. A specification interoperable format to 
>> share transformation data seems extremely desirable. I encourage everyone 
>> who is interested to look at the proposal and give feedback.
>> 
>>> 
>>>> 
>>>> Again, I think it would be better to discuss this in a wider scope but am 
>>>> happy to discuss it on the concrete example as well. This actually might 
>>>> make it easier to come up with general rules in the future.
>>> 
>>> I think spamming the console is not a useful thing to do for interfaces 
>>> that actually have significant usage in the wild. A more productive step 
>>> would be to measure usage of WebKitCSSMatrix. If it's reasonably high, 
>>> we're not going to be able to remove it.
>> 
>> I agree that we need more metrics to discuss the next active steps on 
>> WebKitCSSMatrix and I already uploaded a patch to add it to the 
>> FeatureObserver[1].
>> 
>> The question remains: How do we want to continue with deprecating WebKit 
>> specific features in the long term. Especially when we have a standard 
>> compliant replacement. It is extremely hard to maintain all different 
>> behaviors. So far we have multiple implementations of background, flex-box, 
>> gradients to name some. This doesn't scale very well and there will be a 
>> time where we can not guarantee for the correct functioning of old features. 
>> This is a problem that other browsers like IE are focused for quite some 
>> time as well (not necessarily successfully). As long as we are concerned to 
>> deprecate and remove features, we increase the complexity of the code base. 
>> Less and less reviewers will be able to determine the behavior of patches to 
>> the general code base, while we increase the feature count and 
>> interoperability between modules more and more. There is no other way then 
>> to risk breaking content that relies on non-standardized behavior of 
>> platforms. And we should formalize thi
 s
>  to give a bit more reliability to web authors. The last section on [2] is 
> too vague at the moment.
> 
> I don't think we're be successful at form

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:

> 
> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
> 
>> 
>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
>> 
>>> 
>>> The discussion on each single feature let us forget the greater scope of 
>>> this problem. That is why I did not start with a concrete example.
>>> 
>>> What about going another direction? Right now we have compiler flags for a 
>>> lot of new features. What if we turn this around? Why not having a compiler 
>>> flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make 
>>> sure deprecated features still work properly. Release builds should turn it 
>>> on to not break compatibility. But every binary build of a nightly or 
>>> preview has it turned off. A lot of developers experiment with Chrome 
>>> Canary and WebKit nightlies already. It might be a drop in the bucket, but 
>>> still can have some influence on decreasing the use of deprecated content. 
>>> Features like CSS gradients, transitions and animations might be good 
>>> candidates at the beginning for this flag.
>> 
>> This carries the risk of decreasing test coverage of Nightlies and Canaries. 
>>  I don't think that is acceptable.
>> 
>> Users who download them and cannot use a web page because that page had 
>> deprecated features will then not be able to experience what bugs we had, 
>> those deprecated features notwithstanding.
>> 
>> I empathize with the desire to remove cruft.  But we shouldn't remove things 
>> if it breaks the web, even in Nightlies and Canaries.
> 
> I agree with Phil. And as a corollary, if removing something *doesn't* break 
> the Web and we think it's otherwise bad, then there's no need to do a special 
> dance with nightlies before removing.

Then we should face it. Prefixed content for CSS gradients, animation, 
transition, transforms, CSS Image functions, masking and a lot more will not go 
away. This basically means we will need to support them for an undetermined 
period of time, possibly for the projects lifetime. This will be the same for 
every popular prefixed feature that we introduce in the future.

If we are honest about this we may can prevent future content to be a burden on 
maintenance and use similar concepts as Mozilla does with runtime flags on 
unprefixed features.

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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 2:47 PM, Ryosuke Niwa  wrote:

>> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>> Then we should face it. Prefixed content for CSS gradients, animation, 
>> transition, transforms, CSS Image functions, masking and a lot more will not 
>> go away. This basically means we will need to support them for an 
>> undetermined period of time, possibly for the projects lifetime. This will 
>> be the same for every popular prefixed feature that we introduce in the 
>> future.
>> 
>> If we are honest about this we may can prevent future content to be a burden 
>> on maintenance and use similar concepts as Mozilla does with runtime flags 
>> on unprefixed features.
> 
> This is why we need to be extremely careful when introducing new features. 

I absolutely agree.  Chrome introduced the runtime flags as one possible 
solution for this problem.

Greetings,
Dirk

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

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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 9:16 AM, Adam Barth  wrote:

> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:
>>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
>>>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
>>>>> The discussion on each single feature let us forget the greater scope of 
>>>>> this problem. That is why I did not start with a concrete example.
>>>>> 
>>>>> What about going another direction? Right now we have compiler flags for 
>>>>> a lot of new features. What if we turn this around? Why not having a 
>>>>> compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk 
>>>>> to make sure deprecated features still work properly. Release builds 
>>>>> should turn it on to not break compatibility. But every binary build of a 
>>>>> nightly or preview has it turned off. A lot of developers experiment with 
>>>>> Chrome Canary and WebKit nightlies already. It might be a drop in the 
>>>>> bucket, but still can have some influence on decreasing the use of 
>>>>> deprecated content. Features like CSS gradients, transitions and 
>>>>> animations might be good candidates at the beginning for this flag.
>>>> 
>>>> This carries the risk of decreasing test coverage of Nightlies and 
>>>> Canaries.  I don't think that is acceptable.
>>>> 
>>>> Users who download them and cannot use a web page because that page had 
>>>> deprecated features will then not be able to experience what bugs we had, 
>>>> those deprecated features notwithstanding.
>>>> 
>>>> I empathize with the desire to remove cruft.  But we shouldn't remove 
>>>> things if it breaks the web, even in Nightlies and Canaries.
>>> 
>>> I agree with Phil. And as a corollary, if removing something *doesn't* 
>>> break the Web and we think it's otherwise bad, then there's no need to do a 
>>> special dance with nightlies before removing.
>> 
>> Then we should face it. Prefixed content for CSS gradients, animation, 
>> transition, transforms, CSS Image functions, masking and a lot more will not 
>> go away. This basically means we will need to support them for an 
>> undetermined period of time, possibly for the projects lifetime. This will 
>> be the same for every popular prefixed feature that we introduce in the 
>> future.
>> 
>> If we are honest about this we may can prevent future content to be a burden 
>> on maintenance and use similar concepts as Mozilla does with runtime flags 
>> on unprefixed features.
> 
> Just because we want to be thoughtful about which features we
> deprecate doesn't mean that we'll be unsuccessful in removing
> vendor-prefixed features.

I really hope so. Right now it looks like we hope that the time will solve the 
problems that we introduced. I fear that this will not be the case for some 
popular prefixed features and requires a bit more of a push. See the 
'mozOpacity' interface on Gecko[1] as one example. Otherwise we could end up 
with the worst case scenario that less reviewers are capable to estimate the 
influence of a patch.

Greetings,
Dirk

[1]  https://bugzilla.mozilla.org/show_bug.cgi?id=765645

> 
> Adam

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

[webkit-dev] New WebKit reviewer: Stephen Chenney

[Dirk Schulze]

Hi WebKit folks,


It is a pleasure to announce that Stephen Chenney 
is a WebKit Reviewer now.


Stephen did and does an awesome job on various SVG, Font and Skia related
topics. He fixed at least a dozen of urgent security bugs and has a great
understanding of the WebCore code base.

Please join me in congratulating Stephen for his new status!


Greetings,

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

Re: [webkit-dev] Best practices for landing new/changed layout test expectations?

[Dirk Schulze]

On Feb 25, 2013, at 4:27 PM, Ryosuke Niwa  wrote:

> On Mon, Feb 25, 2013 at 3:36 PM, Glenn Adams  wrote:
> 
> On Mon, Feb 25, 2013 at 3:53 PM, Ryosuke Niwa  wrote:
> On Mon, Feb 25, 2013 at 2:48 PM, Dirk Pranke  wrote:
> On Mon, Feb 25, 2013 at 2:05 PM, Ryosuke Niwa  wrote:
> > On Mon, Feb 25, 2013 at 1:39 PM, Dirk Pranke  wrote:
> >> Are you suggesting we should land a "failling" baseline in the meantime?
> >
> >
> > No. I'm suggesting patch authors perform their due diligence and either ask
> > port maintainers to rebaseline or rebaseline tests themselves.
> >
> 
> I think either you misunderstood my question, or I am misunderstanding
> your answer. I'm not asking "who", I'm asking "what" ...
> 
> If we know some tests are failing, and when we fix a bug the tests
> will start passing again (but that patch might not land for quite some
> time), what should we (anyone) do in the meantime? Leave the tree red,
> land "incorrect" -expected baselines so that we can catch changes in
> behavior, or add lines to TestExpectations? Many of the lines you
> cited fell into the last category.
> 
> Either one of those two solutions would work (although I strictly advice we 
> do the latter) when there are failing tests and we need a fix in order for 
> those tests to pass but I'm not interested in discussing that matter at the 
> moment.
> 
> I'm specifically opposed to adding new entries to TestExpectations for the 
> sole purpose of rebaselining them later.
> 
> One of the modes that the new generic TE file permits is to specify a generic 
> Skip and overriding this with per-port Pass. This provides (IMO) a more 
> manageable way to land a patch that you expect will require per-port mods to 
> fully get the patch working on the primary ports. It also allows one to land 
> a patch containing tests where a subsequent patch will provide the 
> functionality to be tested.
> 
> I recently used both of these modes to sub-divide a large patch and to 
> incrementally verify (landing individual per-port fixes as needed) individual 
> ports.
> 
> Personally, I prefer this over the "just turn bots red" mode. I suspect the 
> turn bots red approach results in greater churn, due to rollouts and 
> re-landing, than the finer grain approach I outlined above. I agree it 
> requires the committer to follow through on other ports and eventually remove 
> the generic Skip and Pass rules (once it works everywhere), but we have to 
> assume here (IMO) that committers will do the right thing and take 
> responsibility for the process. [And if not, then remind them.]
> 
> So I for one, would vote against the "turn the bots red" approach. Overall, I 
> think that approach produces a higher interrupt load on our limited committer 
> and reviewer resources. I think it would be useful to give other procedures 
> an opportunity to be tried out so we can have more data for choosing between 
> alternative approaches.
> 
> This has been tried as many people including yourself are using this approach 
> in landing and rebaselining patches. In particular, a lot of new contributors 
> from Chromium port use this strategy.
> 
> When I used to work for Google, I periodically went through all entries in 
> TestExpectations files that needed rebaselines and manually rebaselined them 
> myself because people just leave entries like I've cited in another email all 
> the time.
> 
> Quite frankly, I don't want it to be my (or anyone but patch author's) job to 
> take care of all these stale entries people add.

The problem of Chromium in the early days was that all tests were rebaselined 
when they failed. Too many tests turned the bots red at this time and the 
Chromium folks didn't (couldn't?) take attention of all these failing tests. We 
lost the chance to fix a lot of these bugs immediately during this time. It 
took months to cover these tests in bug reports and fix them finally. Some 
tests may still report that everything is ok, even if they are failing - 
untracked. I see the current "needs rebaseline" approach better, since the 
tests are at least logged. I do not have an opinion how they should be logged.

Greetings,
Dirk

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

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

Re: [webkit-dev] Philip Rogers is now a Reviewer

[Dirk Schulze]

Congratulations Philip! :)

Greetings
Dirk

On Feb 28, 2013, at 12:11 PM, "Levi Weintraub" 
mailto:le...@chromium.org>> wrote:

Congratulations, Mr. Rogers!


On Thu, Feb 28, 2013 at 12:09 PM, Eric Seidel 
mailto:e...@webkit.org>> wrote:
Nice to have another hand for SVG reviews. :)

Grats to pdr!

___
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] Error while building WebKit

[Dirk Schulze]

If you build the cairo version on either windows or linux, your cairo
library is older than 1.4.
cairo_clip_extents is added to cairo with version 1.4. This is fixed in
newer tarballs by checking your installed version of the cairo library.
Just use a newer tarball or update cairo.

Dirk

Am Montag, den 16.03.2009, 06:20 -0700 schrieb jagadeesh k:
> Hi,
> I used the WebKit nightly build r29022 source tar balls and am
> geting the following error while building,
>  
> WebCore/platform/graphics/cairo/GraphicsContextCairo.cpp:827:error:'cairo_clip_extents'
>   was not declared in this scope
>  
> Thanks and Regards
> Jagadeesh
> 
>  
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

Re: [webkit-dev] Non-Scaling Stroke feature (SVGT 1.2)

[Dirk Schulze]

Hi,

I thougt that we already had a bug about this. It is a good idea to
support this feature in general. Even if our support for SVG 1.1 is not
perfect, we should think about some features of SVG 1.2 like media
support and also non scaling strokes. But implementing non scaling
strokes is not that easy. On SVG we transform the context multiple times
(translate, scale, skew) and stroke the path at the end. We may think
about transforming the path instead of the context but there might be
more problems on doing that.

-Dirk

Am Montag, den 16.11.2009, 16:23 -0600 schrieb Jeff Schiller:
> Hello,
> 
> I am interested in having broader support for non-scaling stroke on
> SVG shapes.  This is a SVGT 1.2 feature:
> http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke
> 
> This adds a CSS property and attribute: vector-effect.  This property
> can have three values:  none (default), inherit, or
> non-scaling-stroke.
> 
> When non-scaling-stroke, the stroke (outline) of a shape would
> maintain its specified width regardless of the transforms applied to
> the shape.  This is very useful when importing foreign SVG into new
> documents and in GIS/mapping scenarios (for instance, zooming in on a
> map would not "fatten" the driving directions path).
> 
> I realize that WebKit has been generally not interested in SVGT 1.2,
> but I feel it makes sense to cherry-pick certain features that really
> do improve SVG on the web.  Non-scaling stroke is one of these
> features.  FWIW, Opera has implemented this feature since version 9.5.
> 
> I have opened a bug and supplied a patch that gets this off the ground
> in WebKit:  https://bugs.webkit.org/show_bug.cgi?id=31438  I only need
> to figure out how to add some tests (need to understand how pixel
> tests work in WebKit).
> 
> Darin Adler requested that I bring this up on this list for discussion.
> 
> Thanks,
> Jeff Schiller
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] SVG Filters

[Dirk Schulze]

> What kinds of tests do we have for the code already? Do we have code that 
> tries to exercise edge cases? Do we have a fuzzer of some sort?
> 
> -- Darin

Every effect that was implemented has at least one test. They are mostly
simple test cases that just test one effect at once but there are also
more complex tests, to see the behavior on combining different effects.
I try to address the different edge cases of every filter effect and add
more tests if necessary.
Mainly effects with pixel manipulation already have more than one test
to target different edge cases.

- Dirk

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

Re: [webkit-dev] SVG Filters

[Dirk Schulze]

Hi Maciej and Darin,

you both suggested to add fuzz tests for SVG Filters. I looked at the
fuzz test LayoutTest/svg/dom/fuzz-path-parser.html. As an analogy to
this test, I would suggest an array with the effects to test, it's
number of inputs and attributes, that can't be randomly set.
But the basic question is, what should the fuzz test test?
The combination of different effects? Should every filter effect have
it's own fuzz test with a default input? Different sizes of effects?
We need to keep in mind, that LayoutTests will slow down, as more
comlpex the fuzz tests get.

Regards,
Dirk

Am Freitag, den 04.12.2009, 11:06 -0800 schrieb Maciej Stachowiak:
> On Dec 4, 2009, at 11:02 AM, Dirk Schulze wrote:
> 
> >> What kinds of tests do we have for the code already? Do we have  
> >> code that tries to exercise edge cases? Do we have a fuzzer of some  
> >> sort?
> >>
> >>-- Darin
> >
> > Every effect that was implemented has at least one test. They are  
> > mostly
> > simple test cases that just test one effect at once but there are also
> > more complex tests, to see the behavior on combining different  
> > effects.
> > I try to address the different edge cases of every filter effect and  
> > add
> > more tests if necessary.
> > Mainly effects with pixel manipulation already have more than one test
> > to target different edge cases.
> 
> I think the feature is ready to be enabled by default.
> 
> One thing that would strongly increase my confidence in actually  
> shipping it would be some form of fuzz testing. Design review by  
> security experts would also help, but that is hard to arrange. Whereas  
> anyone can write a fuzz tester.
> 
> Regards,
> Maciej


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

Re: [webkit-dev] #endif // Foo_h

[Dirk Schulze]

We have somtimes constructs like

#endif // ENABLE(SVG)
#endif // Foo_h

It just helps to understand why there are two endif's and what they are
good for. I think it's not a style issue not to write this comment, but
it can be helpful.

-Dirk

Am Montag, den 04.01.2010, 15:41 -0800 schrieb Darin Adler:
> On Jan 4, 2010, at 3:33 PM, Darin Fisher wrote:
> 
> > I noticed recently that the style bot started complaining about header 
> > files ending with "#endif" instead of "#endif // Foo_h".  I was surprised 
> > by this since the style guide does not require it.
> 
> I personally see little value in this sort of comment at the end of a header 
> file. I’m not sure what kind of problem it’s supposed to prevent.
> 
> -- Darin
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] Running pixel tests on build.webkit.org

[Dirk Schulze]

Would be great to have pixel tests on a bot back. And it would be great,
if the commit queue runs them too. Especially for patches of
non-commiters.

-Dirk

Am Donnerstag, den 07.01.2010, 10:19 -0800 schrieb Dimitri Glazkov:
> Are we planning to run pixel tests on the build bots? What's the
> general opinion here?
> 
> We're running them over at Chromium and it seems like a really good
> idea. Case in point:
> 
> Change http://trac.webkit.org/changeset/52900 broke a bunch of layout
> tests, all pixel results, and as such didn't register on the
> waterfall.
> 
> I rolled out the change for now.
> 
> :DG<
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


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

Re: [webkit-dev] Increasing the number of cross-platform/port expected results

[Dirk Schulze]

Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser:

> It could be an image, or it could be a configuration of  elements, or a 
> table, or something else that can be configured to look exactly the same as 
> the CSS border property being tested.
> 
> Simon

I like the idea of reftests. But how do we write tests for box-shadows,
gradients or patterns on a text (like in SVG)? All basic graphical
elements would still need pixel-tests, or do you have another idea?

Dirk

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

[webkit-dev] ie test center

[Dirk Schulze]

Hi,
Microsoft announced a new test suite, the "Internet Explorer testing
center" together with the first preview of the upcoming ie9.

http://samples.msdn.microsoft.com/ietestcenter/

In one table the "current" releases of the major browsers are compared
to ie9. Safari and Chrome do fail on more than 50% in some parts. Is the
test suite relevant enough to open a master bug at
http://bugs.webkit.org and list all failing tests, like we did on ACID3?

Greetings,
Dirk

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