Re: [webkit-dev] Misplaced files
On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Misplaced files
On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. Thanks, Adam How about just moving everything into WebCore/storage? This is all storage-related stuff. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Misplaced files
On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote: On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. Thanks, Adam How about just moving everything into WebCore/storage? This is all storage-related stuff. I think the File API is large enough to deserve its own directory. In fact, it might be worth splitting up the remaining contents of the storage directory too. It is confusing to have large but almost entirely separate APIs all piled into one directory. It is true they are all storage-related, but that is a pretty broad theme, and LocalStorage, SQL Storage, Indexed DB and File API have little or no interaction with each other. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] We need OwnPtrHashMap
On Aug 29, 2010, at 9:34 PM, Maciej Stachowiak wrote: On Aug 29, 2010, at 9:14 PM, Maciej Stachowiak wrote: Yet another possibility is to use a hash to do the de-duping instead of sorting; I can't tell from context if the sorting is needed for any purpose other than subsequent de-duping. Turns out this doesn't work - the CSS Media Queries spec specifically requires serializing in sorted order and we have a test to that effect: http://dev.w3.org/csswg/cssom/#serializing-media-queries https://bugs.webkit.org/show_bug.cgi?id=39220 So it's down to violating the type system or writing my own sort. OK, you silently guilted me into writing a non-copying sort function. https://bugs.webkit.org/show_bug.cgi?id=44874 - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] skipping tests on Chromium
On Aug 30, 2010, at 8:59 AM, Dimitri Glazkov wrote: We never had platform/chromium/Skipped, as far as I know. Ah, I saw that platform/chromium/Skipped was removed in r66261 and assumed it was a change. Instead, we use the expectations file: http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt Instead of skipping tests, we still run them, but expect them to fail. This allows for both being able to see how the test fails and pulling down baselines when it just needs to be updated. What is the correct METADATA for a new media test that doesn't apply to Chromium (it is for a QuickTime specific behavior)? I think the test will fail because it uses a movie you probably don't support, so filing a bug seems like unnecessary busy work. I think the test will time out but I don't know so what is the correct EXPECTATIONS? eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] skipping tests on Chromium
// Doesn't apply to Chromium (QuickTime-specific behavior) WONTFIX SKIP : test/name = TIMEOUT :DG On Mon, Aug 30, 2010 at 9:43 AM, Eric Carlson eric.carl...@apple.com wrote: On Aug 30, 2010, at 8:59 AM, Dimitri Glazkov wrote: We never had platform/chromium/Skipped, as far as I know. Ah, I saw that platform/chromium/Skipped was removed in r66261 and assumed it was a change. Instead, we use the expectations file: http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txt Instead of skipping tests, we still run them, but expect them to fail. This allows for both being able to see how the test fails and pulling down baselines when it just needs to be updated. What is the correct METADATA for a new media test that doesn't apply to Chromium (it is for a QuickTime specific behavior)? I think the test will fail because it uses a movie you probably don't support, so filing a bug seems like unnecessary busy work. I think the test will time out but I don't know so what is the correct EXPECTATIONS? eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit2 SharedSecondaryProcess model
Hi Balazs, Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles. -Sam On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen k...@inf.u-szeged.hu wrote: Hi all! I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that. Cheers! Balazs Kelemen ___ 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] Accelerated 2D Tesselation Implementation
On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote: On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher da...@chromium.org wrote: On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth aba...@webkit.org wrote: On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin cmar...@apple.com wrote: That's why I still think this should all go into a branch for now. It will help us all see the results without having to deal with the issues of (2) right now. An alternative to a branch is to use a run-time setting. That worked well for the HTML5 parser project. If there's a clean abstraction boundary in the code, we can use that as the branch point for the setting. The advantage of using a run-time setting is that you can leverage all the tools for working on trunk (including code reviews, etc) but you can avoid disturbing the vast majority of other developers while your feature bakes. Adam Such a runtime setting already exists for toggling accelerated canvas 2d on and off. This GPU based path rendering support is initially only going to be hooked in to the accelerated 2D canvas implementation, which since it's already covered by this run-time flag will not disturb other developers. I am going to substantially restructure the code based on feedback and submit new patches, but still against trunk. Given all the discussion that has gone on, I agree that trunk is the right place to do this. But I remain concerned about antialiasing. On that subject. If you were to have to do multi-sampling to solve the AA problem, does it make sense to skip the anti-aliasing on the edges of the spline triangles? Would that buy any performance? - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accelerated 2D Tesselation Implementation
On Mon, Aug 30, 2010 at 1:10 PM, Chris Marrin cmar...@apple.com wrote: On Aug 30, 2010, at 11:56 AM, Kenneth Russell wrote: On Sat, Aug 28, 2010 at 12:36 PM, Darin Fisher da...@chromium.org wrote: On Sat, Aug 28, 2010 at 11:32 AM, Adam Barth aba...@webkit.org wrote: On Sat, Aug 28, 2010 at 7:44 AM, Chris Marrin cmar...@apple.com wrote: That's why I still think this should all go into a branch for now. It will help us all see the results without having to deal with the issues of (2) right now. An alternative to a branch is to use a run-time setting. That worked well for the HTML5 parser project. If there's a clean abstraction boundary in the code, we can use that as the branch point for the setting. The advantage of using a run-time setting is that you can leverage all the tools for working on trunk (including code reviews, etc) but you can avoid disturbing the vast majority of other developers while your feature bakes. Adam Such a runtime setting already exists for toggling accelerated canvas 2d on and off. This GPU based path rendering support is initially only going to be hooked in to the accelerated 2D canvas implementation, which since it's already covered by this run-time flag will not disturb other developers. I am going to substantially restructure the code based on feedback and submit new patches, but still against trunk. Given all the discussion that has gone on, I agree that trunk is the right place to do this. But I remain concerned about antialiasing. On that subject. If you were to have to do multi-sampling to solve the AA problem, does it make sense to skip the anti-aliasing on the edges of the spline triangles? Would that buy any performance? Multisampling doesn't handle the pixels covering the cubic curves. The fragment shader is only run once per pixel, so to get antialiasing for these regions with this algorithm, it's necessary to compute the distance function to the curve in the shader. -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Misplaced files
On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. There are some more files... I'll make a cl to move them to WebCore/fileapi. Thanks, Thanks, 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] Colors
Hi, Looking Webkit color class(WebCore/platform/graphics/Color.*) all the colours format are always converted to rgb/rgba format. But Qt for example can handle many kind of colors like hsl, cmyk and rgba (all supported by webkit). is There any kind of reason to always convert colors to rgba? Theses converts could not be used just like a fallback when the graphics api does not have support for these formats? Igor ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Colors
Hello, yeah. Webkit supporting ICC profiles could be a good real case. Igor 2010/8/30 Darin Adler da...@apple.com: Is there any real world problem changing this would solve? If not, the current approach works and is efficient since a color takes just a 32-bit integer plus one more bit to store. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Colors
Hello, 2010/8/30 Darin Adler da...@apple.com: On Aug 30, 2010, at 5:51 PM, Igor Trindade Oliveira wrote: WebKit supporting ICC profiles could be a good real case. I think we will want that feature eventually. Changing the Color class would probably not be needed, though, for that. If you start working on that kind of feature, I can help you figure out what it takes, and if it turns out I’m wrong we are definitely open to changing the class design. We won’t just change the class based on “Why not?” -- Darin There are some pieces from webkit i looked to do this work. Already there is an initial ColorSpace enum in Webkit(WebCore/platform/graphics/ColorSpace.h) and a color transformation(SRGBA-RGBA) in WebCore/platform/graphics/ImageBuffer.cpp. I was looking first in color because it is used by css parserColorFromValue and some kind of colors(gammut) are not correctly converted to CMYK(they are out of gammut). Igor ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DumpRenderTree crashes because of JavaPluginCocoa
Hi, I encountered a problem yesterday that all layout tests crashed on Mac Snow Leopard. DumpRenderTree produces the following output when run from command line: $ time ./DumpRenderTree 2010-08-31 10:39:25.847 DumpRenderTree[26725:903] The requested plugin at (/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home) cannot be loaded on this system. Using CurrentJDK instead. 2010-08-31 10:39:25.849 DumpRenderTree[26725:903] An uncaught exception was raised 2010-08-31 10:39:25.849 DumpRenderTree[26725:903] *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: WebPluginMIMETypes) 2010-08-31 10:39:25.850 DumpRenderTree[26725:903] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: WebPluginMIMETypes)' *** Call stack at first throw: ( 0 CoreFoundation 0x7fff88a8acc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x7fff84c620f3 objc_exception_throw + 45 2 CoreFoundation 0x7fff88a8aae7 +[NSException raise:format:arguments:] + 103 3 CoreFoundation 0x7fff88a8aa74 +[NSException raise:format:] + 148 4 Foundation 0x7fff8459ea9b -[NSCFDictionary setObject:forKey:] + 227 5 JavaPluginCocoa 0x00010519fbc4 BP_CreatePluginMIMETypesPreferences + 162 6 WebKit 0x0001003da00e -[WebBasePluginPackage createPropertyListFile] + 46 7 WebKit 0x0001003d9fcc -[WebBasePluginPackage pListForPath:createFile:] + 92 8 WebKit 0x0001003db5b7 -[WebBasePluginPackage getPluginInfoFromPLists] + 1975 9 WebKit 0x000100459182 -[WebPluginPackage initWithPath:] + 354 10 WebKit 0x0001003da073 +[WebBasePluginPackage pluginWithPath:] + 51 11 WebKit 0x00010045797d -[WebPluginDatabase(Internal) _scanForNewPlugins] + 429 12 WebKit 0x000100458344 -[WebPluginDatabase refresh] + 100 13 WebKit 0x00010045824d +[WebPluginDatabase sharedDatabase] + 157 14 DumpRenderTree 0x0001cfda _Z14dumpRenderTreeiPPKc + 610 15 DumpRenderTree 0x0001d57f main + 94 16 DumpRenderTree 0x00011fe4 start + 52 ) terminate called after throwing an instance of 'NSException' Abort trap (core dumped) real 3m38.911s user 0m0.042s sys 0m13.951s === I tried to remove /Library/Internet Plug-Ins/JavaPluginCocoa.bundle, then DumpRenderTree worked. Anyone has encountered the same problem and/or has better solution? BTW, why is crash reporting for DumpRenderTree so slow (3.5 minutes)? Thanks, Xianzhu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Colors
30.08.2010, в 17:45, Darin Adler написал(а): Is there any real world problem changing this would solve? If not, the current approach works and is efficient since a color takes just a 32-bit integer plus one more bit to store. Full support for CMYK and other formats could make printing better, see https://bugs.webkit.org/show_bug.cgi?id=12205. But we'd need to pass these to printing layer unchanged, as opposed to letting color matching convert them to RGB. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
