Re: [webkit-dev] Position on new syntax in mediaqueries-4

We are supportive. Much of the needed code was already written for the container queries (as you know) so implementation should be relatively easy. antti On Mon, Apr 11, 2022 at 1:57 PM Anders Hartvoll Ruud via webkit-dev < webkit-dev@lists.webkit.org> wrote: > For example, in mediaqueries-4

Re: [webkit-dev] in WebKit?

I landed the updated behavior. antti On Mon, Oct 19, 2020 at 11:29 AM Anders Hartvoll Ruud wrote: > Yes, there's css/selectors/is-where-error-recovery.tentative.html > > (.tentative tag to be dropped momentarily). > > On Sat, Oct 17, 2020 at 10:17 AM Antti Koivisto wrot

Re: [webkit-dev] in WebKit?

Seems like a sensible change. Are there WPT tests for this behavior already? antti On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud wrote: > Hi, > > We are about to ship support for :is() and :where() in Chromium, including > support for . >

Re: [webkit-dev] WebKit's position on @property

We like declarative @property and will definitely consider implementing it. We like CSS.registerProperty less since it is a performance footgun. antti On Fri, Apr 24, 2020 at 10:25 AM Anders Hartvoll Ruud wrote: > Thanks for the response. I did read through that issue at some point, but > I

Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa wrote: > On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro > wrote: > >> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa wrote: >> > Namely, some people write a lambda as: >> > auto x = [] () { } >> > >> > with a space between [] and () while others wou

Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

On Fri, Nov 1, 2019 at 10:50 PM Yusuke Suzuki wrote: > > > On Nov 1, 2019, at 11:53, Michael Catanzaro > wrote: > > > > On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa wrote: > >> Namely, some people write a lambda as: > >> auto x = [] () { } > >> with a space between [] and () while others would

Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

On Mon, Aug 19, 2019 at 10:25 AM Yusuke Suzuki wrote: > Hello WebKit folks! > > I would like to announce that I’ve just landed the patch which introduces > `WTF::makeUnique` and `WTF::makeUniqueWithoutFastMallocCheck` in > https://trac.webkit.org/changeset/248846. > They are drop-in-replacement t

Re: [webkit-dev] Is anyone maintaining Nicosia scrolling code?

On Sat, Feb 23, 2019 at 1:30 PM wrote: > On Sat, Feb 23, 2019, at 2:47 AM, Simon Fraser wrote: > > There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that > > I keep breaking with scrolling tree refactoring. Most of it it stubs. > > Is anyone maintaining this code, because it obvio

Re: [webkit-dev] Rename AtomicString to AtomString

Sounds good to me. antti On Wed, Jan 30, 2019 at 6:33 PM Darin Adler wrote: > So, did we reach consensus that we should rename AtomicString to > AtomString? > > — Darin > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.w

Re: [webkit-dev] Watch out for std::optional's move constructor

On Tue, Dec 18, 2018 at 3:18 AM Geoffrey Garen wrote: > Again, the C++ standard does not say that moving from an object leaves the > object in an undefined state. > > The C++ standard does say: > > Objects of types defined in the C++ standard library may be moved from > (12.8). Move operations ma

Re: [webkit-dev] Removing support for CSS regions

This is a blocker for making the render tree more secure and for architectural progress there in general. The feature is extremely invasive and has design issues. I think the security benefits of removing it alone are worth taking a small regression risk. antti On Wed, Aug 2, 2017 at 10:00 AM,

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

