Re: [webkit-dev] Roadmap for Qt specific implementation for Network Process
Hi, Currently, only the Mac port uses NetworkProcess, so there is no platform specific code for other backends. I am working on porting NetworkProcess to soup backend for WebKit GTK and EFL ports. The master bug is https://bugs.webkit.org/show_bug.cgi?id=108832 . You can see the platform bits you need to add to support NetworkProcess for Qt. Also we can share some infrastructure work such as supporting UNIX domain sockets in NetworkProcess. Regards, Kwang Yul Seo On Tue, Jul 9, 2013 at 1:46 PM, Harsh Sarin h.sari...@gmail.com wrote: Hi, I am new to webkit and currently analyzing the Network Process module. However, I am unable to locate any platform specific implementations for the same, except for that of mac platform. Like the Plugin and Web process I was expecting a main file (platform based) from where I could start debugging. Please could you shed some light on when and how you plan to develop a platform specific infrastructure for Network Process, specifically for Qt platform. Thanks for your time. ___ 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] Status of multithreaded image decoding
On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 13, 2012, at 11:08 AM, Alpha Lam hc...@chromium.org wrote: That's a good point. I'm not sure but a safe bet would be after RenderView is layout'ed then iterate through images to start decoding. The same thing would be needed for scrolling too, as page scrolls need to iterate images in the viewport. This approach is probably safe (as far as I know) but would have the downside of an extra pass over the whole render tree, or else overhead of maintaining an up-to-date list of rendered images; and it would happen very close to painting. Yes, the problem is that we don't have much time between layout and painting because painting is usually immediately followed by layout. I'm skeptical about the gain we could get by triggering image decoding in the layout phase, but I'd like to defer the conclusion until we have real numbers. I think to some extent, benefit from parallelism is in direct tension with benefit from lazy on-demand decoding. Unfortunately, yes. Because of the lazy nature of image decoding, we don't have much time for decoding before images need to be painted. So we skip image decoding (and just trigger decoding in the background) in the first paint pass and update the decoded images later. Note by the way that in general many kinds of render objects can result in rendering images, not just RenderImage. Consider the various forms of CSS images (CSS backgrounds, CSS content property pointing to an image, etc). We made CSS background, border and mask images be decoded by parallel image decoders. https://bugs.webkit.org/show_bug.cgi?id=91203 Regards, Maciej 2012/8/13 Alpha (Hin-Chung) Lam hc...@google.com That's a good point. I'm not sure but a safe bet would be after RenderView is layout'ed then iterate through images to start decoding. The same thing would be needed for scrolling too, as page scrolls need to iterate images in the viewport. Alpha 2012/8/13 Maciej Stachowiak m...@apple.com The thing I'm not confident of is whether an image's position in absolute coordinates can be changed by an ancestor after RenderImage::layout completes. It would be helpful if a layout expert would weigh in. - Maciej On Aug 13, 2012, at 3:20 AM, Dong Seong Hwang luxte...@company100.net wrote: https://bugs.webkit.org/show_bug.cgi?id=90375#c80 In the above link, Hin-Chung shows how to determine whether an image is actually painted. 2012/8/13 Maciej Stachowiak m...@apple.com: I that case, starting async decoding at layout time makes sense if and only if at layout to e you can predict what you will paint. I don't know enough about our rendering to know of that is the case. - Maciej On Aug 12, 2012, at 5:34 PM, Peter Kasting pkast...@chromium.org wrote: On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak m...@apple.com wrote: Why not start asynchronous decoding immediately as the image is loading, and synchronize at paint time? What is the benefit of waiting until layout time to start decoding the image data? Uninformed guess (since I haven't touched the decoders in a while), but currently we don't decode unless the image is actually painted, which helps a ton on pages that are an enormous long string of images (common cases: Boston Big Picture blog, various porn sites), since most of the images can be decoded after initial layout, or not at all (if the user never scrolls down enough). If we started decoding as images loaded I'd imagine we'd do (possibly a lot of) extra work compared to today. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of multithreaded image decoding
BTW, we are discussing the very same topic on the master bug. For those of you who are interested in this topic, please refer to the master bug for other concerns and probable solutions: https://bugs.webkit.org/show_bug.cgi?id=90375 On Tue, Aug 14, 2012 at 8:32 AM, KwangYul Seo sk...@company100.net wrote: On Tue, Aug 14, 2012 at 4:03 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 13, 2012, at 11:08 AM, Alpha Lam hc...@chromium.org wrote: That's a good point. I'm not sure but a safe bet would be after RenderView is layout'ed then iterate through images to start decoding. The same thing would be needed for scrolling too, as page scrolls need to iterate images in the viewport. This approach is probably safe (as far as I know) but would have the downside of an extra pass over the whole render tree, or else overhead of maintaining an up-to-date list of rendered images; and it would happen very close to painting. Yes, the problem is that we don't have much time between layout and painting because painting is usually immediately followed by layout. I'm skeptical about the gain we could get by triggering image decoding in the layout phase, but I'd like to defer the conclusion until we have real numbers. I think to some extent, benefit from parallelism is in direct tension with benefit from lazy on-demand decoding. Unfortunately, yes. Because of the lazy nature of image decoding, we don't have much time for decoding before images need to be painted. So we skip image decoding (and just trigger decoding in the background) in the first paint pass and update the decoded images later. Note by the way that in general many kinds of render objects can result in rendering images, not just RenderImage. Consider the various forms of CSS images (CSS backgrounds, CSS content property pointing to an image, etc). We made CSS background, border and mask images be decoded by parallel image decoders. https://bugs.webkit.org/show_bug.cgi?id=91203 Regards, Maciej 2012/8/13 Alpha (Hin-Chung) Lam hc...@google.com That's a good point. I'm not sure but a safe bet would be after RenderView is layout'ed then iterate through images to start decoding. The same thing would be needed for scrolling too, as page scrolls need to iterate images in the viewport. Alpha 2012/8/13 Maciej Stachowiak m...@apple.com The thing I'm not confident of is whether an image's position in absolute coordinates can be changed by an ancestor after RenderImage::layout completes. It would be helpful if a layout expert would weigh in. - Maciej On Aug 13, 2012, at 3:20 AM, Dong Seong Hwang luxte...@company100.net wrote: https://bugs.webkit.org/show_bug.cgi?id=90375#c80 In the above link, Hin-Chung shows how to determine whether an image is actually painted. 2012/8/13 Maciej Stachowiak m...@apple.com: I that case, starting async decoding at layout time makes sense if and only if at layout to e you can predict what you will paint. I don't know enough about our rendering to know of that is the case. - Maciej On Aug 12, 2012, at 5:34 PM, Peter Kasting pkast...@chromium.org wrote: On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak m...@apple.com wrote: Why not start asynchronous decoding immediately as the image is loading, and synchronize at paint time? What is the benefit of waiting until layout time to start decoding the image data? Uninformed guess (since I haven't touched the decoders in a while), but currently we don't decode unless the image is actually painted, which helps a ton on pages that are an enormous long string of images (common cases: Boston Big Picture blog, various porn sites), since most of the images can be decoded after initial layout, or not at all (if the user never scrolls down enough). If we started decoding as images loaded I'd imagine we'd do (possibly a lot of) extra work compared to today. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal and WIP implementation for refactoring cross thread communication
Currently, there is no code using WTF::Function in single-threaded code. It seems WTF::Function is intended to be used for cross thread communication. One evidence is that FunctionImplBase is thread-safe ref-counted, which is not super efficient for single threaded use cases. If we have no plan to use WTF::Function for single threaded code, why don't we rename WTF::Function to WTF::CrossThreadFunction and add more features such as cross thread copying there? Regards, Kwang Yul Seo On Mon, Aug 13, 2012 at 9:26 PM, Kwonjin Jeong g...@company100.net wrote: Hi, WebKit. There are several implementations of threads, tasks and cross thread communication. e.g. FileThread, DatabaseThread and StorageThread perform blocking IO asynchronously and invoke callbacks using ScriptExecutionContext. Each of these implementation is pretty similar, but there is no code sharing at all. So, my team at Company 100 is trying to refactor cross thread communication. We wrote an API proposal and modified some thread code to use our new API. As the first step, we added two new abstractions for cross thread communcation: 1) TaskThread is our new abstraction for the task thread. FileThread, DatabaseThread and other task threads reuse the code by inheriting from TaskThread. 2) We also added CrossThreadFunction. It's used to pass a task to the task thread and invoke callbacks. CrossThreadFunction is similar to WTF::Function but it has some additional features. e.g., cross-thread parameter copying and ref counting. Please refer to the following bug for details: https://bugs.webkit.org/show_bug.cgi?id=92365 We welcome feedbacks on our work. Thanks. -- Kwonjin Jeong Computer Scientist Company 100, Inc. Phone: +82-10-9528-2581 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
Down again? I can't access bugs.webkit.org again from Korea. On Thu, Aug 9, 2012 at 9:51 PM, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 12:49 PM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 04:22, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 11:41 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 03:14, Peter Beverloo pe...@chromium.org wrote: On Thu, Aug 9, 2012 at 11:09 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-09, at 02:41, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? This is caused by a problem on a host that I don't have sufficient privileges on to be able to address the issue myself. I've pinged people that should be able to resolve the issue, but given that it's currently 3am in California it may be a few hours before they're awake and fixing it. Thank you. Is there any way an on-call or monitoring system could be set up? While it fortunately occurs much less frequently nowadays than it did earlier in the year, it --please excuse my directness-- is unacceptable for a project the size of WebKit to have critical infrastructure unavailable like this for several hours. Even though it's 3am in California, there are many contributors in Asia and Europe who are severely impacted by this. We have people online virtually 24x7 that are capable of investigating and addressing issues with the webkit.org infrastructure. I'm one such person. This particular case is an unfortunate combination of events: a configuration error on a subset of the new hardware that webkit.org was recently migrated to has unintentionally limited the number of people that can access the host that is currently experiencing problems, and the person that such issues are escalated to is currently on vacation. It's an unfortunate combination, but also one that is unlikely to repeat. One thing we should look in to is improving the process for reporting issues with webkit.org infrastructure. webkit-dev isn't an ideal way to report issues that our monitoring system hasn't noticed as there's no separation between the regular discussion and more urgent issues, so the emails can be overlooked. I see. Thank you for the insight, and I hope the access issues get sorted out. I presume this is something Bill or Lucas will be able to pick up? Hopefully the remaining downtime won't be more than three or four hours, then. Bill is the one that's on vacation, and Lucas is in the same boat that I am as far as access to the host in question. I managed to track down someone else with sufficient access though, and they've fixed the issue that was impacting bugs.webkit.org and trac.webkit.org. Awesome, cheers! Peter - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] github mirror
Hi, Adam. What's the current status? Do they still have different hashes? I am trying to push a few commits to my GitHub WebKit repo from my repo cloned from git.webkit.org. It seems I am pushing the entire repo :( Regards, Kwang Yul Seo On Mon, Apr 30, 2012 at 2:48 AM, Adam Barth aba...@webkit.org wrote: Tor, I think we should retire the author rewriting script on GitHub. Jame's is right that there's a lot of value in having git.webkit.org and GitHub using the same hashes. For example, both Eric and Gavin requested that when they started using GitHub. We would have some trouble adopting the author rewriting script on git.webkit.org. For example, the instructions for using git with WebKit http://trac.webkit.org/wiki/UsingGitWithWebKit suggest configuring git-svn to allow you to commit from your git repository. When git-svn imports changes from SVN into your git repository, it won't know to apply the author rewriting script. That will cause your local repository to diverge from an author-rewriting git.webkit.org, which is bad times. Therefore, it seems like the best way to synchronize the hashes between git.webkit.org and GitHub is to retire the author rewriting script on GitHub and do a non-fastforward push of the unrewritten repository. That will be somewhat disruptive for folks currently using the GitHub repository, but at least it's only a one-time cost. Adam On Tue, Apr 24, 2012 at 11:06 AM, James Robinson jam...@google.com wrote: On Tue, Apr 24, 2012 at 7:15 AM, Tor Arne Vestbø tor.arne.ves...@nokia.com wrote: On 24.04.12 16:04, ext Shezan Baig wrote: On Tue, Apr 24, 2012 at 9:55 AM, Adam Robenaro...@webkit.org wrote: In what situation does this cause issues? Probably the biggest issue is for people who've been using git.webkit.org and now want to try out GitHub. Since the commits are distinct between the two repositories, they have to do a full clone to make the switch. In theory though, these users should be able to just add a remote to their existing clone. Then it will just sync the commit objects, and not the trees and blobs. Not ideal, they would have two different 'masters', but still doable, and not *that* much of an overhead. Switching between the different masters should also be fast since the trees will be the same. Right, a fetch should ideally just pull down the commit objects, but it appears git does not have this optimization. If it did, I don't think the issue of two remote masters would be that big, since you would at some point likely transition to use one of the mirrors anyways. And if not, having multiple mirrors/remotes should be fine -- I'm using both the github and gitorious mirror without any issues. But I agree these two repos should probably merge sooner rather than later, just to avoid confusion for new users etc :) I would support that if it means cleaning up the author-script (which I'm happy to do), and using that on webkit.org. Whatever we decide to do in the future, author rewriting seems like extremely low value compared to having matching SHA1s. I think we should get a clone on github.com that matches the existing git.webkit.orgSHA1s and then make sure that they stay in sync (either with rewriting or not, but whatever webkit.org does). - James tor arne ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Thank you letting me know this information! On Tue, Jul 17, 2012 at 5:41 AM, Alpha Lam hc...@chromium.org wrote: Hi! This is great work! There's work in the Chromium port going on that has a similar goal as your parallel image decoding effort. There are some parts that we overlap that I think should be discussed to avoid clashes. What's the current progress of Chromium work? Can I check out the source code? Do you have a design document? Here's some background information of what we're doing. In Chromium port there's a deferred painting mode that we record painting commands and playback (rasterize) on another thread. Recording on the main thread requires images to be synchronously decoded and our current focus is to defer image decoding to a later time and eventually have parallel image decoding. The specific part we overlap is drawing an asynchronously decoded BitmapImage to GraphicsContext. Your patch does the whole image decoding asynchronously while we just care about whether an image can be asynchronously decoded or not. This part in particular I think we should discuss to make sure we're both comfortable with. Our approach also checks if the given image can be decoded asynchronously or not. Please refer to 3.3 Criteria to Use Parallel Image Decoders of our design document. ( https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 ) I certainly want to hear more about your approach here. I'll make a few comments on the patch in the webkit bug. Thanks. I think we can improve both approaches by sharing ideas with each other regarding asynchronous image decoding because they have much in common. Thanks and this is great effort! Alpha 2012/7/9 KwangYul Seo sk...@company100.net Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ 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/webkit-dev
[webkit-dev] Parallel image decoders are up for review
Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Parallel image decoders are up for review
Thanks. I will upload one monolithic patch (not for review) that you can see to the master bug when I come back to work tomorrow. It is late night in Korea :( I really appreciate your previous work! Regards, Kwang Yul Seo On Mon, Jul 9, 2012 at 10:16 PM, Zoltan Horvath zol...@webkit.org wrote: Great job guys! Your approach sounds good. Can you upload an overall patch (not for review) to the main bug? Then we can easily test your solution and see the overall complexity change of the patch. I will test the patch on Qt and keep in touch. Regards, Zoltan On Mon, 09 Jul 2012 10:30:51 +0200, KwangYul Seo sk...@company100.net wrote: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_**bug.cgi?id=90375https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/**document/pub?id=**12gf7MhNHfupeR3GdRF-** h2Vzg86viCbwXq8_JByHKlg0https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Regards, Kwang Yul Seo __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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] Parallel image decoders are up for review
Hi, I realized that measuring page loading time here is a bit misleading. Because image decoding is performed lazily in rendering, it is possible that many images are still not decoded when page loading is finished. Parallel image decoders exacerbate this because image decoding is changed to asynchronous. Therefore, to accurately measure the performance improvement, we must measure time to the first paint as Maciej suggested. I will update the test results and add more image heavy real word sites such as cuteoverload.com, flickr.com and pinterest.com. Regards, Kwang Yul Seo On Tue, Jul 10, 2012 at 7:42 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 9, 2012, at 1:30 AM, KwangYul Seo sk...@company100.net wrote: Hi, Our team at Company 100 has worked on parallel image decoders for past a few weeks and some patches are pending for review now. Here is the master bug for parallel image decoders: https://bugs.webkit.org/show_bug.cgi?id=90375 For the overall architecture and design, please refer to the following design document. We will update the design document as we change code after review. https://docs.google.com/document/pub?id=12gf7MhNHfupeR3GdRF-h2Vzg86viCbwXq8_JByHKlg0 Our implementation shows considerable speedup in image intensive sites and no performance regression in PLT. Please refer to the master bug for specific numbers. We do understand many paralleization techniques make code so complex to the level that can't be accepted. So we tried our best to reduce the complexity of code, but reviewers can help us reduce it further. Some questions: (1) Do you know of any real-world sites that get a significant benefit? The linked page mentions an artificial test case that gets a large benefit, but shows an inconclusive result for the more general page load benchmark cited. There are definitely image-heavy real-world sites out there, such as http://cuteoverload.com or flickr.com photostream pages. (2) Did you do any testing of time to first paint in addition to page load time? Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] lineNumber() and textPosition() methods in HTMLDocumentParser
Hi.
I have a question regarding HTMLDocumentParser. I found that lineNumber()
retrives the line number from m_tokenizer while
textPosition() retrieves the line number from m_input.current(). I wonder
why HTMLDocumentParser keeps two copies of line
number. ASSERT(m_tokenizer-lineNumber() == line) in
HTMLDocumentParser::textPosition() implies that these two line numbers are
usually the same.
OrdinalNumber HTMLDocumentParser::lineNumber() const
{
*return m_tokenizer-lineNumber();*
}
TextPosition HTMLDocumentParser::textPosition() const
{
const SegmentedString currentString = m_input.current();
*OrdinalNumber line = currentString.currentLine();*
OrdinalNumber column = currentString.currentColumn();
ASSERT(m_tokenizer-lineNumber() == line);
return TextPosition(line, column);
}
Regards,
Kwang Yul Seo
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
Hi, Multiple ports can share the implementation if we put spell checker in WebCore. Ports without native spell checker can use Hunspell based spell checker without much efforts. Brew MP port is also interested because it does not have a native spell checker. Regards, Kwang Yul Seo On Thu, Nov 18, 2010 at 5:27 AM, Brent Fulgham bfulg...@gmail.com wrote: On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. At least in the Windows implementation (WebKit/WebKit source base), the spell checker is implemented on the client side as a delegate operation. I wrote up a few notes on the topic (http://whtconstruct.blogspot.com/2010/07/spelling.html). What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? -Brent ___ 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] Windows mobile build
Hi, Jason. I don't think it is a good idea to add separate solution and vcproj files for Windows Mobile. Windows Mobile is just a small part of Windows CE. Windows CE covers multiple CPU architectures (ARM, MIPS, ..) and platforms with varying features. I hope the build system covers multiple configurations easily. vcproj file is too verbose and not easy to maintain to keep multiple configurations as we can see from Windows port. If we are going to add a build system for Windows CE, I think we need a more clever way to deal with this problem. I am currently working on a build system which generates MSVS solution and vcproj files from a build script. The sole purpose of this build system is to support multiple Windows CE platforms and configurations from a single script. I'd like to contribute this work once it is ready. By the way, what is your contribution plan? Do you plan to contribute WebKit API and layout tests? Regards, Kwang Yul Seo On Sat, Apr 3, 2010 at 12:45 AM, Jason Rukman jas...@bsquare.com wrote: Right now we have a windows mobile 6.x build for webkit. I’d like to start merging this into the tree but wanted to get some consensus on an approach. We have created our own solution and vcproj files that pretty much follow the current solution/vcproj files for the windows cairo build configuration. Would it make sense to add a windows mobile build and solution configuration to the existing windows solution (with some different vsprop changes) or should we check in our version of the solution and project files separately (and where?) I don’t like the idea of a separate solution/vcproj files but as far as I know if we add the windows mobile configuration you need to have the windows mobile sdk installed to be able to open the solution. I need to confirm that this is true also if you just run the build from the command line though. I’ve had some success merging changes between vcproj files so it’s possible this might be automated. Thanks, Jason. ___ 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] Lots of “BREW” patches up for review
I changed the platform defines from BREW to BREWMP to match the official port name. As BREWMP is backward compatible with BREW, there is no much differences. As Eric mentioned, a port without the DRT and a working buildbot is too fragile We will upstream the DRT implementation to webkit.org ASAP once it is ready and will setup a build bot. I will update the Wiki page with detailed schedule and todo list. Thanks, Kwang Yul Seo On Sat, Jan 23, 2010 at 8:36 AM, Eric Seidel e...@webkit.org wrote: Ok, so my reading of this thread is that WebKit is ready to accept a BREW/BREW-MP port. I'm not sure how much the platform defines (BREW vs. BREWMP) matter, but it's fine to change them to match whatever the official port is. Sounds like you have an in-progress DRT implementation. Can we expect it to move to webkit.org soon? I'm glad to see you already have build instructions: http://trac.webkit.org/wiki/BREW Have any of the BREW folks started work on a buildbot slave? No huge rush, but until the port has a builder at build.webkit.org it will likely break daily. :) http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/build.webkit.org-config I would also encourage you to read (and update!): http://trac.webkit.org/wiki/SuccessfulPortHowTo Thanks! -eric On Fri, Jan 22, 2010 at 3:04 PM, KwangYul Seo kwangyul@gmail.com wrote: I will update the patches with BREW_MP tag. Thanks, Kwang Yul Seo On Sat, Jan 23, 2010 at 3:00 AM, David Levin le...@chromium.org wrote: Based on this, it sounds like all [BREW] patches should be r-'ed and appropriate BREW_MP ones submitted? On Sun, Jan 17, 2010 at 6:23 PM, KwangYul Seo kwangyul@gmail.com wrote: [1] NDA I checked the issue with Qualcomm and drew two conclusions: 1) For BREW MP, we can open source our code without any limitation. 2) For BREW, it is not clear if we can open source our code or not due to the NDA with Qualcomm. Hosting and distributing the code can cause a potential problem. This situation is interesting because BREW and BREW MP shares most of the API. I should change the official port name to BREW MP. [2] DumpRenderTree We are actively working on DumpRenderTree, but it is not ready yet. We plan to open it next month. On Fri, Jan 15, 2010 at 10:26 AM, Eric Seidel e...@webkit.org wrote: I don't feel like this question was ever answered. Folks seem to be moving forward with setting up infrastructure for a real port (which is good), but at least this question still remains. Also, does the BREW port already have a DumpRenderTree implementation? When should we expect such? -eric On Wed, Jan 13, 2010 at 1:27 PM, Holger Freyther ze...@selfish.org wrote: On Wednesday 13 January 2010 18:23:21 Darin Adler wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. Last time I checked one needs to have a contract with Qualcomm (NDA) to get information (header files, documentation) that is beyond marketing bla bla. I would be interested if we are allowed to host and distribute the sourcecode that has used information which is under a NDA. ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build bots
It seems gtk and qt build bots are never for run for 33937. Do I need to do something here? https://bugs.webkit.org/show_bug.cgi?id=33937 Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ENABLE(SINGLE_THREADED)
Hi, Currently, ENABLE(SINGLE_THREADED) guard seems to be used by Qt alone. I think it is good to have ENABLE(SINGLE_THREADED) for other ports. Qt adds appropriate guards for ENABLE(SINGLE_THREADED) in the build script, WebKit.pri. For other ports to use it, we need to move theses guards to Platform.h: #if ENABLE(SINGLE_THREADED) #undef ENABLE_JSC_MULTIPLE_THREADS #define ENABLE_JSC_MULTIPLE_THREADS 0 #define ENABLE_DATABASE 0 #define ENABLE_DOM_STORAGE 0 #define ENABLE_ICONDATABASE 0 #define ENABLE_WORKERS 0 #define ENABLE_SHARED_WORKERS 0 #endif Is this okay for Qt port? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] strdup in WebKit
Hi, WebKit does not use malloc/free directly in favor of fastMalloc/fastFree. The only exception to this rule is strdup() which returns a memory that must be freed by free. Why don't we add fastStrDup which allocates a memory with fastMalloc? The memory returned by fastStrDup can be freed by fastFree. The following source files in WebCore contains strdup calls. dom/XMLTokenizerLibxml2.cpp plugins/PluginStream.cpp platform/network/ResourceHandleInternal.h platform/network/curl/ResourceHandleManager.cpp platform/network/curl/ResourceHandleCurl.cpp xml/XSLTProcessorLibxslt.cpp bindings/v8/npruntime.cpp bindings/v8/V8NPUtils.cpp bridge/IdentifierRep.h bridge/jni/jni_runtime.cpp bridge/jni/jsc/JavaClassJSC.cpp bridge/npruntime.cpp bridge/testbindings.cpp strdup/free pairs can be safely replaced with fastStrDup/fastFree in most cases. However, bridge and bindings can be an exception because some APIs must return malloc() allocated memory that can be freed with free(). I am asking this because strdup (POSIX function) is not available in RVCT. If this is not possible for some reasons, adding strdup to StringExtras.h for RVCT can be a good solution too. How does the Symbian QT port solve this problem? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lots of “BREW” patches up for review
I opened a public git repository for WebKit BREW MP port. Third party libraries are available in ThirdPartyLibraries directory. You can get the source code from the following location with git-clone: http://www.dorothybrowser.com/git/WebKitBrew.git The port is complete, but minimal. It contains a very simple WebKit API which needs to be rewritten in accordance with BREW API style. I removed the launcher for BREW 4.x due to a legal issue. Sooner or later, I will add a simple BREWLauncher which runs in BREW MP simulator. Port details: - The port can be compiled with BREW MP 1.0 SDK. - The port is initially ported to BREW 4.0.4 so the code still uses PLATFORM(BREW) guard. PLATFORM(BREWMP) or PLATFORM(BMP) might be a better name. Any suggestion? - ResourceHandle is implemented with BREW's native HTTP backend, IWeb. - skia is used for graphics backend and freetype is used for font rendering within skia. Regards, Kwang Yul Seo On Fri, Jan 15, 2010 at 10:17 AM, KwangYul Seo kwangyul@gmail.com wrote: Sure. I will open a public Git repository for potential reviewers. I need to clean up the code before opening the complete source code because some device-specific information is from a phone manufacturer under NDA. I think it will take one or two days.Third party libraries with BREW specific patches will also be available by then. Thanks, Kwang Yul Seo On Fri, Jan 15, 2010 at 4:05 AM, Adam Treat tr...@kde.org wrote: You have a complete port of BREW already? Interesting. Can you point to the complete sources so potential reviewers can have a look at what the state is? On Thursday 14 January 2010 07:02:24 am KwangYul Seo wrote: I created a wiki for the BREW port of WebKit. https://trac.webkit.org/wiki/BREW Currently it contains preliminary information. I will add more contents gradually. Thanks, Kwang Yul Seo On Thu, Jan 14, 2010 at 9:22 AM, Ariya Hidayat ariya.hida...@gmail.com wrote: This is not a one-time code drop. We want to maintain the BREW port ongoing and will do everything that are required to keep the BREW port up and running. Porting DumpRenderTree is still under work, but we have a complete BREW port which works fine both in BREW device and simulator. Kwang, can you add the all information about the port to http://trac.webkit.org/wiki#WebKitPorts? I guess, make a new wiki page for that and add it to that list. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ 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] Lots of “BREW” patches up for review
Git over HTTP seems to be too slow. Use git protocol instead. git-clone git://www.dorothybrowser.com/WebKitBrew.git On Wed, Jan 20, 2010 at 10:09 AM, KwangYul Seo kwangyul@gmail.comwrote: I opened a public git repository for WebKit BREW MP port. Third party libraries are available in ThirdPartyLibraries directory. You can get the source code from the following location with git-clone: http://www.dorothybrowser.com/git/WebKitBrew.git The port is complete, but minimal. It contains a very simple WebKit API which needs to be rewritten in accordance with BREW API style. I removed the launcher for BREW 4.x due to a legal issue. Sooner or later, I will add a simple BREWLauncher which runs in BREW MP simulator. Port details: - The port can be compiled with BREW MP 1.0 SDK. - The port is initially ported to BREW 4.0.4 so the code still uses PLATFORM(BREW) guard. PLATFORM(BREWMP) or PLATFORM(BMP) might be a better name. Any suggestion? - ResourceHandle is implemented with BREW's native HTTP backend, IWeb. - skia is used for graphics backend and freetype is used for font rendering within skia. Regards, Kwang Yul Seo On Fri, Jan 15, 2010 at 10:17 AM, KwangYul Seo kwangyul@gmail.com wrote: Sure. I will open a public Git repository for potential reviewers. I need to clean up the code before opening the complete source code because some device-specific information is from a phone manufacturer under NDA. I think it will take one or two days.Third party libraries with BREW specific patches will also be available by then. Thanks, Kwang Yul Seo On Fri, Jan 15, 2010 at 4:05 AM, Adam Treat tr...@kde.org wrote: You have a complete port of BREW already? Interesting. Can you point to the complete sources so potential reviewers can have a look at what the state is? On Thursday 14 January 2010 07:02:24 am KwangYul Seo wrote: I created a wiki for the BREW port of WebKit. https://trac.webkit.org/wiki/BREW Currently it contains preliminary information. I will add more contents gradually. Thanks, Kwang Yul Seo On Thu, Jan 14, 2010 at 9:22 AM, Ariya Hidayat ariya.hida...@gmail.com wrote: This is not a one-time code drop. We want to maintain the BREW port ongoing and will do everything that are required to keep the BREW port up and running. Porting DumpRenderTree is still under work, but we have a complete BREW port which works fine both in BREW device and simulator. Kwang, can you add the all information about the port to http://trac.webkit.org/wiki#WebKitPorts? I guess, make a new wiki page for that and add it to that list. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ 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] Lots of “BREW” patches up for review
[1] NDA I checked the issue with Qualcomm and drew two conclusions: 1) For BREW MP, we can open source our code without any limitation. 2) For BREW, it is not clear if we can open source our code or not due to the NDA with Qualcomm. Hosting and distributing the code can cause a potential problem. This situation is interesting because BREW and BREW MP shares most of the API. I should change the official port name to BREW MP. [2] DumpRenderTree We are actively working on DumpRenderTree, but it is not ready yet. We plan to open it next month. On Fri, Jan 15, 2010 at 10:26 AM, Eric Seidel e...@webkit.org wrote: I don't feel like this question was ever answered. Folks seem to be moving forward with setting up infrastructure for a real port (which is good), but at least this question still remains. Also, does the BREW port already have a DumpRenderTree implementation? When should we expect such? -eric On Wed, Jan 13, 2010 at 1:27 PM, Holger Freyther ze...@selfish.org wrote: On Wednesday 13 January 2010 18:23:21 Darin Adler wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. Last time I checked one needs to have a contract with Qualcomm (NDA) to get information (header files, documentation) that is beyond marketing bla bla. I would be interested if we are allowed to host and distribute the sourcecode that has used information which is under a NDA. ___ 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] Lots of “BREW” patches up for review
I will check the issue as soon as possible and let you know the result. In case there is a legal problem with BREW with regard to NDA, BREW MP can be used instead because BREW MP is an open platform. On Thu, Jan 14, 2010 at 6:27 AM, Holger Freyther ze...@selfish.org wrote: On Wednesday 13 January 2010 18:23:21 Darin Adler wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. Last time I checked one needs to have a contract with Qualcomm (NDA) to get information (header files, documentation) that is beyond marketing bla bla. I would be interested if we are allowed to host and distribute the sourcecode that has used information which is under a NDA. ___ 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] Lots of “BREW” patches up for review
Okay. I will add a new wiki page for the BREW port. Thanks. Regards, Kwang Yul Seo On Thu, Jan 14, 2010 at 9:22 AM, Ariya Hidayat ariya.hida...@gmail.com wrote: This is not a one-time code drop. We want to maintain the BREW port ongoing and will do everything that are required to keep the BREW port up and running. Porting DumpRenderTree is still under work, but we have a complete BREW port which works fine both in BREW device and simulator. Kwang, can you add the all information about the port to http://trac.webkit.org/wiki#WebKitPorts? I guess, make a new wiki page for that and add it to that list. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ 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] Lots of “BREW” patches up for review
I created a wiki for the BREW port of WebKit. https://trac.webkit.org/wiki/BREW Currently it contains preliminary information. I will add more contents gradually. Thanks, Kwang Yul Seo On Thu, Jan 14, 2010 at 9:22 AM, Ariya Hidayat ariya.hida...@gmail.com wrote: This is not a one-time code drop. We want to maintain the BREW port ongoing and will do everything that are required to keep the BREW port up and running. Porting DumpRenderTree is still under work, but we have a complete BREW port which works fine both in BREW device and simulator. Kwang, can you add the all information about the port to http://trac.webkit.org/wiki#WebKitPorts? I guess, make a new wiki page for that and add it to that list. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ 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] Lots of “BREW” patches up for review
Sure. I will open a public Git repository for potential reviewers. I need to clean up the code before opening the complete source code because some device-specific information is from a phone manufacturer under NDA. I think it will take one or two days.Third party libraries with BREW specific patches will also be available by then. Thanks, Kwang Yul Seo On Fri, Jan 15, 2010 at 4:05 AM, Adam Treat tr...@kde.org wrote: You have a complete port of BREW already? Interesting. Can you point to the complete sources so potential reviewers can have a look at what the state is? On Thursday 14 January 2010 07:02:24 am KwangYul Seo wrote: I created a wiki for the BREW port of WebKit. https://trac.webkit.org/wiki/BREW Currently it contains preliminary information. I will add more contents gradually. Thanks, Kwang Yul Seo On Thu, Jan 14, 2010 at 9:22 AM, Ariya Hidayat ariya.hida...@gmail.com wrote: This is not a one-time code drop. We want to maintain the BREW port ongoing and will do everything that are required to keep the BREW port up and running. Porting DumpRenderTree is still under work, but we have a complete BREW port which works fine both in BREW device and simulator. Kwang, can you add the all information about the port to http://trac.webkit.org/wiki#WebKitPorts? I guess, make a new wiki page for that and add it to that list. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ 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] Lots of “BREW” patches up for review
Hi, I am Kwang Yul Seo and I work for Company 100, Inc. (http://www.company100.net). I have started to submit patches that are required to port WebKit to Qualcomm's BREW platform. This is not a one-time code drop. We want to maintain the BREW port ongoing and will do everything that are required to keep the BREW port up and running. Porting DumpRenderTree is still under work, but we have a complete BREW port which works fine both in BREW device and simulator. Regards, Kwang Yul Seo On Thu, Jan 14, 2010 at 2:23 AM, Darin Adler da...@apple.com wrote: Someone is porting WebKit to Qualcomm’s BREW. And there are many patches for that port; now a significant fraction of the unreviewed WebKit patches. Who’s going to review these? Is this a one-time code drop or is there an intent to maintain this port ongoing? Does the test suite work on the BREW platform yet? Will someone maintain a buildbot? I won’t be reviewing these patches myself until I know the answers to some of those questions. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WINCE port: questions regarding to JavaScriptCore
Hi, GetThreadCallStack() is a kernel function, but it is not Kernel-mode only. So you can definitely use it to get the stack base address. However, Pkfuncs.h (which includes the function declaration, related structures and constants) is not usually available for user-level applications. You need to create a header file by yourself to use it. The current method with isPageWritable is not so efficient, but it is performed only once. Thus there is no problem. On the other hand, GetThreadCallStack seems to return frames of kernel functions too (it is a kernel function anyway), so the returned stack base address is slightly larger. It means it takes more time to scan the stack when GC occurs. Regards, Kwang Yul Seo On Fri, Oct 16, 2009 at 3:05 PM, Taeyun Kim z...@logicplant.com wrote: I'm currently looking at the source code for WINCE port. And I have two questions regarding to the JavaScriptCore. 1. In Collector.cpp, getStackBase() scans through the memory pages using IsPageWritable() to guess the base of the stack. But isn't it more precise to use GetThreadCallStack() instead? By using GetThreadCallStack(), one can get all the stack frames. The CallSnapshotEx structure which is filled by GetThreadCallStack() for each stack frame has dwFramePtr member, and that member's value of the last stack frame can be used to indicate the base of the stack of the thread. Has GetThreadCallStack() been considered and decided not to be used? Maybe the performance issue? 2. In WINCE port, ENABLE_JSC_MULTIPLE_THREADS is set to 0 so JavaScriptCore's multithreading feature is disabled. What is the reason to disable it? For ARM processor, I tried to fill some platform-specific portion in Collector.cpp for WINCE, and after that, it was compiled successfully with ENABLE_JSC_MULTIPLE_THREADS set to 1. (getStackBase() mentioned above must be changed not to use global variables for this). But I haven't tested it since I cannot build the remaining modules for WINCE port(WebCore, WebKit etc.) for now. Is there any complex problems? (Maybe the performance issue?) Thanks in advance. --- Taeyun Kim ___ 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] Standing of the WINCE port
Hi, 2 WINCE ports are not competing. We are waiting for Torch Mobile to finish the WINCE port not to cause conflicts as you can see in: https://bugs.webkit.org/show_bug.cgi?id=27076 I submitted the Geolocation WINCE patch because the Torch Mobile WINCE port does not have one: https://bugs.webkit.org/show_bug.cgi?id=28095 The problem was not the review process but the license problem because we started the closed beta program without opening our soure code. Recently we released the open source portion of our browser source code and the source tarballs are available from our web site. We hope that we can contribute our code where there is no direct conflict with the on-going Torch Mobile's WINCE port. Because we do share much of Torch Mobile's code, I think two ports are not really competiting. Regards, Kwang Yul Seo On Thu, Aug 27, 2009 at 3:36 PM, Eric Seidel e...@webkit.org wrote: I didn't realize there were 2 competing WINCE ports?? On Wed, Aug 26, 2009 at 10:00 PM, Adam Barth aba...@webkit.org wrote: In trying to help out with the review queue, I noticed this comment: https://bugs.webkit.org/show_bug.cgi?id=28095#c16 [[ Comment #16 From George Staikos 2009-08-26 09:17:28 PDT (-) [reply] In case you still don't understand, the reason your patch hasn't got r+ so far is because your company is openly and willfully violating the WebKit license and some copyrights. This is not welcome, and I don't think WebKit wants contributions of any sort from those who are violating the license. ]] Is the WINCE port in a bad standing of some sort, or can reviews of WINCE patches proceed as normal? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Documentation on internals of WebKit
Hi, There are some articles and talks on WebKit (or Chromium) internals. * WebCore Rendering http://webkit.org/blog/114/webcore-rendering-i-the-basics/ http://webkit.org/blog/115/webcore-rendering-ii-blocks-and-inlines/ http://webkit.org/blog/116/webcore-rendering-iii-layout-basics/ http://webkit.org/blog/117/webcore-rendering-iv-absolutefixed-and-relative-positioning/ http://webkit.org/blog/118/webcore-rendering-v-floats/ * Chromium Tech Talks http://blog.chromium.org/2009/04/chromium-tech-talks.html * SquirrelFish http://webkit.org/blog/189/announcing-squirrelfish/ http://webkit.org/blog/214/introducing-squirrelfish-extreme/ http://webkit.org/specs/squirrelfish-bytecode.html http://blog.mozilla.com/dmandelin/2008/06/03/squirrelfish/ Regards, Kwang Yul Seo 2009/7/14 Aneesh Bhasin contact.ane...@gmail.com: Hi All, I am sure this has been asked before but I cannot seem to find anything related to it : Is there any documentation related to the internals (and not just external APIs) of webkit ? e.g. - regarding how javascript is parsed/executed, block-level diagram of the source and other such things which could help a developer to get started on adding features in webkit ? Also, is there any good resource that explains the working of a browser engine in some detail (e.g. what steps are involved from parsing a page to actually displaying it on screen) ? Thanks in advance for the help. Regards, Aneesh ___ 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] WebCore architecture for persistent cache
Hi, It depends on each HTTP backend. Currently, libcurl does not provide HTTP cache, so you should implement HTTP cache by yourself. Or you can use other HTTP backend which provides persistent HTTP cache. Regards, Kwang Yul Seo 2009/6/17 Jeremy Serdin jser...@gmail.com: Hi all I'm trying to implement a persistent cache for WebCore with libcurl. I'm looking for some documents about webcore architecture in order to implement it in a right way. Can somebody help me? Thx, jser...@gmail.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Coding convention of constants
Hi, It seems that there are three coding styles regarding static const int constants. [1] rendering/RenderImage.cpp static const int maxAltTextWidth = 1024; static const int maxAltTextHeight = 256; [2] rendering/RenderVideo.cpp (prefixed with c) static const int cDefaultWidth = 300; static const int cDefaultHeight = 150; [3] storage/SQLTransaction.cpp (start with a capital letter) static const int DefaultQuotaSizeIncrease = 1048576; http://webkit.org/coding/coding-style.html WebKit Coding Style Guidelines does not mention this issue. All 3 styles are acceptable? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coding convention of constants
I found another style which starts with k. [4] platform/chromium/PopupMenuChromium.cpp static const int kMaxVisibleRows = 20; static const int kMaxHeight = 500; static const int kBorderSize = 1; static const TimeStamp kTypeAheadTimeoutMs = 1000; 2009/7/9 KwangYul Seo kwangyul@gmail.com Hi, It seems that there are three coding styles regarding static const int constants. [1] rendering/RenderImage.cpp static const int maxAltTextWidth = 1024; static const int maxAltTextHeight = 256; [2] rendering/RenderVideo.cpp (prefixed with c) static const int cDefaultWidth = 300; static const int cDefaultHeight = 150; [3] storage/SQLTransaction.cpp (start with a capital letter) static const int DefaultQuotaSizeIncrease = 1048576; http://webkit.org/coding/coding-style.html WebKit Coding Style Guidelines does not mention this issue. All 3 styles are acceptable? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Javascript window.open()
Hi, Look at the allowPopUp() function in bindings/js/JSDOMWindowBase.cpp You can disable window.open() in settings. Check the Settings::setJavaScriptCanOpenWindowsAutomatically. If you are using QT, you can do it with QWebSettings. Regards, Kwang Yul Seo On Thu, Jun 18, 2009 at 1:45 AM, Zongheng Zhouzongheng.z...@gmail.com wrote: Hi, I am using the QT port of webkit. Instead of doing anything else for the Javascript 's window.open(), I only want to log the URL being requested. Can anybody tell me how I can change the behavior of the window.open? Thanks, ___ 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] JPEG2000 support
Hi, Does WebKit support JPEG2000? Some web pages say so. http://echoone.com/filejuicer/formats/jp2 However, I can't find JPEG2000 decoder in WebCore/platform/image-decoders. What is the JPEG2000 decoder? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JPEG2000 support
Hi, You mentioned that WebKit uses Core Graphics frameworks on Mac OS X and Windows. Does this mean that there is a Core Graphics Windows port? Regards, Kwang Yul Seo On Sun, Jul 6, 2008 at 10:08 PM, David Kilzer [EMAIL PROTECTED] wrote: On Sun, 7/6/08, KwangYul Seo [EMAIL PROTECTED] wrote: Does WebKit support JPEG2000? Some web pages say so. http://echoone.com/filejuicer/formats/jp2 However, I can't find JPEG2000 decoder in WebCore/platform/image-decoders. What is the JPEG2000 decoder? It depends on the platform. WebKit uses the Core Graphics (CG) framework with Apple's Safari web browser on Mac OS X and Windows, not the decoders in the WebCore/platform/image-decoders directory. Thus Safari does support the JPEG2000 format, although there is currently one bug open on bugs.webkit.org about it: JPEG 2000 images display intermittently https://bugs.webkit.org/show_bug.cgi?id=8754 I'm not sure about other platforms. I'd guess that if there isn't a decoder for JPEG2000 in WebCore/platform/image-decoders then it's not currently supported. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SquirrelFish Peformance
Hi, I read several articles on SquirrelFish performance. http://webkit.org/blog/189/announcing-squirrelfish/ http://www.satine.org/archives/2008/06/03/squirrelfish-is-faster-than-tamarin/ http://summerofjsc.blogspot.com/2008/06/squirrelfish-has-landed.html I was impressed with the performance improvements in the recent work of SquirrelFish. After reading those articles, I have two questions regarding SquirrelFish. 1) Bytecode size Is SquirrelFish bytecode compact? How much size reduction can I expect from normal JS source code? 2) Compile speed I see the overall performance of SuqirrelFIsh is quite impressive. However, I want to know how long it takes to compile JavaScript source code to bytecode vs. how long it takes to execute the bytecode. I guess it is much faster than JIT compiler, but I could not find the exact number. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Patents on WebKit?
Hello, Is there any possibility that I can accidentally infringe the patents of Apple if I create a browser based on WebKit? I know WebKit is licensed under LGPLv2, but it does not guarantee that the patents of Apple are automatically granted. So I am a bit worried. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit Performance
Hello, I am playing with WebKit's HTML parsing/rendering code to improve the performance ob WebKit. Now I wonder how I can measure the performance of WebKit. I know that I can test it anyway with a few sample HTML pages, but I want to know if there exist any standarized test suites or benchmarks. Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
