Re: [webkit-dev] Testing feature suggestion: animation/interaction pixel-results on the fly
On Sat, Feb 9, 2013 at 5:35 PM, Dirk Pranke dpra...@chromium.org wrote: Perhaps -- and this is a tangent to this thread -- we could also investigate ways of writing tests that did render pngs but told NRWT to ignore them (e.g., dumpAsTextAndIgnoredImage() or something), or conveyed which parts of the image were important ... What's the point of that? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
On 02/07/2013 01:48 AM, Maciej Stachowiak wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. I agree with that, but I still don't see why should LChar be unsigned since it is a character and not a raw byte. It would be somewhat more convenient when dealing with string literals or traditional C libraries. I you agree I could investigate in the refactoring work. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
On Sun, Feb 10, 2013 at 10:03 AM, Balazs Kelemen kbal...@webkit.org wrote: On 02/07/2013 01:48 AM, Maciej Stachowiak wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. I agree with that, but I still don't see why should LChar be unsigned since it is a character and not a raw byte. It would be somewhat more convenient when dealing with string literals or traditional C libraries. I you agree I could investigate in the refactoring work. Because LChar is often (always?) UTF-8 encoded, the individual encoding units of which are 0x00 through 0xFF. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
Short answer, yes. On Feb 10, 2013, at 9:14 AM, Glenn Adams gl...@skynav.com wrote: Because LChar is often (always?) UTF-8 encoded, the individual encoding units of which are 0x00 through 0xFF. Close. LChar is always Latin-1 encoded. That’s what the L is for. That’s the same thing as the first 256 code points in Unicode. If LChar could possibly be a signed byte, then we’d have to cast to an unsigned byte at every call site where we are storing an LChar in a UChar; very easy to get that wrong. Since LChar is an unsigned type we can simply do a normal assignment and we get correct behavior. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak m...@apple.com wrote: Hi Peter, On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote: On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote: There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can. For what my opinion is worth (probably near zero for a lot of you), I would like to see you guys merge sooner rather than later, even if it leads to awkwardness that needs cleanup. Over the years there has been a nonzero amount of friction due to the iOS port not being upstreamed, and I think it would be beneficial to WebKit as a whole to fix that sooner rather than later. And it seems more likely to me that upstream first, then decide how to re-architect as needed is going to result in high-quality discussions and designs, as opposed to figure out in private how to re-architect before upstreaming, which runs the risk of just never bothering to upstream at all. There is real compromise, and perhaps humility, needed from all sides to make such a task successful. I am reminded of Eric's recent email where he pleaded for more of an explicit effort to civility towards each other. Perhaps this is an opportunity for us to practice that effort. I really appreciate you saying that. I feel the same way. For years we've been saying that we need to fix N different things before upstreaming, and in the end we concluded that it was just delaying us from upstreaming at all. And we concluded that cleaning up some of the questionable choices in the open would lead to a better final outcome. +1. I think that allowing the V8 bindings into the tree is a fairly good analogy to this situation (although it's not exactly the same). The point is that it did put a burden on the rest of the project at the benefit of getting Chromium folk working on core code and giving the ability to discuss trade-offs more directly by looking at the code in question. At the same time, I think some scrutiny of what we are doing is fair, so I'll try to explain the threading issues in a bit more detail to the extent I can. Regards, Maciej ___ 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] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Sun, Feb 10, 2013 at 10:39 AM, Ojan Vafai o...@chromium.org wrote: On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak m...@apple.com wrote: Hi Peter, On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote: On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote: There are certainly pros and cons to merging. It would be great get input from the broader WebKit community on the tradeoff of merging sooner vs avoidance of weird legacy code in the main tree. In the meantime, we'll stick to merging things that are not overly controversial as much as we can. For what my opinion is worth (probably near zero for a lot of you), I would like to see you guys merge sooner rather than later, even if it leads to awkwardness that needs cleanup. Over the years there has been a nonzero amount of friction due to the iOS port not being upstreamed, and I think it would be beneficial to WebKit as a whole to fix that sooner rather than later. And it seems more likely to me that upstream first, then decide how to re-architect as needed is going to result in high-quality discussions and designs, as opposed to figure out in private how to re-architect before upstreaming, which runs the risk of just never bothering to upstream at all. There is real compromise, and perhaps humility, needed from all sides to make such a task successful. I am reminded of Eric's recent email where he pleaded for more of an explicit effort to civility towards each other. Perhaps this is an opportunity for us to practice that effort. I really appreciate you saying that. I feel the same way. For years we've been saying that we need to fix N different things before upstreaming, and in the end we concluded that it was just delaying us from upstreaming at all. And we concluded that cleaning up some of the questionable choices in the open would lead to a better final outcome. +1. I think that allowing the V8 bindings into the tree is a fairly good analogy to this situation (although it's not exactly the same). The point is that it did put a burden on the rest of the project at the benefit of getting Chromium folk working on core code and giving the ability to discuss trade-offs more directly by looking at the code in question. Ok. I'm sold. I suspect we'll want to move the iOS port off of USE(WEB_THREAD), but I can see how it's better to do that work in trunk. I wonder if it would be worth using a name like USE(DEPRECATED_WEB_THREAD) to discourage others from adopting this execution model. Thanks everyone for taking the time to discuss this issue. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
On Sun, Feb 10, 2013 at 11:38 AM, Darin Adler da...@apple.com wrote: Short answer, yes. On Feb 10, 2013, at 9:14 AM, Glenn Adams gl...@skynav.com wrote: Because LChar is often (always?) UTF-8 encoded, the individual encoding units of which are 0x00 through 0xFF. Close. LChar is always Latin-1 encoded. That’s what the L is for. That’s the same thing as the first 256 code points in Unicode. thanks for that correction If LChar could possibly be a signed byte, then we’d have to cast to an unsigned byte at every call site where we are storing an LChar in a UChar; very easy to get that wrong. Since LChar is an unsigned type we can simply do a normal assignment and we get correct behavior. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] A catalog of iOS-specific changes related to the WebThread
Here is a list all iOS-specific changes in WebCore and below that are due to the iOS WebKit threading model, from an exhaustive review of diffs to the downstream source. I'm not sure anyone needs this to make a decision any more, but it may be helpful to people to know what's coming as we merge, and to provide input about specific items if they care to. Key: - Probably has to be upstreamed for the WebThread to work in the open source tree = Probably has to be upstreamed, but only affects files specific to the iOS port and/or the Mac port + Can likely be removed before upstreaming % Can probably be removed sooner than other differences (these things are needed for a non-WebKit use on the system which is likely to go away) ? I'm not sure what status this is In WTF: - Changing WTF::MainThread to recognize either the web thread of the main thread - Changes to ThreadRestrictionVerifier to deal with web thread vs main thread - Changing the assert in StringStatics.cpp to assert the true main thread, not isMainThread() (probably not strictly necessary) - Change the StackBounds consistency check to adapt to main thread vs Web thread (this is a class used by JSC for conservative stack scanning) - Sharing of the JSC identifier table (but no locking for that) % Locking and sharing for AtomicString (possibly removable; was added to avoid a crash on exit) In JSC, one change total: - A trick to avoid creating the GC timer on the wrong thread In WebCore: - In JSDOMWindowBase.cpp, arrange for JSC to handle the Web thread correctly - A change to get ThreadGlobalData to be the same on the web thread and the main thread - ScriptDebugServer.cpp, drop and reacquire the web thread lock around a nested run loop in ScriptDebugServer - The Web thread messages the main thread about some events via WKContentObservation = The actual implementation of the Web Thread and associated locking and messaging mechanisms = Not initializing threading in SharedBufferMac.mm +initialize (to avoid initializing on the wrong thread) = Not initializing threading in WebScriptObject.mm +initialize (to avoid initializing on the wrong thread) = The iOS implementation of SharedTimer operates on the WebThread run loop and messages the WebThread = Taking the Web thread lock in an iOS-specific accessibility implementation file = Locking around the ObjC DOM wrapper cache = Schedule CFNetwork callbacks on the Web thread runloop rather than the main runloop = The iOS tile cache implementation uses locking and messaging between the web thread and main thread much like the tile cache in the open source tree does it between the main thread and the scrolling thread = CALayer implementations sometimes grab the global lock and/or message to the WebThread from the main thread (affects WebLayer, PlatformCALayer, and a special layer that exists for text tracks) = An iBooks-specific workaround to target the main thread in LayerFlushSchedulerMac = Some messaging from the web thread to the main thread due to the weird way HTML5 video is implemented on iOS, in CA-specific files = WebCoreMotionManager (a new file that does not exist upstream) uses WebThread primitives + Some places that check isMainThread() || pthread_main_np(), which I expect will not be needed with the isMainThread() change and will likely be fixed before upstreaming; we're changing isMainThread() specifically to avoid sprinkling these diffs all over WebCore + In several places, avoid asserting m_thread == currentThread() (these diffs can probably be eliminated as by introducing an isCurrentThread() function) + An iOS-specific extra ASSERT in ThreadTimers.cpp (probably not needed) + Apparently obsolete includes of WebCoreThread.h in some files (e.g. TextBreakIteratorICU.cpp) + Apparently obsolete code to include WebCoreThreadMessage.h in some generated bindings (seems unused) + Apparently obsolete code to include WebCoreThreadMessage.h in some files (e.g. DOMHTML.mm) + An iOS-specific DiskImageCache in WebCore/loader uses threading in a non-portable way - it directly uses libdispatch and messages the WebThread. We can likely either remove it or rewrite it to do its threading in a more portable way. % A mutex in FontCache.cpp around access to the font cache (needed for a non-WebKit use of WebCore that's likely to be phased out a fair bit sooner than the Web thread) ? Make ScriptController::initializeThreading a no-op (no idea why this is needed) ? Make HTMLParserScheduler yield if it is at a yield candidate point and the main thread is waiting on the web thread lock (this was done long ago for responsiveness, but we need to retest) ? A mutex to guard creation and pausing of the database thread (I don't understand why this is needed) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)
On Feb 10, 2013, at 10:48 AM, Adam Barth aba...@webkit.org wrote: Ok. I'm sold. I suspect we'll want to move the iOS port off of USE(WEB_THREAD), but I can see how it's better to do that work in trunk. We definitely want to get off the web thread over time. There's two paths by which this will start happening in the short to medium term: - We'll likely want to offer opt-in for clients to a lockless pure message-passing model (I can't share details or timelines but it's probably a good guess that it would involve WebKit2 abstractions) - We'll want to pare away as much of the web-thread-related code as we can without breaking clients that haven't migrated. Unfortunately there are public APIs on iOS that are hard to fulfill with a cleaner concurrency model so it will likely take a while to be fully rid of it. I wonder if it would be worth using a name like USE(DEPRECATED_WEB_THREAD) to discourage others from adopting this execution model. How about USE(LEGACY_WEB_THREAD) or USE(IOS_LEGACY_WEB_THREAD)? That would correctly convey that ports should not adopt it, without putting it on quite the same level as Deprecated classes that are further on the path to removal. Any new port that wants to avoid blocking the UI with web content processing should definitely *not* use the Web Thread, and instead should use the WebKit2 or Chromium architectures (possibly including the threaded models offered by those). (Also it should probably be an ENABLE, not a USE.) Thanks everyone for taking the time to discuss this issue. Likewise. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] A catalog of iOS-specific changes related to the WebThread
Hi Maciej, Thank you for taking the time to clearly enumerate these different tasks. It must have been a tedious effort, but I think the list is quite helpful in understanding the changes you are proposing. 1. The WTF changes seem like they could be easily protected by preprocessor macros to not impact other ports. 2. The WebCore ThreadGlobalData change sounds like it could be easily isolated at compile time to the iOS port. 3. Most of the WebCore changes involved CFNetwork/CALayer logic, neither of which (I believe) is used by the Chromium port. It sounds like the port most likely to be impacted by these changes would be Apple's own Mac port. Reading this list, I'm also curious why we would ever want to call pthread_main_np, given the existence of isMainThread. If we were consistent about this, the iOS one of two 'main' threads stuff would be safely encapsulated. I like the idea of getting rid of the explicit m_thread == currentThread() asserts, in favor of some form of encapsulated predicate. All in all, I think these changes seem unlikely to be harmful, and will probably prompt some useful refactoring to clean a few things up. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Can Qt use some of the common DRT code?
Hi, Today, adding a support for a new function in TestRunner requires (painfully) changing: -WebKitTestRunner. -Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry). -Chromium DRT. -Qt DRT. I think we can do much better. A first step is to have more common code in DRT. One of the differences is the way the Qt port works. Instead of using the JSC binding APIs, it uses its own JS Qt bindings. Would it be possible for Qt to move to the common code? It would make future refactoring easier as there would be one less difference to care about. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Is the wxWidgets port maintained?
Hi again, While looking into DRT changes, I notice there is zero activity on the wxWidgets implementation. Looking at WebCore/WebKit, excluding general changes, the last commit for wxWidgets is 6 months old: http://trac.webkit.org/changeset/126457 So...is the port still active? Maybe it should live outside webkit.org like the Haiku port? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] A catalog of iOS-specific changes related to the WebThread
On Feb 10, 2013, at 5:14 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Maciej, Thank you for taking the time to clearly enumerate these different tasks. It must have been a tedious effort, but I think the list is quite helpful in understanding the changes you are proposing. 1. The WTF changes seem like they could be easily protected by preprocessor macros to not impact other ports. 2. The WebCore ThreadGlobalData change sounds like it could be easily isolated at compile time to the iOS port. 3. Most of the WebCore changes involved CFNetwork/CALayer logic, neither of which (I believe) is used by the Chromium port. To clarify, essentially all of the changes are already in ifdefs in our downstream tree, and will remain so. There is no compile time impact on other ports. The main worry is that supporting this weird threading model could be a maintainability headache for the cross-platform code. The reality is that it will be some headache, but hopefully not too much. It sounds like the port most likely to be impacted by these changes would be Apple's own Mac port. Reading this list, I'm also curious why we would ever want to call pthread_main_np, given the existence of isMainThread. If we were consistent about this, the iOS one of two 'main' threads stuff would be safely encapsulated. I like the idea of getting rid of the explicit m_thread == currentThread() asserts, in favor of some form of encapsulated predicate. Yeah, I think the above two categories of changes can be fixed before merging and won't result in any diffs, ultimately. All in all, I think these changes seem unlikely to be harmful, and will probably prompt some useful refactoring to clean a few things up. Thanks for reviewing the list. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Need help regarding layouting and painting part
On Sun, Feb 10, 2013 at 10:30 PM, 85.mukesh 85.muk...@gmail.com wrote: I want to put any kind of Box2d effect on html element. These things I want to do with css extension. [...] Wrong mailing list. WebKit-dev is for the development of WebKit. If you want to make some kind of non-standard extension, try asking on webkit-help or the mailing list of the port you are using. See https://lists.webkit.org Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can Qt use some of the common DRT code?
On Mon, Feb 11, 2013 at 3:37 AM, Benjamin Poulain benja...@webkit.orgwrote: Hi, Today, adding a support for a new function in TestRunner requires (painfully) changing: -WebKitTestRunner. -Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry). -Chromium DRT. -Qt DRT. I think we can do much better. A first step is to have more common code in DRT. Another option is to add the new functionality to window.internals, and only change DRT for test code that is port specific or supposed to test a port's WebKit API. best -jochen One of the differences is the way the Qt port works. Instead of using the JSC binding APIs, it uses its own JS Qt bindings. Would it be possible for Qt to move to the common code? It would make future refactoring easier as there would be one less difference to care about. Benjamin ___ 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] Can Qt use some of the common DRT code?
On Sun, Feb 10, 2013 at 10:56 PM, Jochen Eisinger joc...@chromium.orgwrote: Today, adding a support for a new function in TestRunner requires (painfully) changing: -WebKitTestRunner. -Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry). -Chromium DRT. -Qt DRT. I think we can do much better. A first step is to have more common code in DRT. Another option is to add the new functionality to window.internals, and only change DRT for test code that is port specific or supposed to test a port's WebKit API. Isn't that what we already do? If someone intentionally choose DRT over internals, she/he is courageous :) Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can Qt use some of the common DRT code?
On Mon, Feb 11, 2013 at 8:19 AM, Benjamin Poulain benja...@webkit.orgwrote: On Sun, Feb 10, 2013 at 10:56 PM, Jochen Eisinger joc...@chromium.orgwrote: Today, adding a support for a new function in TestRunner requires (painfully) changing: -WebKitTestRunner. -Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry). -Chromium DRT. -Qt DRT. I think we can do much better. A first step is to have more common code in DRT. Another option is to add the new functionality to window.internals, and only change DRT for test code that is port specific or supposed to test a port's WebKit API. Isn't that what we already do? If someone intentionally choose DRT over internals, she/he is courageous :) I'm not sure I understand. In what cases do you then add something to DRT and need to change all of them? best -jochen Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can Qt use some of the common DRT code?
On Sun, Feb 10, 2013 at 11:20 PM, Jochen Eisinger joc...@chromium.orgwrote: I'm not sure I understand. In what cases do you then add something to DRT and need to change all of them? Take this for example: http://trac.webkit.org/changeset/130416 It does not make sense to test everything through internals. In some cases, some test go all the way through the client interfaces, to the WebKit layer, and then back. It is good such cases are tested through the test runner and not internals. Example of such APIs: -Notification. -Page Visibility. -Geolocation. Internals is awesome, but it is not an excuse to keep DRT in bad shape. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