This is a good change as long as we are just relaxing the rule rather than mandating ==. I think ! makes a lot of sense when testing for emptiness: if (!container.size()) ... if (!count) ... but == should be used for testing things where 0 is just another number, like indexes: if (index =

[webkit-dev] SVN trouble

Hi, Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some sort of SVN problem. Please hold commits until this is resolved. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-

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

Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a top-level namespace (even if it currently happens to live in the WebCore project)? #include would be more consistent with existing headers than . antti On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield wrote: > A

Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

On Mon, Dec 26, 2016 at 5:29 AM, Maciej Stachowiak wrote: > > ScopedChange(tachyonFlux, 2.0); > I wish there was a compiler warning against this. I have caused at least one bug by doing this exact thing. (a temporary gets deleted at the end of the expression) antti

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

I think the actual issue here was that std::chrono::duration can't represent infinite duration and some of our code has been hacking around that with std::chrono::duration::max(). Clock time + duration is not going to overflow if the duration is natural (a finite constant or produced by diffing tim

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

Does this mean we can start using (most) C++14 features? antti On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham wrote: > Hi Floks, > > We’ve finished updating the various Windows builds to VS2015. Full > regression tests are now completing on these new builds, and seem to be > comparable in t

Re: [webkit-dev] Filling the features.json files

On Wed, Apr 8, 2015 at 7:09 AM, Benjamin Poulain wrote: > Hi WebKit, > > The two features.json files are in the tree (WebCore/features.json and > JavaScriptCore/features.json). The style checker now checks the basic > structure of the files. > Could you also explain what these files are used for

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

Reusable Os Fitting Layer antti On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser wrote: > > On Mar 20, 2015, at 11:03 AM, Edward O'Connor wrote: > > >> This almost makes me want to suggest a jokey name for Platform. I can’t >> off the top of my head think of a good expansion of OMG, though.

Re: [webkit-dev] WebKit Meeting: Network Cache session

I added link to the slide to https://trac.webkit.org/wiki/March%202015%20Meeting . antti On Tue, Mar 17, 2015 at 8:28 AM, Adam Bergkvist wrote: > Hi > > Perhaps I should have posted this to the webkit-meeting list, but it > seems pretty dead. > > Anyways.. does anyone have any notes or slid

Re: [webkit-dev] WorkQueue for Windows?

vely, we can just make an implementation using std::thread). > > - Anders > > On Mar 6, 2015, at 10:46 AM, Antti Koivisto wrote: > > > Hi, > > > I'd like to start using WTF::WorkQueue abstraction in WebCore code. > However we are currently missing a Windows im

[webkit-dev] WorkQueue for Windows?

Hi, I'd like to start using WTF::WorkQueue abstraction in WebCore code. However we are currently missing a Windows implementation (WorkQueue used to be part of WK2). Anyone interested in making one? I assume it wouldn't be a difficult task for someone who knows the platform. antti ___

[webkit-dev] virtual and override

We have traditionally marked virtual overrides with the 'virtual' keyword for documentation purposes. Nowadays we also have the compiler checked 'override'. Using both at the same time seems redundant. Should we change the coding style so that exactly one of the 'virtual' and 'override' must be pr

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

