Re: [webkit-dev] Updating the tradition for new reviewer blog posts
So what is the process then if you have a blog ready to post? Just get one person to review? On 2 ʻAok 2010, at 9:02 PM, Maciej Stachowiak wrote: I agree that it would be good to have more useful and interesting content. I don't think it's good to do this by forcing the task on new reviewers. Not everyone enjoys a writing exercise and it shouldn't be required to become a reviewer. However, I encourage people to post about cool WebKitty stuff! - Maciej On Aug 2, 2010, at 11:56 AM, Tony Gentilcore wrote: The Surfin' Safari blog seems to have fairly wide readership in the web dev community. Google Reader reports 35k Reader subscribers. For comparison: blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last post with descriptive content was back on April 18th. Since that post, we've written 8 X is a now a WebKit reviewer posts. One recent commenter said: I don’t suppose there’s anything more interesting going on in WebKit land worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t nearly as interesting as whatever new hotness is coming down the pipe. And I know I’m not the only one who thinks so… Feel like blogging about WebKit awesomeness? I propose we increase the amount of blogging about WebKit awesomeness by changing the tradition for new reviewer posts. Instead of defaulting to: So-and-so is now a WebKit reviewer Posted by Someone-else So-and-so has worked on awesome-feature or awesome-infrastructure... We encourage (or just allow?) a format more like: How awesome-infrastructure works Posted by So-and-so, the latest WebKit reviewer Here's my description of how awesome-infrastructure works in WebKit... -OR- Awesome-feature is the new hotness Posted by So-and-so, the latest WebKit reviewer Web developers can now use awesome-feature. Here's how it works... Thoughts? -Tony ___ 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] Rendering a PDF on an HTML5 Canvas using WebKit/AIR
This is not the right mailing list for such questions. Please see http://webkit.org/contact.html On Tue, Aug 3, 2010 at 4:26 AM, Andrew Sealy-Bell andyamsterdam2...@gmail.com wrote: Hi, I'd like to know if anybody has experience with rendering a PDF on an HTML5 canvas? I'd like to to this and listen for mouse events etc. do overlay some customised functionality on top. I'd like to be able to do this both on a desktop AIR app and on the browser if possible. Any help or advice would be much appreciated. Regards, Andrew. ___ 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] Leopard Release Builder -- Slave Lost
http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) We lost the slave over 3 days ago. :( (The tree is also generally on fire right now...) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Canvas performance and memory usage
Hi, There is a performance hit when using HTML canvas when using ImageBufferCairo: - As soon as something is rendered in the canvas, the HTMLCanvasElement::willDraw method is called which in turn calls clearImage on the imageBuffer if one is already present. - When the render tree is traversed (HTMLCanvasElement::paint gets called), the image containing the canvas is drawn using GraphicsContext::drawImage. Unfortunately, ImageBuffer::image() (in BufferImageCairo.cpp) allocates a new surface, and copies the image surface into it. When very frequent updates are done in the canvas, this double buffering causes significant performance degradation that worsens with large canvas sizes. In addition, the extra memory consumption can become quite expensive especially on embedded devices. Can anybody explain why this double buffering is necessary for ImageBuffer specifically for the Cairo port? We are looking at disabling the double buffering at least for the canvas because of both performance and memory issues. It would also be nice to disable it for images as well but we would like to understand why in the first place it was added. Note that a code comment states This seems silly, but is the way the CG port works: image() is intended to be used only when rendering is complete. Any suggestion on how to fix this issue is welcome. If it is considered a bug, then I will create a bug as well to keep track of it. Regards, Christophe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
On Mon, Aug 2, 2010 at 9:40 AM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 2, 2010 at 7:33 AM, Dan Bernstein m...@apple.com wrote: On Aug 2, 2010, at 4:28 AM, Alexey Proskuryakov wrote: 29.07.2010, в 10:59, Darin Adler написал(а): The directory should be eventually be named Tests or WebKitTests or RegressionTests. Ideally, the directory will have a unique first letter for better tab completion - so WebKitTests is a poor option from that point of view. I like the other two. Tests collides with Tools (which is what WebKitTools should be renamed to). That sounds like a vote for RegressionTests I know I'm new around here, but my .02: This seems like a lot of busy work that will never really complete. We'll end up with LayoutTests in some places and RegressionTests in others, indefinitely. It will be even more messy than having the bad name consistently. Keep in mind that there are places that refer to WebKit's LayoutTests that aren't even under the WebKit project's control: http://www.google.com/search?q=webkit+layout+tests+-webkit.org It seems simpler and better to me to just have a note on the page on webkit.org that talks about LayoutTests describing the origins of the name and let sleeping dogs lie. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
I don’t buy in to this at all. We have done many successful renaming projects in the past. The future is bigger than the past and it’s worthwhile to do maintenance like this. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
On Tue, Aug 3, 2010 at 1:27 PM, Darin Adler da...@apple.com wrote: I don’t buy in to this at all. We have done many successful renaming projects in the past. The future is bigger than the past and it’s worthwhile to do maintenance like this. Okie. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Leopard Release Builder -- Slave Lost
Looks like the slave is back now. But there are ~90 pending builds: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) For future reference, I'm curious if it is safe to cancel some older builds so that it will catch up. On Tue, Aug 3, 2010 at 11:37 AM, Eric Seidel e...@webkit.org wrote: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) We lost the slave over 3 days ago. :( (The tree is also generally on fire right now...) -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] Leopard Release Builder -- Slave Lost
Yes its safe to cancel old builds. The only danger is that it is harder to track regressions. But caught-up builders missing a few builds are more useful than behind ones. :) On Tue, Aug 3, 2010 at 1:36 PM, Tony Gentilcore to...@chromium.org wrote: Looks like the slave is back now. But there are ~90 pending builds: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) For future reference, I'm curious if it is safe to cancel some older builds so that it will catch up. On Tue, Aug 3, 2010 at 11:37 AM, Eric Seidel e...@webkit.org wrote: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Tests) We lost the slave over 3 days ago. :( (The tree is also generally on fire right now...) -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
This would probably have to be verified, but I believe CG uses copy-on-write semantics when creating an image from a bitmap context. Therefore I suspect this is not a performance problem with CG just because of smarts in the underlying CG implementation. Basically image() is a cheap call for CG, and creating/destroying images over and over when frequent drawing happens is not expensive. However I'm not 100% sure about this. I think the fact that the image has to be manually cleared from the ImageBuffer is part of the problem. I think we should redesign ImageBuffer::image() so that every time it's called you can guarantee that you're getting an accurate reflection of the contents of the image buffer. I notice that Qt added imageForRendering() and felt they could not use image() for some reason. I'd be curious if a Qt expert could weigh in on that, since maybe with a redesign a separate call would not be needed. Here's a basic suggestion for how to improve this: (1) Make sure your port does a lightweight wrapping of the ImageBuffer into an Image and does not do a copy. It's debatable whether this Image really even needs to be cached if the creation operation is really lightweight. I think people copied the CG implementation I wrote where I wasn't 100% sure if I needed to cache or not, and that has created some of the confusion. (2) If anyone accesses the GraphicsContext of an ImageBuffer and we do cache the Image, maybe just assume they're going to draw and clear out the image. Anyway, I'd definitely file a bug. dave (hy...@apple.com) On Aug 3, 2010, at 3:20 PM, Christophe Public wrote: Hi, There is a performance hit when using HTML canvas when using ImageBufferCairo: - As soon as something is rendered in the canvas, the HTMLCanvasElement::willDraw method is called which in turn calls clearImage on the imageBuffer if one is already present. - When the render tree is traversed (HTMLCanvasElement::paint gets called), the image containing the canvas is drawn using GraphicsContext::drawImage. Unfortunately, ImageBuffer::image() (in BufferImageCairo.cpp) allocates a new surface, and copies the image surface into it. When very frequent updates are done in the canvas, this double buffering causes significant performance degradation that worsens with large canvas sizes. In addition, the extra memory consumption can become quite expensive especially on embedded devices. Can anybody explain why this double buffering is necessary for ImageBuffer specifically for the Cairo port? We are looking at disabling the double buffering at least for the canvas because of both performance and memory issues. It would also be nice to disable it for images as well but we would like to understand why in the first place it was added. Note that a code comment states This seems silly, but is the way the CG port works: image() is intended to be used only when rendering is complete. Any suggestion on how to fix this issue is welcome. If it is considered a bug, then I will create a bug as well to keep track of it. Regards, Christophe ___ 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] webkit editing rewrite?
At the editing meeting at the WebKit conference in April, we discussed the idea of coming up with a replacement to Position/Range, using that throughout the editing code and then eventually exposing that API to the web to supersede DOM Ranges. Specifically, the idea was to get rid of node/offset pairs and instead having the following possible positions: beforeNode, nodeStart, afterNode, nodeEnd. We would then only use offsets for positions inside text nodes. There are also a slew of other APIs web developers need to make editing work well, e.g., undo management, better selection control, position normalizing, etc. Finally, the editing code is crashtastic. Some of that is due to less than great foundations like the current Position class. Some of it is due to editing just being complicated. Some of us had a somewhat crazy idea to rewrite much of the editing code (e.g. document.execCommand) in JavaScript. Pros: -Ensures that the APIs we expose to the web are at least good enough for our own editing code -Ensures that editing code never crashes (outside of JSC/V8 bugs) -Gives a clean slate for starting the editing code anew -Moves code out of WebCore -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers Cons: -Potentially slower since DOM calls are now JS--C++ -Potential for regressions due to holes in the layout test coverage -Not statically typed I'm not too concerned about the perf hit. It should be no more than a constant-factor and, historically, the editing perf problems have been order-of-magnitude issues. As for the functionality regressions, I think they're inevitable. We'd hit most of the same issues trying to refactor the existing C++ code on top of better APIs. The best we can hope for is to write extra tests for each bit that we port over. We don't need to do this as one large atomic swap. We can port one command at a time over to keep this as incremental changes. There's also the question of whether we should expose the library code to JS. But that's orthogonal really. I think we shouldn't to start with not exposing the code. We can always decide to expose it later if we think it's worthwhile. What do you think? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit editing rewrite?
On Aug 3, 2010, at 4:32 PM, Ojan Vafai wrote: Pros: -Ensures that the APIs we expose to the web are at least good enough for our own editing code -Ensures that editing code never crashes (outside of JSC/V8 bugs) -Gives a clean slate for starting the editing code anew -Moves code out of WebCore -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers Cons: -Potentially slower since DOM calls are now JS--C++ -Potential for regressions due to holes in the layout test coverage -Not statically typed I am more interested in what these new APIs would be that we’d rebuild editing on top of. Using JavaScript as the programming language doesn’t seem so great, but I’m not as passionate about this as I am about devising good abstractions to build editing on top of. Coming up with the abstraction that lets us build efficient editing code seems like a challenge. Programming language has little to do with it. We’ve had lots of performance problems with editing code. Inventing a new layer to rebuild editing on top could well be good. Exposing that layer itself to webpages seems like it makes the job even harder rather than easier! Hidden implementation details can be changed more easily than exposed APIs. I personally don’t think a complete rewrite is a great idea, nor do I think that using JavaScript is how I’d do it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit editing rewrite?
On Aug 3, 2010, at 4:32 PM, Ojan Vafai wrote: At the editing meeting at the WebKit conference in April, we discussed the idea of coming up with a replacement to Position/Range, using that throughout the editing code and then eventually exposing that API to the web to supersede DOM Ranges. I assume you plan on maintaining support for the DOM Range API? http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit editing rewrite?
Some of us had a somewhat crazy idea to rewrite much of the editing code (e.g. document.execCommand) in JavaScript. Pros: -Ensures that the APIs we expose to the web are at least good enough for our own editing code I don't think this necessarily follows. Not everything exposed to the internal editing implementation would necessarily be exposed to the web. If we required that everything exposed to the internal editing implementation be exposed to the web, that would substantially slow development, since every new API would need to be vetted and possibly standardized. So this is either not true or a substantial con. -Ensures that editing code never crashes (outside of JSC/V8 bugs) JavaScript can still crash -- you just get an unhandled exception instead of a segfault. It's not clear to me why that would be better. I can think of reasons why it would be worse: - Can't use standard OS tools like CrashReporter to detect problem areas. - Harder to debug, since you need to use the Web Inspector, which: - doesn't have all the features of modern C++ debuggers, like watchpoints and breakpoint commands - creates a circular dependency - Sometimes, instead of an unhandled exception, you'll just get incorrect behavior that's very hard to track down. A similar set of cons pertains to performance issues. -Gives a clean slate for starting the editing code anew This is an argument for a rewrite, not an argument for JavaScript. A rewrite can happen in any language. A rewrite is not self-evidently a good thing. -Moves code out of WebCore Changing the language doesn't move the code out of WebCore. Moving code out of WebCore is not self-evidently a good thing. -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers That's a big if. Do you have any evidence that other vendors are interested? Are there vendors specifically interested in adopting WebKit's editing library, but not WebKit as a whole? That would surprise me. Cons: -Potentially slower since DOM calls are now JS--C++ -Potential for regressions due to holes in the layout test coverage -Not statically typed I notice that you don't mention the added complexity of gluing two languages together for core DOM operations. I think that's probably the main con. I'm not too concerned about the perf hit. It should be no more than a constant-factor and, historically, the editing perf problems have been order-of-magnitude issues. You're not considering the hurt that the editing JavaScript code could put on website code. If the editing memory footprint is large, the GC hit on other websites could be substantial. JavaScript's scoping rules also have a nasty tendency to introduce accidental memory references that keep large object graphs alive, exacerbating this problem. For security reasons, we might need to instantiate a new copy of the editing code for every webpage. That could be a substantial memory use regression. As for the functionality regressions, I think they're inevitable. We'd hit most of the same issues trying to refactor the existing C++ code on top of better APIs. I agree that a rewrite inevitably introduces a large number of bugs, regardless of whether it happens in C++ or JavaScript. However, I don't agree that refactoring inevitably introduces just as many bugs as rewriting. I would submit that the entire history of the WebKit project demonstrates the value of refactoring over rewriting. Geoff ___ 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
Resent from the proper address: On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson martin.james.robin...@gmail.com wrote: I notice that Qt added imageForRendering() and felt they could not use image() for some reason. I'd be curious if a Qt expert could weigh in on that, since maybe with a redesign a separate call would not be needed. I'm not a Qt expert, but just based on a quick look, it seems that imageForRendering avoids the full QPixmap copy. Christophe, when you open a bug for this issue, please CC me, as I have a small patch in my tree which has the same imageForRendering pecialization, but for Cairo. Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] commit-queue works again EOM
It was down for the last 36 hours due to Leopard bustage and moving machines. It's back up and running again now. Apologies for (my part) of the trouble. http://queues.webkit.org/queue-status/commit-queue -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
