Re: [webkit-dev] Modern image formats for WebKit
Are there no existing libraries that can be conditionally linked with for supporting these formats? In the long term, it seems like bad design to have WebKit have its own custom decoders. Yes. there are of course. libwebp, libjxr are available on linux based systems and also seem available on mac and Windows. [1] Both are BSD license so that there is no license issue to port them for any platforms if necessary. I’m not telling about inventing new wheels for them, but adding a kind of a glue layer in webkit as png, gif and png supports do. ;) (e.g PNGImageDecoder.* JPEGImageDecoder.*) [1] https://developers.google.com/speed/webp/download https://developers.google.com/speed/webp/download https://jxrlib.codeplex.com/releases/view/107208 https://jxrlib.codeplex.com/releases/view/107208 https://packages.debian.org/wheezy/webp https://packages.debian.org/wheezy/webp https://packages.debian.org/sid/utils/libjxr-tools https://packages.debian.org/sid/utils/libjxr-tools ChangSeok On Mar 20, 2015, at 2:21 PM, Myles C. Maxfield mmaxfi...@apple.com wrote: Are there no existing libraries that can be conditionally linked with for supporting these formats? In the long term, it seems like bad design to have WebKit have its own custom decoders. If that isn't an option, it seems fine to me provided that the decoders' sources are all close together (for some definition of close) and not peppered throughout WebKit. On Mar 19, 2015, at 9:38 PM, ChangSeok Oh changseok...@collabora.com wrote: Hi WebKittens. I just saw apng support landed on webkit main stream. [1] (even it works for gtk port only now) So I suddenly wonder if webkit community is getting interested in bringing other modern image formats like webp or jpeg-xr into webkit. If so, I can lend my hands for it. For webp support, as you know, we can reuse blink's codebase. [2] For jpeg-xr supprot, I have a rough sketch for it [3] (it might be outdated or not fit tot of webkit though, bringing it to webkit is just a piece of cake. ;)) My intention is not to argue which format is better, just to ask community's thoughts, preferences or like that. [1] https://bugs.webkit.org/show_bug.cgi?id=17022 [2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cppq=webpimasq=package:chromiuml=1 [3] http://cgit.collabora.com/git/user/kevino/Blink.git/commit/?h=jxr-supportid=2ac58312a5aae502aacc1c55c0bfdff767ab82a2 BR. -- ChangSeok ___ 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] WebCore/platform standalone library
Low-level Object Library. This sounds good to me. Something prefixed “NEW” could not be new forever. ;) If I suggest one.. how about WAFL? WebKit(or WebCore) Abstraction Framework Library(or Layer) It should sound sweet like waffle =) ChangSeok On Mar 21, 2015, at 3:26 AM, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com mailto:eocon...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. General Independent Framework (pronounced jiff, of course). Low-Level Abstract Platform would also be a logical choice. Low-level Object Library. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev 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] WebCore/platform standalone library
Platform Interface and Testing Abstraction. - R. Niwa *P*latform *A*bstract *I*nterface ? Sound like delicious pie :) Gyuyoung On Sat, Mar 21, 2015 at 2:18 AM, Ryosuke Niwa rn...@webkit.org wrote: On Friday, March 20, 2015, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote: On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. - R. Niwa -- - R. Niwa ___ 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] Modern image formats for WebKit
So this is a really a question for people working on other active ports like the EFL and GTK ones. Are there other libraries that you could use for image decoding, or do you still want to keep and maintain a WebKit copy of these image decoders? Maybe the latter one. I’m not sure what you meant other libraries here if they are not libwebp nor libjxr. I found webp has been supported by gtk elf ports already. At least WebPImageDecoder.cpp is a build target for those ports. JXR support would be a same shape with webp support, i. e adding a glue layer JPEGXRImageDecoder.cpp/h and linking libjxr.so. ChangSeok On Mar 21, 2015, at 6:39 AM, Darin Adler da...@apple.com wrote: We should consider whether to keep the image format decoders in the WebKit tree or not. Dave Hyatt originally created this when we first were planning the Apple Windows port of WebKit, but in the end we chose to not use them for the Windows port. They aren’t used in the Windows port nor in the Mac or iOS ports; for all of those we use a separate image decoding library. So this is a really a question for people working on other active ports like the EFL and GTK ones. Are there other libraries that you could use for image decoding, or do you still want to keep and maintain a WebKit copy of these image decoders? — Darin ___ 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] Running new/modified tests on EWS bots
Hi, Though I really like to support to run tests on EWS like Mac port, it can often block to land a patch if tests on EFL or GTK aren't green. So I think we need to find methods which don't annoy patch owner or reviewer. In this light, if we're able to check if there is different between last test result and new test result with a patch as Carlos suggested, it seems to be more realistic approach. If someone tries to support it, I will also help to try it If I can. Gyuyoung. On Fri, Mar 20, 2015 at 2:41 AM, Carlos Alberto Lopez Perez clo...@igalia.com wrote: On 19/03/15 16:46, youenn fablet wrote: Hi, Related to the webkit contributor meeting discussion related to ports, I would find it useful if EWS bots (gtk, efl, win, ios) were running the tests that are modified/created by a patch. The idea would be to turn yellow the port bubble whenever one of these tests do not pass. Results would be uploaded to bugzilla. This would give an incentive for patch developers to try fixing the tests on these ports. That may reduce (slightly? noticeably?) port maintainers gardening effort. That would also be valuable when importing test suites. Any potential issue? objection to move that forward? Anyone willing to help? Thoughts? I think that having an EWS running only the tests that the patch touches is of limited value because a patch can break unrelated tests. However running all the tests requires to have the tree green and this is not possible for GTK or EFL because it will require more manpower than the currently available. An idea that comes to mind for running all the tests without requiring to have the tree green is the following: 1) EWS either run all the tests without the patch or download from https://build.webkit.org/results the results from the bot for the revision if they are available. 2) EWS run all the tests with the patch. 3) EWS gets the diff from 1. and 2. 4) EWS runs only the tests that broke from 1 to 2 several times, in order to discard the ones that are flaky and only report the ones that on every run fail now. If I'm not overlooking something, I think that this would allow to identify what tests a given patch breaks and it won't require to have the tree green, neither it will be affected by flaky tests. ___ 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] Running new/modified tests on EWS bots
On Fri, Mar 20, 2015 at 7:21 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: Though I really like to support to run tests on EWS like Mac port, it can often block to land a patch if tests on EFL or GTK aren't green. So I think we need to find methods which don't annoy patch owner or reviewer. In this light, if we're able to check if there is different between last test result and new test result with a patch as Carlos suggested, it seems to be more realistic approach. If someone tries to support it, I will also help to try it If I can. EWS does this already (or at least attempts to do so). Of course, it could still fail if there are flaky tests that aren't marked as such in the test expectations. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
Reusable Os Fitting Layer antti On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. General Independent Framework (pronounced jiff, of course). Low-Level Abstract Platform would also be a logical choice. Low-level Object Library. Simon ___ 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] WebCore/platform standalone library
On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. General Independent Framework (pronounced jiff, of course). Low-Level Abstract Platform would also be a logical choice. Low-level Object Library. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. General Independent Framework (pronounced jiff, of course). Low-Level Abstract Platform would also be a logical choice.___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Friday, March 20, 2015, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com javascript:; wrote: On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com javascript:; wrote: This almost makes me want to suggest a jokey name for Platform. I can't off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. - R. Niwa -- - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Fri, Mar 20, 2015 at 9:56 AM, Simon Fraser simon.fra...@apple.com wrote: On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote: On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Web Utility Belt With Useful Behavior. Simon ___ 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] WebCore/platform standalone library
On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote: New System Framework for WebCore This! -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote: On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebCore/platform standalone library
On Mar 20, 2015, at 11:40 AM, Antti Koivisto koivi...@iki.fi wrote: Reusable Os Fitting Layer …Containing Opensource Platform Types, Events, and Resources. -Jer antti On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser simon.fra...@apple.com mailto:simon.fra...@apple.com wrote: On Mar 20, 2015, at 11:03 AM, Edward O'Connor eocon...@apple.com mailto:eocon...@apple.com wrote: This almost makes me want to suggest a jokey name for Platform. I can’t off the top of my head think of a good expansion of OMG, though. Or BBQ. I am not a pro at this, but here are a few tries: Lower-level Object Library. Algorithm Reuse Framework. New Framework for WebCore, New System Framework for WebCore. Platform Obfuscation Source. Platform Interface and Testing Abstraction. General Independent Framework (pronounced jiff, of course). Low-Level Abstract Platform would also be a logical choice. Low-level Object Library. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev 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 smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Modern image formats for WebKit
We should consider whether to keep the image format decoders in the WebKit tree or not. Dave Hyatt originally created this when we first were planning the Apple Windows port of WebKit, but in the end we chose to not use them for the Windows port. They aren’t used in the Windows port nor in the Mac or iOS ports; for all of those we use a separate image decoding library. So this is a really a question for people working on other active ports like the EFL and GTK ones. Are there other libraries that you could use for image decoding, or do you still want to keep and maintain a WebKit copy of these image decoders? — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Modern image formats for WebKit
On Mar 20, 2015, at 2:39 PM, Darin Adler da...@apple.com wrote: Dave Hyatt originally created this when we first were planning the Apple Windows port of WebKit, but in the end we chose to not use them for the Windows port. They aren’t used in the Windows port nor in the Mac or iOS ports; for all of those we use a separate image decoding library. So this is a really a question for people working on other active ports like the EFL and GTK ones. Are there other libraries that you could use for image decoding, or do you still want to keep and maintain a WebKit copy of these image decoders? The WinCairo and GTK ports definitely use these image decoders. I think the EFL port does as well, but I’m not sure. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