I don't think this is really 32bit vs 64bit platform issue. The vast majority of 64bit systems our users have (that is iOS devices) can't use memory buffers sized anywhere near the 32bit limit even in theory. Also when using Vector auto-grow capabilities (which is really the point of using a vector

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

Or Vector and ByteBuffer. All these cases requiring very large buffers seem to be about untyped data. antti On Thu, Nov 20, 2014 at 9:40 PM, Filip Pizlo wrote: > That looks like a pretty good performance win. > > I'd advocate for SmallVector and Vector, then. > > -Filip > > > On Nov 20, 20

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

I agree with Phil, we should just use unsigned consistently. For very large memory allocations Vector is probably not the right type to use. antti On Wed, Nov 19, 2014 at 10:32 PM, Filip Pizlo wrote: > Whatever we do, the clients of Vector should be consistent about what type > they use. I'

Re: [webkit-dev] Networking process scope

On Mon, Nov 10, 2014 at 12:28 PM, youenn fablet wrote: > Hi, > > I looked at the Networking process recently and am wondering what is > in scope/out of scope of this process. > > Currently, the networking process is used to load resources from: > - URLs resolved using platform specific libraries

Re: [webkit-dev] Disk cache

On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos wrote: > El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió: > > Hello, > > > > > > I'm planning to add an experimental HTTP cache implementation to > > WebKit (https://bugs.webkit.org/

Re: [webkit-dev] Disk cache

tation. Just compiling it out requires no action. antti > > Alex > > On Oct 31, 2014, at 11:02 AM, Antti Koivisto wrote: > > Hello, > > I'm planning to add an experimental HTTP cache implementation to WebKit ( > https://bugs.webkit.org/show_bug.cgi?id=30322

[webkit-dev] Disk cache

Hello, I'm planning to add an experimental HTTP cache implementation to WebKit ( https://bugs.webkit.org/show_bug.cgi?id=30322). The main motivations are: - Improving performance by bringing the cache closer. For example we can serialize WebKit response objects directly instead of converting to/f

Re: [webkit-dev] Keep ResourceBuffer?

In that case remove away. Did I mention this code is confusing? antti On Thu, Oct 23, 2014 at 8:11 PM, Darin Adler wrote: > > > On Oct 23, 2014, at 10:13 AM, Antti Koivisto wrote: > > > > Note that ResourceBuffer is virtual and wraps a ShareableResou

Re: [webkit-dev] Keep ResourceBuffer?

Note that ResourceBuffer is virtual and wraps a ShareableResource on WebKit2 side. ShareableResource exists to do memory mapped IPC. The current factoring is confusing and cleaning this up is definitely a good idea. However it will require a bit more than just changing ResourceBuffers to SharedBuf

[webkit-dev] Please avoid inheriting concrete types over WebCore/WebKit boundary

Hi, To make callbacks from WebCore to WebKit(2) we have generally used approach where WebCore exports an abstract client interface which is then implemented on the WebKit side. More recently there has been some proliferation of a pattern where we inherit directly from a concrete WebCore type and

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

Yes, let's remove the flag. It is too easy to break the no-SVG build and the guards uglify the code. antti On Wed, Jan 29, 2014 at 2:13 AM, Sam Weinig wrote: > Hi Everyone, > > While we are discussing removing #ifdefs that everyone has enabled, I'd > like to propose removing ENABLE(SVG), a

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Mon, Jan 6, 2014 at 11:49 PM, Geoffrey Garen wrote: > > (2) ApplyStyleCommand.cpp: > > auto children = elementChildren(*dummySpanAncestor); > for (auto child = children.begin(), end = children.end(); child != > end; ++child) { > *if (isSpanWithoutAttributesOrUnstyledStyleSpan(&

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Fri, Jan 3, 2014 at 9:28 PM, Geoffrey Garen wrote: > I strongly object to varying coding style arbitrarily based on author or > project file. That's a recipe for an unreadable polyglot codebase. > I wasn't advocating a general coding style free-for-all. I imagine there could be valid subsyste

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

On Thu, Jan 2, 2014 at 11:12 PM, Geoffrey Garen wrote: > Hi folks. > > Recently, I’ve seen patches go by using the C++11 “auto” keyword. For > example, let me pick on Andreas: > > > > > > > +auto newRenderer = textNode.createTextRenderer(style); > > +

Re: [webkit-dev] The SrcN responsive images proposal

On Tue, Oct 22, 2013 at 11:50 PM, Tab Atkins Jr. wrote: > The parsing aspect isn't particularly new - parsing data-* attributes > presents the same problem. You just need to filter the list of > data-* attributes are not parsed. > attributes on the element to look for things with a src- prefix

Re: [webkit-dev] The SrcN responsive images proposal

On Sun, Oct 20, 2013 at 11:08 PM, Benjamin Poulain wrote: > On 10/20/13, 9:07 AM, Antti Koivisto wrote: > > Ignoring other aspects of this, the idea of making attribute name an > > enumeration is somewhat distasteful. It will require ugly special > > parsing. The platform ha

Re: [webkit-dev] The SrcN responsive images proposal

Ignoring other aspects of this, the idea of making attribute name an enumeration is somewhat distasteful. It will require ugly special parsing. The platform has plenty of attribute values that are lists already. antti On Sun, Oct 20, 2013 at 4:00 AM, Maciej Stachowiak wrote: > My initial im

Re: [webkit-dev] Proposal: remove style scoped

I think it is a feature that we may want to have sooner or later. We will probably want to change the implementation quite a bit though and removing the dead code for now makes sense. antti On Thu, Sep 26, 2013 at 3:42 PM, Benjamin Poulain wrote: > Dear WebKit, > > We have an unmaintained i

[webkit-dev] Removing DIALOG_ELEMENT for now

We current have an incomplete, unmaintained implementation of the HTML5 element in our code base. No one is building it as far as I can see and it has bit-rotted to the point it probably wouldn't work anyway. I think we should remove the code for now. It should be possible to come up with a nicer

Re: [webkit-dev] Ref counting questions

TreeShared is essentially an implementation detail of the DOM tree (the only other client besides Node is SVGElementInstance). It shouldn't be used for anything else. TreeShared keeps Nodes alive when they are part of a tree (have a parent node) even when they have zero refcount. This way nodes d

Re: [webkit-dev] We should delete ENABLE_SHADOW_DOM

I think it would be better to remove this code in controlled pieces along with all the underlying implementation (which is mostly not behind the flag) rather than removing it wholesale. It is good to understand what we are removing and that gets difficult if the API level (the only thing consistent

Re: [webkit-dev] What do we do with various Web component features?

I agree that we should remove most of the Shadow DOM related code (the portions supporting distribution especially). It is invasive, has significant architectural issues (including use of a confusing mutating iterator) and forces generic code many places where it would not be needed otherwise. It i

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

On Sat, Apr 13, 2013 at 8:26 AM, Filip Pizlo wrote: > > Also, you could do a libdispatch style, where there is no "lock" per se > but instead you just have queues that you put tasks on. I like that, too. > It's also formally equivalent to both locks and message queues, but much > more similar t

Re: [webkit-dev] StyleBuilder vs StyleResolver

On Fri, Apr 12, 2013 at 4:50 PM, Dirk Schulze wrote: > > On Apr 12, 2013, at 1:08 AM, Antti Koivisto wrote: > > > On Fri, Apr 12, 2013 at 7:36 AM, Dirk Schulze > wrote: > > Hi, > > > > The style of CSS properties is either set in StyleBuilder/CSSP

Re: [webkit-dev] StyleBuilder vs StyleResolver

On Fri, Apr 12, 2013 at 7:36 AM, Dirk Schulze wrote: > Hi, > > The style of CSS properties is either set in StyleBuilder/CSSProperty or > in StyleResolver (alias CSSStyleSelector). > > StyleResolver has a giant switch statement to handle all CSS property > values and set the style. It is the hist

Re: [webkit-dev] AncestorChainWalker substance and style thoughts

The purpose of the NodeTraversal refactoring was simply to move the existing traversal functions off the (rather bloated) Node and add Element specific functions. I think longer term iterators are the way to go as they allow decoupling our internal document tree data structures from the DOM API. T

Re: [webkit-dev] Opera and WebKit

Welcome! antti On Wed, Feb 13, 2013 at 10: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

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

When loading web pages we are very frequently in a situation where we already have the source data (HTML text here but the same applies to preloaded Javascript, CSS, images, ...) and know we are likely to need it in soon, but can't actually utilize it for indeterminate time. This happens because pe

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. wrote: > No, it's just a refactoring on the CSS side, so we don't have to > repeat a bunch of stuff every time we have an at-rule that contains > other rules. It just makes the WebIDL easier and less error-prone. > It seems bit strange to add a web

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

We already have internal type corresponding to the new CSSGroupingRule, StyleRuleBlock. Technically refactoring the CSSOM like this would be fairly trivial. It is not clear to me what value this new type adds though. In JS you don't really care if types have a common base as long as they share sim

Re: [webkit-dev] Prefix naming scheme for DOM-exposed functions

ds, > Maciej > > On Dec 7, 2012, at 9:27 AM, Darin Adler wrote: > > > Hi folks. > > > > Many of the APIs designed for use in the DOM are not efficient for use > inside WebKit, or have designs that are better for JavaScript than for C++. > Antti Koivisto and I have

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Wed, Oct 31, 2012 at 12:05 AM, Alexey Proskuryakov wrote: > This will mean that cache is always almost empty, and all resources in it > are extremely fresh. I don't know if this would provide substantial > additional test coverage over cleaning the cache all the time, or just > completely disa

Re: [webkit-dev] On returning mutable pointers from const methods

I don't think the original proposal was meant to apply to the basic container types. Would this be a sensible rule to adopt for WebCore only for example? Like all our "blanket rules", this one should be ignored when it doesn't make sense. If that kind of cases are expected to be very rare then the

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

We could clear the cache between tests but run each test twice in a row. Second run will then happen with deterministically pre-populated cache. That would both make things more predictable and improve our test coverage for cached cases. Unfortunately it would also slow down testing significantly,

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Fri, Oct 26, 2012 at 6:09 PM, Ami Fischman wrote: > The reality is that this "test coverage" today shows up as flakiness and > so is ignored anyway, meaning we don't actually have useful coverage here. > Even when flakiness is investigated, the "fix" is to cache-bust using > unique URL params

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

On Wed, Aug 8, 2012 at 9:54 PM, Eric U wrote: > On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov > wrote: > > I can see some downsides to emptying the cache before each test: > > > > - we won't be getting any test coverage for cache behavior when it hits > > non-trivial size; > > Then let's

Re: [webkit-dev] On returning mutable pointers from const methods

On Thu, Oct 25, 2012 at 1:48 PM, Andreas Kling wrote: > > So, I propose that we allow only these two signature formats for raw > pointers: > > - const Foo* foo() const; > - Foo* foo(); > I think this would be an excellent rule to adopt for new code. The mutable/immutable state pattern is a power

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth wrote: > This is interesting data, but it seems to be related to whether we > should make the MemoryCache content addressable rather than whether we > should use shared memory to back the MemoryCache when there are > multiple WebProcesses. > It is rele

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak wrote: > One preliminary finding of ours is that different web pages fairly often > load identical resource bodies from different URLs. We expect possible > benefits from sharing the body data of resources in memory even if we > cannot share the U

Re: [webkit-dev] Eliminate potential null pointer dereference?

Sat, Apr 21, 2012 at 8:13 AM, John Yani wrote: > 2316if (selector->relation() != CSSSelector::SubSelector) > 2317break; > 2318selector = selector->tagHistory(); > 2319}; > > Now selector is null and we are trying to call tagHistory(): > This is not

Re: [webkit-dev] How to use ASSERT_NO_EXCEPTION

On Thu, Dec 15, 2011 at 8:36 AM, Darin Adler wrote: >ExceptionCode ec; >appendChild(newChild, ec); >ASSERT(!ec); > Often code like this indicates misuse of DOM API functions for internal purposes. This is inefficient (due to exception related checking and other spec mandated behavior

Re: [webkit-dev] Using C++ constant local variables in WebKit

On Thu, Dec 1, 2011 at 4:26 AM, Ojan Vafai wrote: > I don't mind using const in some cases, but I share Darin's concern of > littering the code with consts. I'd prefer that > we come up with a fairly conservative guideline about when to use it. I'm > not sure what that would look like. We could s

Re: [webkit-dev] old-run-webkit-tests is officially deprecated.

On Fri, Oct 28, 2011 at 1:00 AM, Eric Seidel wrote: > > If you're still using old-run-webkit-tests for your work, I would > *love* to know and fix any issues you may have with NRWT. > > The lack of locale independence is a showstopper for me, https://bugs.webkit.org/show_bug.cgi?id=68691. ant

Re: [webkit-dev] Compile-time assertions for object sizes

On Thu, Sep 29, 2011 at 9:40 PM, Andreas Kling wrote: > One idea is to add a file that would only be built on (for example) 64-bit > Mac and then at least that bot would break if an object changes size. That's > obviously not ideal though. > I like that approach as it allows you to explicitly as

Re: [webkit-dev] Implementing

On Fri, Sep 9, 2011 at 12:28 AM, Roland Steiner wrote: > > ad 3.) Implementation of scoped selector matching works as follows: > > .) scoped style sheet rules are contained in a separate map element address> -> RuleSet > .) add a field to ParentStackFrame that identifies the > closest ParentStack

Re: [webkit-dev] Preload Scanner in WebKit

On Fri, Feb 11, 2011 at 9:11 AM, Adam Barth wrote: > We run the preload scanner when the regular parser is blocked on the > network.  CSS and other sub-resources don't block the main parser > whereas scripts do. If the main parser encounters an script tag (including inline scripts) it will also b

Re: [webkit-dev] beforeload & link (esp rel prefetch)

2011/1/13 Darin Fisher : > Supporting the Link header enables web servers to inject tags without > modifying the document, which can be useful, especially for intermediaries. That sounds like a great reason not to support this feature. Why would we want to make the web more unpredictable and hard

Re: [webkit-dev] HTML5 & Web Links (RFC 5988)

Even for prefetching this seem rather worthless as it won't allow prefetching start significantly earlier over the resources specified in the document source. There is also (based on the experience in similar things) a high chance that whatever is listed in the Link header won't match what the doc

Re: [webkit-dev] Tightening up smart pointer usage rules

Is the plan also to banish the std::auto_ptr? It seems pointless and confusing to allow both the OwnPtr and the auto_ptr. antti (who wants PwnPtr too) On Mon, Jun 28, 2010 at 11:39 PM, Darin Adler wrote: > Hi folks. > > I’d like to use our smart pointers more consistently to decrease the chan

Re: [webkit-dev] HTML5 tokenizer landing soon

Cool. Are you going to switch the PreloadScanner to the new tokenizer too? antti On Mon, Jun 14, 2010 at 8:21 AM, Adam Barth wrote: > People of WebKit, > > As mentioned recently on webkit-dev, Eric, Tonyg, and I have been > working on implementing the HTML5 parsing algorithm in WebKit: > > ht

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt wrote: > I really don't think hit testing needs to be modified to get what you want.   > You can do a scattershot sampling using multiple candidate points within the > rect and apply whatever heuristics you want to choose a node.  I'm also not > conv

Re: [webkit-dev] PreloadScanner aggressiveness

On Fri, Jan 8, 2010 at 3:00 AM, Mike Belshe wrote: Nice testing! But for HTTP; the key seems to the pre-rendering-ready escape hatch in > DocLoader::preload. Removing this gives me most all of the benefit. The > comment says it pretty clearly: "Don't preload images or body resources > before

Re: [webkit-dev] WebKit runtime image compression

On Sun, Dec 14, 2008 at 9:12 AM, Paul Pedriana wrote: > For a lot of web pages, images are the primary source of memory usage. > These images seem to be typically stored as RGB or ARGB data in the > BitmapImage class. It seems to me that applications that wish or need to > save runtime memory cou

Re: [webkit-dev] http cache support - rfc2616

WebKit implements significant parts of RFC 2616 caching logic for it's internal memory cache and will implement more. See https://bugs.webkit.org/show_bug.cgi?id=17998 for details. antti 2008/11/15 Darin Fisher <[EMAIL PROTECTED]>: > The http caching logic for chromium lives here: > http://sr

[webkit-dev] Windows build now requires QuickTime SDK

Hi, I just checked in the timed media support ( and ) for Windows. This means that Windows build now depends on the QuickTime SDK which can be downloaded from here: http://developer.apple.com/quicktime/download/ Note that QuickTime itself is not required to build, just the SDK. antti __

Re: [webkit-dev] Re: [webkit-changes] [24907] trunk

19:04 , Mitz Pettel wrote: > > > If I understood the bug fix and the test correctly, then a test > > like this might work: do 5000 iterations (instead of 3) and > > look at the ratio between the time the first 500 and last 500 > > iterations take. > > > >

Re: [webkit-dev] Re: [webkit-changes] [24907] trunk

On 8/7/07, Mitz Pettel <[EMAIL PROTECTED]> wrote: > Hi Antti, > > I do not understand the purpose of the test and how it is supposed to > serve that purpose (two of the reasons that I am baffled are that it > is my understanding that there are facilities to track performance > within fractions of a

Re: [webkit-dev] Re: [webkit-changes] [24907] trunk

On 8/7/07, Mitz Pettel <[EMAIL PROTECTED]> wrote: > On Aug 7, 2007, at 2:15 PM, [EMAIL PROTECTED] wrote: > - added performance test. With debug build on MBP this takes about 1.5s to > run. > > * fast/block/basic/stress-shallow-nested-expected.txt: Added. > * fast/block/basic/stress-shallow-neste