Re: [webkit-dev] On IDL files, events and writing DOM bindings
On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler wrote: > The bindings do not expose events directly, thus the IDL files don’t show the > events. The IDL files only show functions and attributes on the various > objects. Events are neither functions nor attributes. For the bindings I am > familiar with, there is no list of events and so nothing to be generated from > the IDL. The event names, as with tag names, are string constants. Interesting. For the GObject bindings I'm actually exposing the events directly. Eg, you are able to do: g_signal_connect(image, "click-event", callback, NULL); and callback will be called when the image is clicked, with an Event object as a parameter. The wrapping for the Events comes from the IDL file that exists for each type of event (Event.idl and its subclasses). > > You mentioned the ended attribute in HTMLMediaElement. This is a boolean > attribute, and not an event. It happens to have the same name as an event, > but there is no direct connection between the event and the attribute. Right, I was aware of the distinction. Maybe I failed to express myself properly here, my only doubt was really why there was no reference to the event in any IDL file, which has already been answered. > > You asked: > >> is it possible to know which Events are defined for each class just from the >> IDL files > > Events are not defined for classes. The engine can send events to any > EventTarget, and the IDL files and the bindings have nothing to say about > which events the engine will send to which objects. Right. I think the only solution that makes sense for the bindings (at least the GObject ones, where you *do* have to tell a class which kind of events/signals it can receive or emit), is to define every possible type of event in the most basic class that is an EventTarget (say, Node). In this way you'll be able to connect to the event delivery signals or manually dispatch and event to any node or any of its subclasses, both perfectly valid things to do. Cheers, Xan > > -- Darin > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On IDL files, events and writing DOM bindings
The bindings do not expose events directly, thus the IDL files don’t show the events. The IDL files only show functions and attributes on the various objects. Events are neither functions nor attributes. For the bindings I am familiar with, there is no list of events and so nothing to be generated from the IDL. The event names, as with tag names, are string constants. You mentioned the ended attribute in HTMLMediaElement. This is a boolean attribute, and not an event. It happens to have the same name as an event, but there is no direct connection between the event and the attribute. You asked: > is it possible to know which Events are defined for each class just from the > IDL files Events are not defined for classes. The engine can send events to any EventTarget, and the IDL files and the bindings have nothing to say about which events the engine will send to which objects. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About fixing "old" layout bugs
Hi, developers, I'd really like my patches to be reviewed and landed. Could any reviewer/commiter help me? The normal review/commit queue mechanisms aren't suitable for the the patches because the layout-tests in them are almost always out-dated. Thanks, Xianzhu 2010/8/1 Xianzhu Wang > Hi, > > Now the status of the three old bugs are: > * white space preceding ( > https://bugs.webkit.org/show_bug.cgi?id=37261): New patches uploaded > * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413): New > patches uploaded > * line breaking around some punctuations ( > https://bugs.webkit.org/show_bug.cgi?id=37698): Fixed > > For the bug, I still split the patch into following parts to ease > review: > 1. A patch containing only the changed code and the added test; > 2. A patch containing all affected text-only layout tests that differ only > about trailing spaces; > 3. A patch containing all affected DRT layout tests that differ only about > trailing spaces of text rendering nodes; > 4. A patch containing other layout tests that have been manually adjusted; > 5. A patch containing changed Skipped files of other platforms. > > The above 2 and 3 were auto generated by scripts. And instead of > rebaslining tests of other platforms, I simply (temporarily) added the > affected tests into Skipped files. I used the similar method to generate the > patch for the second bug but didn't split it because the patch is much > smaller. The patches also don't contain pixel tests to reduce the scope and > size. > > Because of rapid changes of affected layout tests, the patches had already > been out-dated even before I uploaded them. It seems to me that the normal > process of review queue and commit queue doesn't work for such patches. > Would any committer please help review and maybe commit the patches? > > Thanks, > Xianzhu > > 2010/6/2 Xianzhu Wang > >> Hi, >> >> I'm new to webkit development, and I'd like to hear opinions about the >> problems I met. >> >> Now I'm trying to fix some "old" layout bugs, for example: >>* white space preceding ( >> https://bugs.webkit.org/show_bug.cgi?id=37261) >> * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) >> * line breaking around some punctuations ( >> https://bugs.webkit.org/show_bug.cgi?id=37698) >> >> Some people have warned me about the difficulty of fixing these bugs, and >> now I have realized it. Fixing the bugs themselves is not very difficult, >> for example, only 2 functional lines change can fix the first bug. However, >> the change will break more than 4000 existing layout tests mostly because >> trailing spaces preceding s in current expectations of the tests (for >> example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests >> (for now on mac only), and the patch is about 6MB (Sorry I overlooked the >> "Bigfile" option when I submitted the patch, so I split it into 4 parts). >> >> My questions are: >> >> 1. The bugs violate the standards and cause some site compatibility >> issues. However, because the bugs are old, some web developers might treat >> them as features and depend on them, so fixing them might break some >> existing pages. Is there any existing policy about this problem? Are these >> bugs worth fixing? >> >> 2. What's the best practice to deal with a patche containing many updated >> layout test expectations? Is there a good way to rebaseline the effected >> tests on all platforms? >> >> Thanks, >> Xianzhu >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how is expected.txt file generating while test layouttests
Please try 'run-layout-tests --help' to see the command line options of run-layout-tests script. The '--new-test-results' and '--reset-results' options will help you generate the expected file. You may also want to read http://trac.webkit.org/wiki/CreatingLayoutTests to learn the different types of layout tests. 2010/8/10 KrishnaMurthy Naidu > how is expected.txt file generating while test layouttests > > On Tue, Aug 10, 2010 at 4:07 PM, KrishnaMurthy Naidu < > krishnamurthyna...@gmail.com> wrote: > >> >> > > ___ > 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] Canvas performance and memory usage
On Aug 10, 2010, at 2:49 PM, David Hyatt wrote: > Yeah, I think an even better way of abstracting it might be to make > ImageBuffer:drawIntoContext(GraphicsContext*, ...). I think that would be > simpler for people implementing something special. If we did that, then the > image() accessor on ImageBuffer could probably just always be a deep copy (or > copy-on-write). > > Getting rid of the graphicsContext->drawImage(imageBuffer->image()) > pattern would definitely be good though. > > I'm just really curious about the performance of canvas and whether it's > better to have slower get/PutImageData or faster rendering otherwise. It > all comes down to how people are using canvas. I suspect that > get/PutImageData are really really popular. I implemented ImageBuffer::drawIntoContext on Mac, and I switched the implementation of ImageBuffer to dynamically swap to a CGLayer (throwing away the bitmap context) if it can do so. Preliminary tests look very very good. This benchmark for example: http://themaninblue.com/experiment/AnimationBenchmark/canvas/ Jumped from 37fps to 85fps. I'll need to see what happens with intensive get/PutImageData examples though before I declare victory, but it definitely looks like slowing down get/PutImageData is worth it if we can get performance gains like this! dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
Eric Seidel írta: Chromium skips it (and if I remember correctly, they commissioned it?) Why do we want to be running these 6000 tests and slowing down our builds. I was talking with jamesr, and he seemed to think it adds little value to run it every time? (It was supposedly written as more of a development tool for V8?) But maybe I'm missing something? Sputnik tests are very fast. All test cases (15642) run in 394s, and 5468 Sputnik tests run in 41s on Qt buildbot, it takes only 10% of the testing time. Alexey Proskuryakov írta: > One possible way to speed up Sputnik tests would be to run them as part > of run-javascriptcore-tests, avoiding web page overhead. Someone proficient > in scripting languages just needs to improve run-javascriptcore-tests to the > point when it can do that. 1127 JavaScriptCore tests (run-javasriptcore-tests) run in 11s, 5468 Sputnik tests run in 41s on Qt buildbot. I don't think we can speed up Sputnik tests significantly. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
10.08.2010, в 14:00, Adam Barth написал(а): > A better long-term fix might be to finish new-run-webkit-tests so we > can run the tests in parallel. One reason to move the tests to run-javascriptcore-tests is that people working on JS run these more often (sometimes not even building WebCore until ready to submit a patch). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
On Tue, Aug 10, 2010 at 12:16 PM, Alexey Proskuryakov wrote: > 10.08.2010, в 11:51, Eric Seidel написал(а): >> Why do we want to be running these 6000 tests and slowing down our >> builds. I was talking with jamesr, and he seemed to think it adds >> little value to run it every time? (It was supposedly written as more >> of a development tool for V8?) But maybe I'm missing something? > > Just like any test suite, it catches regressions. We saw that it was > effective when we introduced certain JSC regressions that it could have > prevented. Since some of the errors Sputnik catches are platform specific (32 > bit vs. 64 bit, JIT vs. interpreter etc), it is particularly important to > have it on build bots. > > Some subtests are less interesting (e.g. many Unicode tests basically check > ICU behavior), so we have the slowest of those disabled already. > > One possible way to speed up Sputnik tests would be to run them as part of > run-javascriptcore-tests, avoiding web page overhead. Someone proficient in > scripting languages just needs to improve run-javascriptcore-tests to the > point when it can do that. FWIW, a Sputnik test caught an error in the new HTML parser (related to the interaction between \r\n collapsing and line numbering in JavaScript) that otherwise might have gotten through. A better long-term fix might be to finish new-run-webkit-tests so we can run the tests in parallel. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
Nope, it's from Chromium: http://blog.chromium.org/2009/06/launching-sputnik-into-orbit.html http://blog.chromium.org/2010/03/does-your-browser-behave.html Mihai On Tue, Aug 10, 2010 at 1:30 PM, Dirk Pranke wrote: > I thought Sputnik came from Microsoft? > > -- Dirk > > On Tue, Aug 10, 2010 at 11:51 AM, Eric Seidel wrote: > > Chromium skips it (and if I remember correctly, they commissioned it?) > > > > Why do we want to be running these 6000 tests and slowing down our > > builds. I was talking with jamesr, and he seemed to think it adds > > little value to run it every time? (It was supposedly written as more > > of a development tool for V8?) But maybe I'm missing something? > > > > -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] Why are we running Sputnik?
I thought Sputnik came from Microsoft? -- Dirk On Tue, Aug 10, 2010 at 11:51 AM, Eric Seidel wrote: > Chromium skips it (and if I remember correctly, they commissioned it?) > > Why do we want to be running these 6000 tests and slowing down our > builds. I was talking with jamesr, and he seemed to think it adds > little value to run it every time? (It was supposedly written as more > of a development tool for V8?) But maybe I'm missing something? > > -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
Re: [webkit-dev] Canvas performance and memory usage
On Aug 10, 2010, at 2:38 PM, Stephen White wrote: > On Mon, Aug 9, 2010 at 6:17 PM, David Hyatt wrote: > There are other cases as well where you want a copy. Patterns are another > example. For example you can create a pattern from another canvas, and I > don't think it's supposed to be live if that other canvas later changes. > There are examples in SVG as well where patterns are used and I am pretty > sure a copy is the desired behavior. > > I don't think it's as simple as saying "image()" should never copy. > > I spent some time thinking about this from a CG perspective, and I couldn't > really come up with a good solution. We use a bitmap context for efficient > pixel access for get/putImageData. Any platform that wants these functions > to be efficient has to keep the pixels easily obtainable. This means, for > example, that we can't produce a live image using CGLayers. Looking at Qt, > the only current platform to return a "live" image to canvas for rendering, > it looks like they made this tradeoff, i.e., it looks to me like > get/putImageData are slower than other platforms. (The get is having to call > toImage() on a pixmap and then has to convert to obtain a good representation > of the data for a QImage). The put has to render the changes into the pixmap. > > I tried renaming the two methods (image() and imageForRendering()) to > copiedImage and liveImage, and ended up with about an 80/20 split at the call > sites between the two. It looked really ugly to me, since in nearly every > case the "liveImage" was just being used to paint the current contents of the > ImageBuffer, i.e., it was just being passed to drawImage. The copiedImage > was typically passed to somebody who needed to retain it for later rendering, > e.g., a pattern. > > So to sum up, the call sites want two things: > > (1) To render the current contents of the image buffer efficiently. > > Would it make sense to add a GraphicsContext::drawImageBuffer(ImageBuffer*, > ...) call for this use case? Then the details of how the image is actually > extracted (or not) could be kept down in the platform-specific layers. I > don't know if this entirely helps the problem under discussion, but I ran > into it in another context and it seemed like it would be useful. Yeah, I think an even better way of abstracting it might be to make ImageBuffer:drawIntoContext(GraphicsContext*, ...). I think that would be simpler for people implementing something special. If we did that, then the image() accessor on ImageBuffer could probably just always be a deep copy (or copy-on-write). Getting rid of the graphicsContext->drawImage(imageBuffer->image()) pattern would definitely be good though. I'm just really curious about the performance of canvas and whether it's better to have slower get/PutImageData or faster rendering otherwise. It all comes down to how people are using canvas. I suspect that get/PutImageData are really really popular. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
On Mon, Aug 9, 2010 at 6:17 PM, David Hyatt wrote: > There are other cases as well where you want a copy. Patterns are another > example. For example you can create a pattern from another canvas, and I > don't think it's supposed to be live if that other canvas later changes. > There are examples in SVG as well where patterns are used and I am pretty > sure a copy is the desired behavior. > > I don't think it's as simple as saying "image()" should never copy. > > I spent some time thinking about this from a CG perspective, and I couldn't > really come up with a good solution. We use a bitmap context for efficient > pixel access for get/putImageData. Any platform that wants these functions > to be efficient has to keep the pixels easily obtainable. This means, for > example, that we can't produce a live image using CGLayers. Looking at Qt, > the only current platform to return a "live" image to canvas for rendering, > it looks like they made this tradeoff, i.e., it looks to me like > get/putImageData are slower than other platforms. (The get is having to > call toImage() on a pixmap and then has to convert to obtain a good > representation of the data for a QImage). The put has to render the changes > into the pixmap. > > I tried renaming the two methods (image() and imageForRendering()) to > copiedImage and liveImage, and ended up with about an 80/20 split at the > call sites between the two. It looked really ugly to me, since in nearly > every case the "liveImage" was just being used to paint the current contents > of the ImageBuffer, i.e., it was just being passed to drawImage. The > copiedImage was typically passed to somebody who needed to retain it for > later rendering, e.g., a pattern. > > So to sum up, the call sites want two things: > > (1) To render the current contents of the image buffer efficiently. > Would it make sense to add a GraphicsContext::drawImageBuffer(ImageBuffer*, ...) call for this use case? Then the details of how the image is actually extracted (or not) could be kept down in the platform-specific layers. I don't know if this entirely helps the problem under discussion, but I ran into it in another context and it seemed like it would be useful. Stephen (2) To obtain a copied image that is independent of the image buffer that is > typically retained by someone else. > > And the current implementations of image()/imageForRendering() do three > things: > > (1) Make a copy of the image buffer into an Image (e.g., Skia). > (2) Make an Image that is a live representation of the Image buffer > contents (e.g., Qt using imageForRendering). > (3) Make a copy-on-write image wrapper (e.g., CG). > > Assuming the copy-on-write stuff in CG is actually working (and I suspect > that it is), then it's actually a pretty good solution. You don't copy to > do throwaway drawing. Pixel access is efficient using get/PutImageData. > There's no need to distinguish between copied images vs. live, with the > caveat that the cached image has to be cleared (only an issue for canvas, > since nobody else does continual drawing to ImageBuffers). > > Anyway I'm open to suggestions here. :) > > As for removing the ImageBuffer completely, I don't think you can get away > with that. The canvas buffer's size does not necessarily match the size > into which it is drawn. You need to be able to get to the image pixels of a > possibly larger (or smaller) buffer. You also have to be able to draw the > contents of one canvas into another canvas, so you have to be able to treat > the canvas as an image. Again that means being able to get to the contents > of the canvas itself as a separate buffer/image. > > dave > (hy...@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
Re: [webkit-dev] On IDL files, events and writing DOM bindings
On Tue, Aug 10, 2010 at 8:59 PM, Xan Lopez wrote: > On Tue, Aug 10, 2010 at 8:32 PM, Adam Barth wrote: >> I'm not sure I understand your question. Every event can happen on >> every EventTarget. > > I mean that an HTMLMediaElement will naturally emit an 'ended' Event > in some situations, but an HTMLImageElement won't. I see no obvious > way of knowing that (or other similar facts) from the IDL files. Answering myself after the trip home, I take it that the answer is basically that the information I want is not useful when writing the bindings (since as you say any event can in theory happen in any target, be it naturally or synthetically), and that I should simply collect all event classes defined and add them as "this class might possible receive this event" where appropriate in the class hierarchy? Another question would be whether we maintain the canonical list somewhere (perhaps in DOMWindow.idl ) or if we are supposed to construct it ourselves manually. > > Xan > >> >> Adam >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
10.08.2010, в 11:51, Eric Seidel написал(а): > Why do we want to be running these 6000 tests and slowing down our > builds. I was talking with jamesr, and he seemed to think it adds > little value to run it every time? (It was supposedly written as more > of a development tool for V8?) But maybe I'm missing something? Just like any test suite, it catches regressions. We saw that it was effective when we introduced certain JSC regressions that it could have prevented. Since some of the errors Sputnik catches are platform specific (32 bit vs. 64 bit, JIT vs. interpreter etc), it is particularly important to have it on build bots. Some subtests are less interesting (e.g. many Unicode tests basically check ICU behavior), so we have the slowest of those disabled already. One possible way to speed up Sputnik tests would be to run them as part of run-javascriptcore-tests, avoiding web page overhead. Someone proficient in scripting languages just needs to improve run-javascriptcore-tests to the point when it can do that. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On IDL files, events and writing DOM bindings
On Tue, Aug 10, 2010 at 8:32 PM, Adam Barth wrote: > I'm not sure I understand your question. Every event can happen on > every EventTarget. I mean that an HTMLMediaElement will naturally emit an 'ended' Event in some situations, but an HTMLImageElement won't. I see no obvious way of knowing that (or other similar facts) from the IDL files. Xan > > Adam > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Why are we running Sputnik?
Chromium skips it (and if I remember correctly, they commissioned it?) Why do we want to be running these 6000 tests and slowing down our builds. I was talking with jamesr, and he seemed to think it adds little value to run it every time? (It was supposedly written as more of a development tool for V8?) But maybe I'm missing something? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On IDL files, events and writing DOM bindings
On Tue, Aug 10, 2010 at 11:26 AM, Xan Lopez wrote: > as we all know, when writing DOM bindings on top of WebKit we are > supposed to use the IDL files it ships as the source of the structure > and behavior of the DOM. At first I had assumed that to figure out > which events apply to each type/class it was OK to see which > EventListeners were defined, and go on from there (ie, if there's a > onabort defined in Element.idl, Element has an 'abort' Event defined). > This, though, seems to be not completely accurate in many cases, and > in others it's downright absent: > > Media elements are defined to have, for example, an 'ended' event, > emitted when the playback has finished. The matching attribute is > defined in HTMLMediaElement.idl, but the event listener for it is in > DOMWindow.idl. This was done here > https://bugs.webkit.org/show_bug.cgi?id=26100 completely on purpose, > so I assume this is how it's meant to work. > > So the question is: is it possible to know which Events are defined > for each class just from the IDL files, or are we expected to inject > part of this knowledge ourselves when writing the bindings? I'm not sure I understand your question. Every event can happen on every EventTarget. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
On Mon, Aug 9, 2010 at 9:28 PM, Geoffrey Garen wrote:
>> As Ojan indicated,
>> the use cases for DOM Mutation events are extremely limited and to me,
>> most of them feel like we should be solving them differently anyway.
>
> This is the question I'm most interested in.
>
> You say the use cases are limited. How do you know? Are you speaking about
> when you would use mutation events, or do you have data on when authors use
> them on the web? Is one of the limited use cases on a high traffic web site?
I don't have any data -- just my own intuition at this point.
> Does Mozilla share your opinion? Do others?
It would be awesome if Mozilla shared my opinion. We should hook up
with them and have a beer-laden discussion. I heard they like beer.
> I have the same questions about Ojan's claim.
Good! Let's try to answer them together.
For example, in every one of the use cases listed in Wiki, the
mutation events are just workarounds for deficiencies of today's Web.
Just take a gander:
Keeping updated statistics of page DOM -- these are things that a
browser should do. If we have a JS developer who writes a selector
engine (for justifiable reasons, of course) -- we as browser
developers have failed our users. We should be providing this
functionality out-of-the-box.
Widgetify dynamically created markup -- this cries for a decent
behavior attachment construct.
Poor man's XBL -- dude, the title says it all.
For browser extensions (not for web page authors) -- again, we should
be solving this with allowing XBL-like behavior attachment
capabilities and certainly not mutation events.
>> However, with the introduction of extensions into Chromium and Safari,
>> DOM Mutation events experience a sort of renaissance, being used to
>> sense the DOM changes to re-apply modifications (rewrite URLs, text,
>> etc.).
>
> This is an interesting data point.
>
> If we just need an event for an extension to reapply its magic to new
> content, a global, asynchronous DOMContentChanged event might work.
Yes. After extensions launched, I managed to get into fixing some of
the mysterious isolated-world-related crashes and was amazed to find
out how many extensions use this anti-pattern:
document.body.addEventListener("DOMNodeInserted", function() {
process() }, false);
>
> If we introduced an API like that, and gave extensions developers time to
> update, we could probably remove mutation events without harming extensions.
>
> I'd like to give the same kind of consideration to data about web content.
>
>> With this in mind, I think we should do #1 and #3, then #2 after some
>> time and loud over-communication (like Inspector warnings, blog posts,
>> billboards on Hwy 101 etc.).
>
> I'm not sure this plan makes sense. If we plan to do #2 (remove mutation
> events), #1 (make mutation events asynchronous) may not be worth the effort.
You're probably right.
> Also, I'm not sure that the best time to remove mutation events depends on
> what we do (communication) -- it most likely depends on what others do
> (changing web content not to use mutation events, or not).
>
> On the other hand, I would be willing to chip in to see "Friends Don't Let
> Friends Use DOM Mutation Events" in big letters over highway 101 :).
Yes! Yes! Big Comic Sans letters! :)
> Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] On IDL files, events and writing DOM bindings
Hi, as we all know, when writing DOM bindings on top of WebKit we are supposed to use the IDL files it ships as the source of the structure and behavior of the DOM. At first I had assumed that to figure out which events apply to each type/class it was OK to see which EventListeners were defined, and go on from there (ie, if there's a onabort defined in Element.idl, Element has an 'abort' Event defined). This, though, seems to be not completely accurate in many cases, and in others it's downright absent: Media elements are defined to have, for example, an 'ended' event, emitted when the playback has finished. The matching attribute is defined in HTMLMediaElement.idl, but the event listener for it is in DOMWindow.idl. This was done here https://bugs.webkit.org/show_bug.cgi?id=26100 completely on purpose, so I assume this is how it's meant to work. So the question is: is it possible to know which Events are defined for each class just from the IDL files, or are we expected to inject part of this knowledge ourselves when writing the bindings? Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
> Anyway I'm open to suggestions here. :) I came to very similar conclusions that you did and posted a WIP patch here: https://bugs.webkit.org/show_bug.cgi?id=43507 . I'm not sure if it is ready or good, but in particular removing the caching behavior for ::image() led to a lot of unexpected changes. Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] strategy for evaluating performance issues related to memory.
> From: lmeye...@eecs.berkeley.edu > Date: Tue, 22 Jun 2010 17:51:22 -0700 > To: webkit-dev@lists.webkit.org > Subject: Re: [webkit-dev] strategy for evaluating performance issues > related to memory. > > I've been doing some memory benchmarking recently (my current interest > is layout but am also poking at nearby processes). Generally, data > representation seems hard to usefully tweak in a non-invasive way as > it's pretty good while being legible (e.g., bit packing), but access > patterns (and random allocations) already seem questionable. This fwiw, in some unrelated apps, I actually found that doing seemingly expensive things and doing them with no regard to efficiency, like a sort on a large data set, can quickly pay for itself in later cache hits. In my case anyway it stopped VM thrashing- the original app continued to act as if data was random but the bash sort result I piped into it didn't require it to thrash anymore. This turned an impractical runtime into something quite usable. Concise, regular, and local are always better but they may be discarded due to some initial time to order or compress data or re-order code. > especially hurts netbooks/mobiles, but I'm seeing high missrates on my > penryn MacBook Pro and it likely surfaces in the new macbook pros with > their big L3 but much smaller L2 (though I can't get perf counters w/ > Shark to work there). > > A high-impact and less-painful first step might be to target CSS > selectors & default render style creation: > > -- buffer calls at the end of the > parseToken()->insertNode()->attach()->createRender()->styleForRenderer()->styleForElement() > pipeline > -- once enough are in (or there is nothing else to do), > perform matchRules/matchUARules calls: > -- in tiles > -- ... and in parallel > -- ... and with software prefetching > -- resume rest of createRender calls (similar tricks may apply, still > not sure) > > A different form of this is now in the firefox mainline but there's > room to do more using the above (and I suspect with a bit less > implementation complexity). > > Anyways, this seems inappropriate for this list, but if anybody would > be interested in continuing the discussion, you have my email. Also, if > there are any resources describing memory layout / instantiation / etc. > patterns and how/why recomputation/memoization are traded off, it would > be a nice bootstrap: I've been essentially walking > through http://webkit.org/blog/114/webcore-rendering-i-the-basics/, Cool, sorry I just got around to reading this the other day :) Where do you suggest discussing this? Informal ad hoc mail group? If you are forming a list obviously add me to it. I guess everytime I see coding style issues come up, I keep thinking about structured comments ( annotations related to this isue. That is, sure you can keep profiling it and taking tools to it, and empirical data is always needed, but I keep thinking that generally each contributor knows how he calculates the size of each memory allocation and generally how that blob will be read or written. If there was a concise way to desribe this to others that may help. Thoughts? I'd like to grep the code for some comment about memory needs and see if patterns emerge or see if it suggests to me some place to dig in. To hijack the thread and wander around in idea space, are there accepted terms like "todo" or "kluge" to put into comments so they are easily found or do these things normally end up in bug tracker or issue list? > > Regards, > > - Leo > > > > > On Jun 21, 2010, at 9:05 PM, Maciej Stachowiak wrote: > > > On Jun 21, 2010, at 11:59 AM, Mike Marchywka wrote: > > > I was hardly worried about who does anything as much as what would make > sense to do. I have interest, motivation, > and multiple copies of the code but not a lot of time to waste of bad > approaches. There was a prior discussion > about coding conventions that should be applicable even to those > contemplating a contribution of just browsing > the code, I fail to see how this discussion is less relevant to current > and possible future development concerns. > > If there was some piece of this or a related effort that could be aided > by certain code features that > would seem to be of interest to everyone and it isn't clear which > people would have important thoughts > to contribute ( or I would take it some other place). > > So I take it that now you just have factories and smart pointers and > just make stuff and have it > allocated wherever without further thought? I guess I could do some > profiling my self and empirically > find problems and just assume that no one has specific comments on > suspects or things they have observed > as possible problems. > > In my experience with performance work, and specifically in the context > of WebKit, I believe the following are useful approaches to reducing > memory use: > > 1) Find and fix memory leaks. There are go
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
On Sat, 2010-07-24 at 03:32 -0300, Gustavo Sverzut Barbieri wrote: > Guessed so from Qt port... Now we need to do that for both soup and > curl, or write an abstraction for elf with some backend outside webkit FYI, this is being worked on in soup: https://bugzilla.gnome.org/show_bug.cgi?id=55 Perhaps you could discuss with Dan Winship and Sergio how you could help them there =) See you, -- Gustavo Noronha Silva GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how is expected.txt file generating while test layouttests
how is expected.txt file generating while test layouttests On Tue, Aug 10, 2010 at 4:07 PM, KrishnaMurthy Naidu < krishnamurthyna...@gmail.com> wrote: > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how is expected.txt file generating while test layouttests
___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
