[webkit-dev] Make accelerated compositing mandatory
Hello webkittens, Do you happen to know if we still have ports that build WebKit without accelerated compositing? If not, I'd like to write a patch that removes the flag and makes AC mandatory. From IRC, I've heard that the Haiku port (not upstreamed) disables the AC flag, but they agree they should switch it on in the future. Thoughts? Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GTK+ EWS bot lagging behind
Hey, Em Seg, 2014-01-27 às 19:18 -0800, Martin Robinson escreveu: On Mon, Jan 27, 2014 at 5:55 PM, Anders Carlsson ander...@apple.com wrote: Hello, there are currently 93 patches in the GTK+ EWS patch queue, is it stuck? If it’s not, I think it’s completely unreasable to expect committers to wait for 93 patches to be processed before landing. (This lead to a problem this weekend where I removed code from WebCore that was used by GTK+ WebKit and I couldn’t tell because the patch was never processed!) It just looks like the bot is wedged. I'll try to run a local EWS until it's unwedged. I was looking into it yesterday but had to drop it 'till today, it should be up and running in a couple hours, I think I managed to find the main issue. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur abu...@adobe.com wrote: Do you happen to know if we still have ports that build WebKit without accelerated compositing? If not, I'd like to write a patch that removes the flag and makes AC mandatory. From IRC, I've heard that the Haiku port (not upstreamed) disables the AC flag, but they agree they should switch it on in the future. Yes, GTK+ on Windows does not use accelerated compositing. I'm also fairly certain the WinCE port does not enable accelerated compositing. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs
On Jan 27, 2014, at 5:39 PM, Chris Fleizach cfleiz...@apple.com wrote: I dislike this change now that's been rolled out. The lack of email notices before confirmed that my patch was OK and I was able to do something else while waiting for review. Now I have to continually revisit the bug page checking to see if more bots have completed and that my patch is good. I think at least the person who submitted the patch should be notified when there's been an error. I agree that it would be nice for the patch author to be notified when there is an error. eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GTK+ EWS bot lagging behind
On Jan 28, 2014, at 3:43 AM, Gustavo Noronha Silva g...@gnome.org wrote: I was looking into it yesterday but had to drop it 'till today, it should be up and running in a couple hours, I think I managed to find the main issue. Yeah, it seems to be chugging along nicely now. Thanks! - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
The same is true for the WinCairo port, though I know Alex Christensen has been working towards correcting that. -Brent On Jan 28, 2014, at 7:49 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur abu...@adobe.com wrote: Do you happen to know if we still have ports that build WebKit without accelerated compositing? If not, I'd like to write a patch that removes the flag and makes AC mandatory. From IRC, I've heard that the Haiku port (not upstreamed) disables the AC flag, but they agree they should switch it on in the future. Yes, GTK+ on Windows does not use accelerated compositing. I'm also fairly certain the WinCE port does not enable accelerated compositing. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
The same is true for the WinCairo port, though I know Alex Christensen has been working towards correcting that. -Brent On Jan 28, 2014, at 7:49 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur abu...@adobe.com wrote: Do you happen to know if we still have ports that build WebKit without accelerated compositing? If not, I'd like to write a patch that removes the flag and makes AC mandatory. From IRC, I've heard that the Haiku port (not upstreamed) disables the AC flag, but they agree they should switch it on in the future. Yes, GTK+ on Windows does not use accelerated compositing. I'm also fairly certain the WinCE port does not enable accelerated compositing. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Jan 28, 2014, at 7:49 AM, Martin Robinson mrobin...@webkit.org wrote: Yes, GTK+ on Windows does not use accelerated compositing. This begs the question: How widely used is the GTK+ port of WebKit on Windows? Do enough people use it that it's worth the maintenance burden for the other ports that use accelerated compositing? - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
If we can’t drop the non-accelerated-compositing mode immediately, I think that non-accelerated-compositing should be the one that is treated as an exception and be renamed to use the word “deprecated”. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Tue, Jan 28, 2014 at 10:00 AM, Anders Carlsson ander...@apple.com wrote: This begs the question: How widely used is the GTK+ port of WebKit on Windows? Do enough people use it that it's worth the maintenance burden for the other ports that use accelerated compositing? An example of a browser that uses WebKitGTK+ on Windows is Midori: http://midori-browser.org/download/choose/ If it is at-all helpful, we don't have WebKit2 support for the GTK+ port on Windows. So if the majority of the maintanance burden is in WebKit2, there should be no problem with removing the non-AC code in WebKit2. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Jan 28, 2014, at 10:19 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Jan 28, 2014 at 10:00 AM, Anders Carlsson ander...@apple.com wrote: This begs the question: How widely used is the GTK+ port of WebKit on Windows? Do enough people use it that it's worth the maintenance burden for the other ports that use accelerated compositing? An example of a browser that uses WebKitGTK+ on Windows is Midori: http://midori-browser.org/download/choose/ Is this the only project using WebKitGTK+ on Windows? How many people do you think use it? If it is at-all helpful, we don't have WebKit2 support for the GTK+ port on Windows. So if the majority of the maintanance burden is in WebKit2, there should be no problem with removing the non-AC code in WebKit2. I don’t think we’ve ever had a problem with accelerated compositing being disabled in WebKit2. (I don’t know if anyone ever built without it). I’m not a layout and rendering person, but I suspect that the burden lies in that part of WebCore. I also don’t think building with accelerated compositing means that it has to be enabled at all; WebKitGTK+ on Windows could probably just have a stub implementation of the relevant GraphicsLayer classes. (FWIW, for the last two years or so WebKit2 on Mac has been running with accelerated compositing on always, and I strongly suspect this is the general direction other ports are taking too). - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Jan 28, 2014, at 10:47 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Jan 28, 2014 at 10:33 AM, Anders Carlsson ander...@apple.com wrote: I’m not a layout and rendering person, but I suspect that the burden lies in that part of WebCore. I also don’t think building with accelerated compositing means that it has to be enabled at all; WebKitGTK+ on Windows could probably just have a stub implementation of the relevant GraphicsLayer classes. A stub implementation disabled at runtime would be fine for us, I believe. Great! I’d be happy to review any patches to do this. Since we don’t have any WebKitGTK+/Windows buildbots or EWS bots, I think Andrei should go ahead and remove the flag and then the GTK+ maintainers can fix WebKitGTK+ for Windows. Does that sound like a reasonable approach? - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Jan 28, 2014, at 10:47 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Jan 28, 2014 at 10:33 AM, Anders Carlsson ander...@apple.com wrote: I’m not a layout and rendering person, but I suspect that the burden lies in that part of WebCore. I also don’t think building with accelerated compositing means that it has to be enabled at all; WebKitGTK+ on Windows could probably just have a stub implementation of the relevant GraphicsLayer classes. A stub implementation disabled at runtime would be fine for us, I believe. I think it would be fairly trivial to remove most of the #ifdefs but just never make any compositing layers on some platforms. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
On Tue, Jan 28, 2014 at 10:58 AM, Anders Carlsson ander...@apple.com wrote: Since we don’t have any WebKitGTK+/Windows buildbots or EWS bots, I think Andrei should go ahead and remove the flag and then the GTK+ maintainers can fix WebKitGTK+ for Windows. Does that sound like a reasonable approach? Sure. That sounds reasonable. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
The GTK port also disables accelerated compositing at build-time when building specifically for the Wayland windowing target. Adding AC support for this configuration is planned, but a stub implementation can be used as well until then. Cheers, Zan On Tue, Jan 28, 2014 at 10:47 AM, Martin Robinson mrobin...@webkit.orgwrote: On Tue, Jan 28, 2014 at 10:33 AM, Anders Carlsson ander...@apple.com wrote: I'm not a layout and rendering person, but I suspect that the burden lies in that part of WebCore. I also don't think building with accelerated compositing means that it has to be enabled at all; WebKitGTK+ on Windows could probably just have a stub implementation of the relevant GraphicsLayer classes. A stub implementation disabled at runtime would be fine for us, I believe. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
ENABLE(DECELERATED_COMPOSITING) On Jan 28, 2014, at 10:15 AM, Darin Adler da...@apple.com wrote: If we can’t drop the non-accelerated-compositing mode immediately, I think that non-accelerated-compositing should be the one that is treated as an exception and be renamed to use the word “deprecated”. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: COMPILE_ASSERT_MATCHING_ENUM is a bad idea
Hi floks!
I noticed that both the EFL port and GTK+ port use a
COMPILE_ASSERT_MATCHING_ENUM macro to make sure that WebCore enum values map to
API enum values correctly, for example:
COMPILE_ASSERT_MATCHING_ENUM(WEBKIT_WEB_NAVIGATION_REASON_LINK_CLICKED,
NavigationTypeLinkClicked);
This means that we can’t add new enums declarations (unless they’re added at
the end) without breaking the build.
Instead of doing this (and then just blindly casting between the API layer and
WebCore enum types), use conversion functions, like this (taken from WebKit2):
inline WebCore::PageVisibilityState
toPageVisibilityState(WKPageVisibilityState wkPageVisibilityState)
{
switch (wkPageVisibilityState) {
case kWKPageVisibilityStateVisible:
return WebCore::PageVisibilityStateVisible;
case kWKPageVisibilityStateHidden:
return WebCore::PageVisibilityStateHidden;
case kWKPageVisibilityStatePrerender:
return WebCore::PageVisibilityStatePrerender;
}
ASSERT_NOT_REACHED();
return WebCore::PageVisibilityStateVisible;
}
I plan to audit the Mac and Windows ports and look for places where we cast
between API enum types and WebCore enum types, and I filed
https://bugs.webkit.org/show_bug.cgi?id=127800 WebKitGTK+ should stop using
COMPILE_ASSERT_MATCHING_ENUM macros
https://bugs.webkit.org/show_bug.cgi?id=127801 EFL port should stop using
COMPILE_ASSERT_MATCHING_ENUM macros
for the Mac and EFL ports respectively. I’m happy to answer any questions about
this.
- Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] EFL EWS Bot output
Could whoever is responsible for the EFL EWS bot please make the bot set the correct mimetype on the build output. I've requested this before, but i'm trying again. It is really annoying that it triggers a download rather than just opening in the browser like the output from every other bot. Cheers, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature Announcement: URL API
Hi everyone, I would like to implement the URL API from the WHATWG URL spec, described here: http://url.spec.whatwg.org/#api I have a preliminary patch (not ready for review yet; needs tests and fixing build on other platforms) here: https://bugs.webkit.org/show_bug.cgi?id=127795 The patch implements the API with no flag and no prefix because it is simple, and as far as I know, reasonably well-liked. Parts of the API that are not yet in this patch: - Sharing the interface and implementation of URL properties with HTMLAnchorElement, HTMLAreaElement, Location and WorkerLocation - The URLSearchParams interface - Making parsing, stringification, and modification by parts match the parsing in the spec (and/or filing spec bugs where the spec doesn't seem to match other browsers). - The domainToASCII and domainToUnicode static methods (probably not to be implemented for now based on comments in the spec discouraging it) I plan to do all of these as future steps (except possibly the last part). Comments? My patch will probably be landable by Thursday if there are no objections. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Infinite scrolling feature exploration
Hi all, We're experimenting with engine features that could help people build infinite scrolling websites. To start, we're prototyping an event for triggering the loading of new content when the user has scrolled near a content edge. We'll be kicking off an open-ended discussion in the CSS WG about these events as well as other possible features for infinite scrolling. As a part of that discussion, we'd like to be able to have WG members grab a WebKit build to play with the prototype event and get a feel for how it works and if it's the sort of thing the platform should have. I've got a patch that adds these events behind a flag and enables them on the Mac port (so people can grab a nightly and try them out). I’d like to land this patch this week so we can have a demoable prototype to talk about in the CSS WG. If you’re curious about the approach, check out the patch here: https://bugs.webkit.org/show_bug.cgi?id=127371 If there are no objections, I'll land the patch on Thursday. Thanks, Beth ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL EWS Bot output
28 янв. 2014 г., в 14:59, Oliver Hunt oli...@apple.com написал(а): Could whoever is responsible for the EFL EWS bot please make the bot set the correct mimetype on the build output. I've requested this before, but i'm trying again. It is really annoying that it triggers a download rather than just opening in the browser like the output from every other bot. What needs to be fixed is that the output shouldn't have escape sequences. The MIME type of text/plain is set by webkit-queues server, but then networking code in the browser sees a resource without an extension and that has binary data in it, so it overrides the type. Another solution would be for webkitpy or webkit-queues to automagically strip escape sequences from the output. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Infinite scrolling feature exploration
Neat! Over in Blink-land, we're also quite interested in infinite
scrolling. Do you have a doc that describes the approach you're
investigating?
We've been experimenting with how you might be able to achieve infinite
scrolling using existing web platform API. You can see the engine we're
experimenting with at the URL below:
http://src.chromium.org/viewvc/chrome/trunk/src/tools/perf/page_sets/key_silk_cases/infinite_scrolling.html
You can mix-and-match that infinite scrolling engine with template and
web components to get markup that looks roughly as follows:
app-list id=messages
app-dismissable-list class=padding-wrapper
template repeat
app-dismissable-item class=item conversation
div class=avatar style=background-color: {{ avatarColor
}}{{ avatarLetter }}/div
div class=summary
div class=topline
div class=participants{{ participants }}/div
div class=time{{ time }}/div
/div
div class=bottomline
div class=previewspan class=subject{{ subject
}}/span mdash;
span class=snippet{{ snippet }}/span/div
div class=trinkets#x2606;/div
/div
/div
/app-dismissable-item
/template
/app-dismissable-list
/app-list
The app-list custom element stamps out a number of physical list items when
the page loads and then changes the values in the template as you scroll to
different positions in the list. You can see a worked example on GitHub:
https://github.com/abarth/app-widgets/blob/master/demo.html
We've been experimenting with these widgets in Blink, which means they
might not work in Safari yet.
Adam
On Tue, Jan 28, 2014 at 3:07 PM, Beth Dakin bda...@apple.com wrote:
Hi all,
We're experimenting with engine features that could help people build
infinite scrolling websites. To start, we're prototyping an event for
triggering the loading of new content when the user has scrolled near a
content edge.
We'll be kicking off an open-ended discussion in the CSS WG about these
events as well as other possible features for infinite scrolling. As a part
of that discussion, we'd like to be able to have WG members grab a WebKit
build to play with the prototype event and get a feel for how it works and
if it's the sort of thing the platform should have.
I've got a patch that adds these events behind a flag and enables them on
the Mac port (so people can grab a nightly and try them out). I'd like to
land this patch this week so we can have a demoable prototype to talk about
in the CSS WG. If you're curious about the approach, check out the patch
here: https://bugs.webkit.org/show_bug.cgi?id=127371
If there are no objections, I'll land the patch on Thursday.
Thanks,
Beth
___
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] Feature Announcement: URL API
On Jan 28, 2014, at 3:06 PM, Maciej Stachowiak m...@apple.com wrote: - The domainToASCII and domainToUnicode static methods (probably not to be implemented for now based on comments in the spec discouraging it) That is unfortunate, the Web Inspector could use these to show international domains better — instead of showing punycode. Otherwise, the URL parsing parts will be useful and I look forward to using them and removing our JS URL parser! — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] JavaScriptCore Merge of C Stack Work
The JavaScriptCore team at Apple has been doing work on a branch (http://svn.webkit.org/repository/webkit/branches/jsCStack) to move JavaScript processing to use the native C stack for all engines (LLInt, Baseline JIT, DFG JIT, and the new FTL JIT). We are in the end stages of merging the work of that branch to trunk (tracked in https://bugs.webkit.org/show_bug.cgi?id=127763). When this merge is complete and the patch is landed, ports that use the LLInt and/or any JIT will use the native call-return stack to make calls to/from JavaScript. The LLINT C-Loop will be the only code that uses the separate JSStack, and only while in the C-Loop. We are relying on the EWS bots to test ports that we can’t test directly. There are some ports where there aren’t any EWS bots (SH4 and MIPS). Although we have made what we think are the correct changes for all ports, the changes for those we can’t test are speculative at best. Obviously, if there are any issues we will support the work of others to get the ports they support working. - Michael Saboff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: Remove ENABLE(SVG)
Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I’d like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a “minimal build” working, but I don’t think the clutter of the #ifdefs is worth that. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Infinite scrolling feature exploration
Hi, Adam wrote: Over in Blink-land, we're also quite interested in infinite scrolling. Great! It's an increasingly common pattern that could use some help from the engine. We've been experimenting with how you might be able to achieve infinite scrolling using existing web platform API. Cool. I agree with the general principle, but I want to ensure Web authors don't have to roll their own scrolling engine with transforms and rAF just to do interesting things like non-janky infinite scrolling. I think this will require some additions to the platform, but hopefully we can keep the Web-exposed changes minimal. Do you have a doc that describes the approach you're investigating? I'm in the middle of writing up an email for www-style with our thought process and what we've looked at; stay tuned. Ted ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
Not a true statement if you consider out of tree ports. None of the ports we have done at Crank have used or needed svg support and as embedded systems, they all benefit from the smaller footprint. Thanks, Thomas - Reply message - From: Sam Weinig wei...@apple.com To: webkit-dev@lists.webkit.org Development webkit-dev@lists.webkit.org Subject: [webkit-dev] Proposal: Remove ENABLE(SVG) Date: Tue, Jan 28, 2014 18:13 Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I’d like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a “minimal build” working, but I don’t think the clutter of the #ifdefs is worth that. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
On 1/28/14, 4:20 PM, Thomas Fletcher wrote: Not a true statement if you consider out of tree ports. None of the ports we have done at Crank have used or needed svg support and as embedded systems, they all benefit from the smaller footprint. Out of tree ports that do not contribute back upstream are not relevant for deciding the direction of WebKit. Do you guys help on WebKit.org? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
On Jan 28, 2014, at 4:20 PM, Thomas Fletcher tho...@cranksoftware.com wrote: Not a true statement if you consider out of tree ports. In general, we do not take in consideration ports that don’t contribute back or live in tree. None of the ports we have done at Crank have used or needed svg support and as embedded systems, they all benefit from the smaller footprint. Since you live out of tree, you probably need to do a bit of merging anyway, so you will be free to add back the #ifdefs. - Sam___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
This sounds good to me. A WebKit without SVG support is scarcely a WebKit at all. On Jan 28, 2014, at 4:13 PM, Sam Weinig wei...@apple.com wrote: Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I’d like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a “minimal build” working, but I don’t think the clutter of the #ifdefs is worth that. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
On Jan 28, 2014, at 4:51 PM, Philip Rogers p...@google.com wrote: This will make hacking on WebKit much easier. For better or worse, SVG is tightly coupled with the rest of rendering/. We recently measured SVG usage on the web and found 10% of all pageviews contain SVG. Do you plan to remove ENABLE(SVG_FONTS) as well? This is about SVG, not SVG_FONTS. And I agree that SVG can be removed. Not the latter at this point. Greetings, Dirk On Tue, Jan 28, 2014 at 4:34 PM, Andreas Kling akl...@apple.com wrote: This sounds good to me. A WebKit without SVG support is scarcely a WebKit at all. On Jan 28, 2014, at 4:13 PM, Sam Weinig wei...@apple.com wrote: Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I'd like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a minimal build working, but I don't think the clutter of the #ifdefs is worth that. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Infinite scrolling feature exploration
On Jan 28, 2014 4:19 PM, Edward O'Connor eocon...@apple.com wrote: Hi, Adam wrote: Over in Blink-land, we're also quite interested in infinite scrolling. Great! It's an increasingly common pattern that could use some help from the engine. We've been experimenting with how you might be able to achieve infinite scrolling using existing web platform API. Cool. I agree with the general principle, but I want to ensure Web authors don't have to roll their own scrolling engine with transforms and rAF just to do interesting things like non-janky infinite scrolling. I think this will require some additions to the platform, but hopefully we can keep the Web-exposed changes minimal. Just to clarify, in those examples, the browser is driving the scrolling. We're just using transforms to recycle DOM nodes, which keeps the DOM finite even though the scrollable area is infinite. Adam Do you have a doc that describes the approach you're investigating? I'm in the middle of writing up an email for www-style with our thought process and what we've looked at; stay tuned. Ted ___ 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] Make accelerated compositing mandatory
I've made WinCairo almost able to enable accelerated compositing using the TextureMapper code. I would not consider it stable yet, but it compiles and runs to the point that it can be debugged. WebGL doesn't work at all with it yet, and I've had a few other problems and crashes. I can't dedicate a lot of time to it right now and I'm not a compositing expert, but I'd be happy to share what I've done. Alex Christensen On Tue, Jan 28, 2014 at 2:16 PM, Maciej Stachowiak m...@apple.com wrote: ENABLE(DECELERATED_COMPOSITING) On Jan 28, 2014, at 10:15 AM, Darin Adler da...@apple.com wrote: If we can't drop the non-accelerated-compositing mode immediately, I think that non-accelerated-compositing should be the one that is treated as an exception and be renamed to use the word deprecated. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Alex Christensen FlexSim Software Products, Inc. *1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097* *Voice: 801-224-6914 | Fax: 801-224-6984* *Email:* al...@flexsim.com k...@flexsim.com *URL:* www.flexsim.com This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
On Jan 28, 2014, at 4:51 PM, Philip Rogers p...@google.com wrote: This will make hacking on WebKit much easier. For better or worse, SVG is tightly coupled with the rest of rendering/. We recently measured SVG usage on the web and found 10% of all pageviews contain SVG. Interesting stat! Thanks. Do you plan to remove ENABLE(SVG_FONTS) as well? Not at this point. -Sam On Tue, Jan 28, 2014 at 4:34 PM, Andreas Kling akl...@apple.com wrote: This sounds good to me. A WebKit without SVG support is scarcely a WebKit at all. On Jan 28, 2014, at 4:13 PM, Sam Weinig wei...@apple.com wrote: Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I’d like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a “minimal build” working, but I don’t think the clutter of the #ifdefs is worth that. -Sam ___ 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] PSA: COMPILE_ASSERT_MATCHING_ENUM is a bad idea
El mar, 28-01-2014 a las 14:32 -0800, Anders Carlsson escribió:
Hi floks!
I noticed that both the EFL port and GTK+ port use a
COMPILE_ASSERT_MATCHING_ENUM macro to make sure that WebCore enum values map
to API enum values correctly, for example:
COMPILE_ASSERT_MATCHING_ENUM(WEBKIT_WEB_NAVIGATION_REASON_LINK_CLICKED,
NavigationTypeLinkClicked);
Yes, we preferred that way to keep the code simpler and avoid long
switches.
This means that we can’t add new enums declarations (unless they’re added at
the end) without breaking the build.
That's right, it's also true that most of the times enums are extended
adding new entries at the end.
Instead of doing this (and then just blindly casting between the API layer
and WebCore enum types), use conversion functions, like this (taken from
WebKit2):
inline WebCore::PageVisibilityState
toPageVisibilityState(WKPageVisibilityState wkPageVisibilityState)
{
switch (wkPageVisibilityState) {
case kWKPageVisibilityStateVisible:
return WebCore::PageVisibilityStateVisible;
case kWKPageVisibilityStateHidden:
return WebCore::PageVisibilityStateHidden;
case kWKPageVisibilityStatePrerender:
return WebCore::PageVisibilityStatePrerender;
}
ASSERT_NOT_REACHED();
return WebCore::PageVisibilityStateVisible;
}
I plan to audit the Mac and Windows ports and look for places where we cast
between API enum types and WebCore enum types, and I filed
https://bugs.webkit.org/show_bug.cgi?id=127800 WebKitGTK+ should stop using
COMPILE_ASSERT_MATCHING_ENUM macros
https://bugs.webkit.org/show_bug.cgi?id=127801 EFL port should stop using
COMPILE_ASSERT_MATCHING_ENUM macros
for the Mac and EFL ports respectively. I’m happy to answer any questions
about this.
Ok, let's fix this sooner rather than later, then.
- Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
--
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
