Re: [webkit-dev] How to deal with the difference between JS IDL and V8 IDL?
Are the IDL generators for JS and V8 same? Different. WebCore/bindings/scripts/CodeGeneratorJS.pm for JSC, and WebCore/bindings/scripts/CodeGeneratorV8.pm for V8. Though we are trying hard to make those two behaviors same:) The array syntax float[] is not supported by the JS binding IDL generator. This would be a bug. I think JSC should also support it. Would you file a bug to https://bugs.webkit.org/enter_bug.cgi?product=WebKit? On Mon, Apr 23, 2012 at 12:40 AM, xuewen xuewen.w...@torchmobile.com.cn wrote: In the file Source/WebCore/Modules/gamepad/Gamepad.idl, there are two definitions: readonly attribute float[] axes; readonly attribute float[] buttons; The array syntax float[] is not supported by the JS binding IDL generator. Are the IDL generators for JS and V8 same? If it is right for V8, how do we deal with this difference between JS binding and V8 binding? Thanks Sean Wang - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebCore's ResourceLoader
Hi everyone, I want to use the ResourceLoader (WebCore/loader), but without caching. It was possible a while ago using SubresourceLoaderClient (removed in revision 100311), but now it seems like there are no resources but CachedResources and it is not possible to do no caching for certain types of resources. When I look at the ImageLoader class (WebCore/loader/ImageLoader.cpp) the resource loading is deferred to the document's cachedResourceLoader, but the document doesn't seem to have a noncached resource loader. Is it, if at all, possible to get access to a non-caching resource loader? Up to now I investigated the following: o as far as I see, I can't get access to such a thing. o Also it is not really possible to disable caching for a certain type of resources. That would be I define my own CachedResource and overwrite a method that tells do not cache me, this is not possible. o I could manually remove the resource after loading from the cache by using the global memoryCache() accessor. But the CachedResourceLoader operates only on bare resource pointers, so simply removing it from the cache is not enough, the resource might be stored somewhere else (and in fact it is, the loader already stores a map from URLs to loaded resources) o I could declare my own resource to have the type CachedResource::RawResource. In this case the CachedResourceLoader doesn't cache it. I don't like this, since the implementation could change and decide to cache RawResources and I would have to keep track of this. All in all, my conclusion up to now is, I can't really do non-cached resource loading without extending WebCore code probably by implementing my own ResourceLoader. Is this right? Thanks in advance! Regards, bobbel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to deal with the difference between JS IDL and V8 IDL?
I think this is caused by the same cause as https://bugs.webkit.org/show_bug.cgi?id=84540. On Mon, Apr 23, 2012 at 12:48 AM, Kentaro Hara hara...@chromium.org wrote: Are the IDL generators for JS and V8 same? Different. WebCore/bindings/scripts/CodeGeneratorJS.pm for JSC, and WebCore/bindings/scripts/CodeGeneratorV8.pm for V8. Though we are trying hard to make those two behaviors same:) The array syntax float[] is not supported by the JS binding IDL generator. This would be a bug. I think JSC should also support it. Would you file a bug to https://bugs.webkit.org/enter_bug.cgi?product=WebKit? On Mon, Apr 23, 2012 at 12:40 AM, xuewen xuewen.w...@torchmobile.com.cn wrote: In the file Source/WebCore/Modules/gamepad/Gamepad.idl, there are two definitions: readonly attribute float[] axes; readonly attribute float[] buttons; The array syntax float[] is not supported by the JS binding IDL generator. Are the IDL generators for JS and V8 same? If it is right for V8, how do we deal with this difference between JS binding and V8 binding? Thanks Sean Wang - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ 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] How to deal with the difference between JS IDL and V8 IDL?
I looked the patch, they should be the same issue. I will help to verify the patch Thanks Sean Wang On 04/23/2012 04:14 PM, Ryosuke Niwa wrote: I think this is caused by the same cause as https://bugs.webkit.org/show_bug.cgi?id=84540. On Mon, Apr 23, 2012 at 12:48 AM, Kentaro Hara hara...@chromium.org mailto:hara...@chromium.org wrote: Are the IDL generators for JS and V8 same? Different. WebCore/bindings/scripts/CodeGeneratorJS.pm for JSC, and WebCore/bindings/scripts/CodeGeneratorV8.pm for V8. Though we are trying hard to make those two behaviors same:) The array syntax float[] is not supported by the JS binding IDL generator. This would be a bug. I think JSC should also support it. Would you file a bug to https://bugs.webkit.org/enter_bug.cgi?product=WebKit? On Mon, Apr 23, 2012 at 12:40 AM, xuewen xuewen.w...@torchmobile.com.cn mailto:xuewen.w...@torchmobile.com.cn wrote: In the file Source/WebCore/Modules/gamepad/Gamepad.idl, there are two definitions: readonly attribute float[] axes; readonly attribute float[] buttons; The array syntax float[] is not supported by the JS binding IDL generator. Are the IDL generators for JS and V8 same? If it is right for V8, how do we deal with this difference between JS binding and V8 binding? Thanks Sean Wang - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit2 with v8
Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] win-ews linker error
I'm writing a patch for inspector that is giving me a linker error that I'm not able to track down since I don't have a windows build setup. Bug: https://bugs.webkit.org/show_bug.cgi?id=83282 This is the build output from win-ews. http://queues.webkit.org/results/12476169 Inline for convenience: 12WebCore.lib(InspectorInstrumentation.obj) : error LNK2001: unresolved external symbol public: void __thiscall WebCore::InspectorResourceAgent::didReceiveWebSocketFrame(unsigned long,class WebCore::WebSocketFrame const ) (?didReceiveWebSocketFrame@InspectorResourceAgent@WebCore@@QAEXKABVWebSocketFrame@2@@Z) 12WebCore.lib(InspectorInstrumentation.obj) : error LNK2001: unresolved external symbol public: void __thiscall WebCore::InspectorResourceAgent::didSendWebSocketFrame(unsigned long,class WebCore::WebSocketFrame const ) (?didSendWebSocketFrame@InspectorResourceAgent@WebCore@@QAEXKABVWebSocketFrame@2@@Z) 12WebCore.lib(WebSocketChannel.obj) : error LNK2001: unresolved external symbol private: static void __cdecl WebCore::InspectorInstrumentation::didReceiveWebSocketFrameImpl(class WebCore::InstrumentingAgents *,unsigned long,struct WebCore::WebSocketFrame const ) (?didReceiveWebSocketFrameImpl@InspectorInstrumentation@WebCore@@CAXPAVInstrumentingAgents@2@KABUWebSocketFrame@2@@Z) 12WebCore.lib(WebSocketChannel.obj) : error LNK2001: unresolved external symbol private: static void __cdecl WebCore::InspectorInstrumentation::didSendWebSocketFrameImpl(class WebCore::InstrumentingAgents *,unsigned long,struct WebCore::WebSocketFrame const ) (?didSendWebSocketFrameImpl@InspectorInstrumentation@WebCore@@CAXPAVInstrumentingAgents@2@KABUWebSocketFrame@2@@Z) I can't find where the symbols for WebSocketHandshakeRequest and WebSocketHandshakeResponse are exported because WebSocketFrame would need something similar. Thanks in advance, Konrad - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCore's ResourceLoader
You can do a non-cached resource load still, I just haven't figured out where to document it. Suggestions welcome :-) It's possible via CachedRawResource. When you call CachedResourceLoader::requestRawResource(), the DataBufferingPolicy in the ResourceLoaderOptions parameter should be DoNotBufferData. This will prevent buffering of the data at both the CachedRawResource and ResourceLoader levels, and since the CachedRawResource won't have any useful data, it will also prevent caching. EventSource use this for its resource loads, albeit indirectly via DocumentThreadableLoader. Hope this helps, ~Nate On Mon, Apr 23, 2012 at 1:05 AM, Boris Brönner borisbroen...@googlemail.com wrote: Hi everyone, I want to use the ResourceLoader (WebCore/loader), but without caching. It was possible a while ago using SubresourceLoaderClient (removed in revision 100311), but now it seems like there are no resources but CachedResources and it is not possible to do no caching for certain types of resources. When I look at the ImageLoader class (WebCore/loader/ImageLoader.cpp) the resource loading is deferred to the document's cachedResourceLoader, but the document doesn't seem to have a noncached resource loader. Is it, if at all, possible to get access to a non-caching resource loader? Up to now I investigated the following: o as far as I see, I can't get access to such a thing. o Also it is not really possible to disable caching for a certain type of resources. That would be I define my own CachedResource and overwrite a method that tells do not cache me, this is not possible. o I could manually remove the resource after loading from the cache by using the global memoryCache() accessor. But the CachedResourceLoader operates only on bare resource pointers, so simply removing it from the cache is not enough, the resource might be stored somewhere else (and in fact it is, the loader already stores a map from URLs to loaded resources) o I could declare my own resource to have the type CachedResource::RawResource. In this case the CachedResourceLoader doesn't cache it. I don't like this, since the implementation could change and decide to cache RawResources and I would have to keep track of this. All in all, my conclusion up to now is, I can't really do non-cached resource loading without extending WebCore code probably by implementing my own ResourceLoader. Is this right? Thanks in advance! Regards, bobbel ___ 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] FYI: sub-pixel layout landing soon
WebKittens and Unlucky Sheriffs We intend to flip the switch on sub-pixel layout tomorrow morning PST. We apologize in advance for any breakages. See https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318 for reference, and feel free to contact Emil (eae) or me (leviw) with any questions. Happy zooming! -Emil and Levi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] PSA: Commit-queue/Cr-Linux Delays expected until EOD
run-webkit-unittests was hung on the 2 cr-linux EWS machines: https://bugs.webkit.org/show_bug.cgi?id=84611 Causing a queue overflow: http://ews-watcher.kov.eti.br/ (big red line to the sky) The CQ was unaffected, but because most patches are fast-tracked (don't get re-tested if the cr-linux-ews was green) the CQ has been riding on the tails of the cr-linux-ews and is now over-capacity while it recovers. This combined with the normal monday morning patch spike has caused delays. :) http://queues.webkit.org/queue-status/commit-queue http://queues.webkit.org/queue-status/chromium-ews Normal service should resume by EOD/tomorrow morning. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Hi Everybody!
As a first-time poster, I am sorry ahead of time for any lapses in
etiquette. I am seeking feedback for my (hopefully relatively painless
in practice compared to the alternatives - i.e. -webkit-image-set and
html5 image) proposal to solve the problem of 2x-res (double-
resolution) images with our current HTML and CSS standards for devices
with high-resolution displays, such as 3rd Generation iPads and 4th
generation iPhones and newer.
Here's what I had in mind. We add the following elements:
1) The new meta tag 'double-resolution-images' (whose value would be a
string for the double-res filename key - the often-standardized string
added to the filename for 2x assets, i.e. '_2x'), with the optional
boolean (defaulted to 'true') attribute 'assume-present', and maybe
eventually the optional attribute 'double-resolution-path' for cases
where sites store all their 2x image assets in a different directory
than their 1x images.
2) A new optional attribute to the img tag called 'double-resolution',
(possible values include 'true', 'false', a string for the double-res
filename key - the often standardized string added to the filename for
2x assets, i.e. '_2x', or 'url()' to specify a completely different
path for the 2x asset)
3) The new optional CSS properties 'background-image-2x', 'border-
image-2x' and 'list-style-image-2x' (possible values for these include
'true', 'false', a string for the double-res filename key, or 'url()').
A simple example usage of these new capabilities would be the following:
meta double-resolution-images=_2x /
The effect of adding this single line to the page would be that a user
agent that wishes to display double-res images would then attempt to
access 'filename_2x.ext' whenever it encounters an img tag like 'img
url=(filename.ext) /', or a CSS property like '.class {background-
image: url(filename.ext);}', '.class {border-image:
url(filename.ext);}' or '.class {list-style-image:
url(filename.ext);}'. For all these, in the case that the
'filename_2x.ext' file does not exist, a second request is made for
'filename.ext'.
If the bulk of the 2x-resolution images are located in a different
directory than the 1x assets, the meta tag could be extended as such:
meta double-resolution-images=_2x double-resolution-
path=2x_images/ /
Then, any img or css-image assets would be requested from '2x_images/
filename_2x.ext' instead of 'images/filename.ext'.
If a particular img tag asset or css-image asset has a '@2x' double-
resolution filename key instead of '_2x' for some reason (maybe you're
integrating with some 3rd party off-site content with a different 2x
naming convention), you could add a 'double-resolution' attribute to
its img tag, such as 'img double-resolution=@2x /', or to its css
properties, such as '.class {background-image-2x: @2x;}'.
If a particular 2x-resolution img tag asset or css-image asset is not
located in the same directory as the 1x asset, or if the filenames and/
or file formats are not identical to the 1x asset, a separate path
could be specified by doing this: 'img double-resolution=url(2x-
images/filename.ext) /', or to its css properties by doing: '.class
{background-image-2x: url(2x-images/filename.ext);}'.
In the case that a majority, but not all img and css-image assets are
available in 2x resolution, the img assets that lack a 2x version
would include the a tag such as, 'img double-resolution=false /, or
a css property such as '.class{background-image-2x: false;}'.
In the case that a majority, but not all img and css-image assets are
unavailable in 2x resolution, you would add the 'assume-present=false'
attribute to the meta tag, such as 'meta double-resolution-
images=_2x assume-present=false /', and use the 'double-resolution'
attribute to flag img assets with a double-resolution asset available,
such as 'img double-resolution=true /, and the css with '.class
{background-image-2x: true;}'.
In the case that no double-resolution image assets are available, the
meta tag can be simply omitted.
By using this approach, we avoid the need to specify the same list of
filenames varying only by 2x-res filename key for every single image
asset, which is a bunch of busy work that just seems extremely
redundant and clumsy to me. We are also able to achieve the same level
of performance for those willing to put in the extra work to flag
assets that deviate from the default setting (to minimize requests),
and we allow the flexibility to be lazy or wrong, and have the user
agent make two requests in those cases. This solution is also
completely backwards-compatible with existing browsers. We can revisit
whether or not this was really the best approach once 4x displays are
out, but it's going to save millions of collective developer-hours in
the meantime; remind me to buy future me a beer to make up for it.
As a corollary
Re: [webkit-dev] FYI: sub-pixel layout landing soon
Supporting this would be very logistically intensive and error prone. Beyond huge test expectation differences, hacking on the rendering engine could easily result in bugs in one path or the other. -Levi On Mon, Apr 23, 2012 at 2:31 PM, Adele Peterson ad...@apple.com wrote: Is there an if-def ports can use if they don't want this on by default? - Adele On Apr 23, 2012, at 2:15 PM, Levi Weintraub wrote: WebKittens and Unlucky Sheriffs We intend to flip the switch on sub-pixel layout tomorrow morning PST. We apologize in advance for any breakages. See https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318 for reference, and feel free to contact Emil (eae) or me (leviw) with any questions. Happy zooming! -Emil and Levi ___ 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] webkit2 with v8
Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemen kbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. 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] FYI: sub-pixel layout landing soon
We're not prepared to take on this big change in our ports at this time. Without an if-def, I'm not sure how we're going to coordinate flipping the switch at a time that works for everyone. - Adele On Apr 23, 2012, at 2:48 PM, Levi Weintraub wrote: Supporting this would be very logistically intensive and error prone. Beyond huge test expectation differences, hacking on the rendering engine could easily result in bugs in one path or the other. -Levi On Mon, Apr 23, 2012 at 2:31 PM, Adele Peterson ad...@apple.com wrote: Is there an if-def ports can use if they don't want this on by default? - Adele On Apr 23, 2012, at 2:15 PM, Levi Weintraub wrote: WebKittens and Unlucky Sheriffs We intend to flip the switch on sub-pixel layout tomorrow morning PST. We apologize in advance for any breakages. See https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318 for reference, and feel free to contact Emil (eae) or me (leviw) with any questions. Happy zooming! -Emil and Levi ___ 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] FYI: sub-pixel layout landing soon
If it's a global switch that ports can't opt out of, then we have to do this at a time when it wouldn't disrupt anyone's release cycle. Let's say hypothetically a vendor was going to branch from trunk and ship in two weeks (not actually the case for us, but just to make it an extreme example). It would be insane for them to take this change. So we need one of the following: (1) It needs to be compile-time switchable so that vendors who are close to shipping can turn it on to mitigate risk without having to roll back to earlier on trunk. OR (2) We need up-front buy-in from all vendors who ship from the open source tree that now is a reasonable time for them to make such a major change. Regards, Maciej On Apr 23, 2012, at 2:48 PM, Levi Weintraub wrote: Supporting this would be very logistically intensive and error prone. Beyond huge test expectation differences, hacking on the rendering engine could easily result in bugs in one path or the other. -Levi On Mon, Apr 23, 2012 at 2:31 PM, Adele Peterson ad...@apple.com wrote: Is there an if-def ports can use if they don't want this on by default? - Adele On Apr 23, 2012, at 2:15 PM, Levi Weintraub wrote: WebKittens and Unlucky Sheriffs We intend to flip the switch on sub-pixel layout tomorrow morning PST. We apologize in advance for any breakages. See https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318 for reference, and feel free to contact Emil (eae) or me (leviw) with any questions. Happy zooming! -Emil and Levi ___ 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] webkit2 with v8
On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. 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] webkit2 with v8
Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemen kbal...@webkit.org wrote: On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Hi Tom, You wrote: I am seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 image) proposal to solve the problem of 2x-res (double- resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer. webkit-dev probably isn't the best place to design new Web-facing features; in particular, there is ongoing work on this problem space in the CSS WG, the WHATWG, and elsewhere. See for instance the threads starting here http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/thread.html#34683 and here http://lists.w3.org/Archives/Public/www-style/2012Feb/thread.html#msg1103 Anybody is welcome to contribute to www-style and the whatwg list. Ted ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On what standard mailing lists have this idea been proposed or discussed?
At glance, it seems like a bad idea to add a specific element for the
double resolution images. What makes us think that someone won't come up
with 3x or 4x resolution screens in near future?
On Mon, Apr 23, 2012 at 2:44 PM, Tom Penzer tpen...@mailcan.com wrote:
1) The new meta tag 'double-resolution-images' (whose value would be a
string for the double-res filename key - the often-standardized string
added to the filename for 2x assets, i.e. '_2x'), with the optional boolean
(defaulted to 'true') attribute 'assume-present', and maybe eventually the
optional attribute 'double-resolution-path' for cases where sites store all
their 2x image assets in a different directory than their 1x images.
You mean a content attribute? It's unusual for a content attribute name to
include -.
2) A new optional attribute to the img tag called 'double-resolution',
(possible values include 'true', 'false', a string for the double-res
filename key - the often standardized string added to the filename for 2x
assets, i.e. '_2x', or 'url()' to specify a completely different path for
the 2x asset)
You mean an attribute?
3) The new optional CSS properties 'background-image-2x', 'border-image-2x'
and 'list-style-image-2x' (possible values for these include 'true',
'false', a string for the double-res filename key, or 'url()').
Again, what makes us think that we won't need background-image-3x,
background-image-4x, ... in the future? Or maybe background-image-7.5x?
A simple example usage of these new capabilities would be the following:
meta double-resolution-images=_2x /
The effect of adding this single line to the page would be that a user
agent that wishes to display double-res images would then attempt to access
'filename_2x.ext' whenever it encounters an img tag like 'img
url=(filename.ext) /', or a CSS property like '.class {background-image:
url(filename.ext);}', '.class {border-image: url(filename.ext);}' or
'.class {list-style-image: url(filename.ext);}'. For all these, in the
case that the 'filename_2x.ext' file does not exist, a second request is
made for 'filename.ext'.
Not all images end with .ext. It could be generated by a server-side
script for example. What do we do with them?
By using this approach, we avoid the need to specify the same list of
filenames varying only by 2x-res filename key for every single image asset,
which is a bunch of busy work that just seems extremely redundant and
clumsy to me. We are also able to achieve the same level of performance for
those willing to put in the extra work to flag assets that deviate from the
default setting (to minimize requests), and we allow the flexibility to be
lazy or wrong, and have the user agent make two requests in those cases.
This solution is also completely backwards-compatible with existing
browsers. We can revisit whether or not this was really the best approach
once 4x displays are out, but it's going to save millions of collective
developer-hours in the meantime; remind me to buy future me a beer to make
up for it.
A much better solution would be adding a new http request header, and let
the server send back back double resolution images.
Quite frankly, I don't think we're interested in implementing this proposal.
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Process for importing third party tests
At the recent WebKit Contributors Meeting, a process was drafted for importing third party tests into WebKit. I created a wiki page that captures the process that we came up with here: http://trac.webkit.org/wiki/ImportingThirdPartyTests We'd like to get more input from the community on all aspects of this process. Please review and lets discuss further. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On Apr 23, 2012, at 3:42 PM, Ryosuke Niwa rn...@webkit.org wrote: On what standard mailing lists have this idea been proposed or discussed? I have not yet submitted to w3.org public-html or public-html-comments as I wanted to get the take of the webkit community first, since you guys are particularly interested in this issue. Again, what makes us think that we won't need background-image-3x, background-image-4x, ... in the future? Or maybe background-image-7.5x? Then maybe a meta 'image-scaling' attribute rather than 2x-specific. The main point is to avoid requiring each image path for the different scales to be explicitly written, when it's likely a standardized variation from the 1x image file path. We should explore ways to codify those variations, instead of making our lives hard. Not all images end with .ext. It could be generated by a server-side script for example. What do we do with them? Well, if you could think of a way to codify that request in a standardized way, that would certainly be something to consider. Do you think this type of system could be extended to account for such a situation? By using this approach, we avoid the need to specify the same list of filenames varying only by 2x-res filename key for every single image asset, which is a bunch of busy work that just seems extremely redundant and clumsy to me. We are also able to achieve the same level of performance for those willing to put in the extra work to flag assets that deviate from the default setting (to minimize requests), and we allow the flexibility to be lazy or wrong, and have the user agent make two requests in those cases. This solution is also completely backwards-compatible with existing browsers. We can revisit whether or not this was really the best approach once 4x displays are out, but it's going to save millions of collective developer-hours in the meantime; remind me to buy future me a beer to make up for it. A much better solution would be adding a new http request header, and let the server send back back double resolution images. Quite frankly, I don't think we're interested in implementing this proposal. - Ryosuke If that means we don't need to go through and fill out every single file path for every different scale image if there's a file naming system in place, then I'm all for it. I'm just scared we're needlessly making our lives harder than they should be. -Tom P. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] FYI: sub-pixel layout landing soon
Given the concerns brought up, we'll be adding an ENABLE_SUBPIXEL_LAYOUT flag that will default to on. Turning this off will continue to use FractionalLayoutUnits, but the fraction will switch to 1/1 from the default of 1/60. This should be ready in the near future, and we'll provide another heads-up when we're again ready to land. -Levi On Mon, Apr 23, 2012 at 2:55 PM, Maciej Stachowiak m...@apple.com wrote: If it's a global switch that ports can't opt out of, then we have to do this at a time when it wouldn't disrupt anyone's release cycle. Let's say hypothetically a vendor was going to branch from trunk and ship in two weeks (not actually the case for us, but just to make it an extreme example). It would be insane for them to take this change. So we need one of the following: (1) It needs to be compile-time switchable so that vendors who are close to shipping can turn it on to mitigate risk without having to roll back to earlier on trunk. OR (2) We need up-front buy-in from all vendors who ship from the open source tree that now is a reasonable time for them to make such a major change. Regards, Maciej On Apr 23, 2012, at 2:48 PM, Levi Weintraub wrote: Supporting this would be very logistically intensive and error prone. Beyond huge test expectation differences, hacking on the rendering engine could easily result in bugs in one path or the other. -Levi On Mon, Apr 23, 2012 at 2:31 PM, Adele Peterson ad...@apple.com wrote: Is there an if-def ports can use if they don't want this on by default? - Adele On Apr 23, 2012, at 2:15 PM, Levi Weintraub wrote: WebKittens and Unlucky Sheriffs We intend to flip the switch on sub-pixel layout tomorrow morning PST. We apologize in advance for any breakages. See https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318for reference, and feel free to contact Emil (eae) or me (leviw) with any questions. Happy zooming! -Emil and Levi ___ 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] Debugging With Xcode
Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. Simon Fraser helped me set up WebKitBuild on one of my machines, but I don't really know how to repeat that process. 2. Xcode tries to Re-index WebCore, seemingly every time I open WebCore.xcodeproj. This is a hour+ process on my 12-core Mac Pro! The re-indexing takes a lot of processing power, and seems to render both my machine, and Xcode largely unusable. I understand that Xcode isn't really designed for projects as large as WebCore, but we've made it work in the past, and I'm curious if anyone is still making it work? If the Apple folks have any suggestions or updates to http://www.webkit.org/building/debug.html, they would be most appreciated. :) Thanks! -eric Xcode 4.2.1 Build version 4D502 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging With Xcode
On 2012-04-23, at 18:02, Eric Seidel e...@webkit.org wrote: Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. This page was updated recently to reflect the terminology used in the current version of Xcode. The diff may provide the information you need to get this working in earlier versions of Xcode. 2. Xcode tries to Re-index WebCore, seemingly every time I open WebCore.xcodeproj. This is a hour+ process on my 12-core Mac Pro! The re-indexing takes a lot of processing power, and seems to render both my machine, and Xcode largely unusable. That's interesting. If you're seeing that with the latest released version of Xcode then I'd strongly suggest filing a bug report at http://bugreport.apple.com/ so that the Xcode folks can address it. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging With Xcode
Hi, On Mon, Apr 23, 2012 at 10:07 PM, Mark Rowe mr...@apple.com wrote: On 2012-04-23, at 18:02, Eric Seidel e...@webkit.org wrote: Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. I also didn't manage to make it work for me also. I managed to get Safari launching (after a long wait) but when running debug it doesn't stop on the breakpoints. This page was updated recently to reflect the terminology used in the current version of Xcode. The diff may provide the information you need to get this working in earlier versions of Xcode. 2. Xcode tries to Re-index WebCore, seemingly every time I open WebCore.xcodeproj. This is a hour+ process on my 12-core Mac Pro! The re-indexing takes a lot of processing power, and seems to render both my machine, and Xcode largely unusable. That's interesting. If you're seeing that with the latest released version of Xcode then I'd strongly suggest filing a bug report at http://bugreport.apple.com/ so that the Xcode folks can address it. I also noticed the same, every git pull start to re-index the entire project and my old MacBook Pro almost die away after that. I use the latest Mac App store version. Additional question : is it possible to actually build WebCore or any subproject (JSC, ...) from XCode so you could get a fancy ui for compilation issues (maybe provided you already ran once build-webkit) ? - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging With Xcode
On Mon, 23 Apr 2012 18:02:51 -0700, Eric Seidel e...@webkit.org wrote: Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. As Mark Rowe pointed out in his reply, I recently updated these instructions with respect to changes in Xcode 4.3.2. I've updated the build location instructions on the web site to mention Xcode 4.3.2 instead of Xcode 4 and landed this change in changeset 114978, http://trac.webkit.org/changeset/114978. Also, I've updated http://www.webkit.org/building/tools.html to mention the need to either run xcode-select or set the environment variable DEVELOPER_DIR to point to the developer tools directory before using the Xcode command line tools. This change was landed in changeset 114982, http://trac.webkit.org/changeset/114982. Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging With Xcode
On Apr 23, 2012, at 9:03 PM, Eric Seidel e...@webkit.org wrote: Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. Simon Fraser helped me set up WebKitBuild on one of my machines, but I don't really know how to repeat that process. 2. Xcode tries to Re-index WebCore, seemingly every time I open WebCore.xcodeproj. This is a hour+ process on my 12-core Mac Pro! The re-indexing takes a lot of processing power, and seems to render both my machine, and Xcode largely unusable. I understand that Xcode isn't really designed for projects as large as WebCore, but we've made it work in the past, and I'm curious if anyone is still making it work? If the Apple folks have any suggestions or updates to http://www.webkit.org/building/debug.html, they would be most appreciated. :) Thanks! -eric Xcode 4.2.1 Build version 4D502 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev I usually create an empty project, add the source files I care about, and then attach to the appropriate renderer process - but also use WebCore.xcodeproj directly on occasion. I run the same version as you and once ran into an infinite indexing cycle, but after a swift kick from Activity Monitor, I haven't seen it again. Xcode works great as a gdb front end for me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging With Xcode
Has anyone successfully setup DRT as a debug target (a.k.a. Scheme) on XCode 4 (so that we don't have to manually attach dbg)? - Ryosuke On Mon, Apr 23, 2012 at 7:07 PM, Jarred Nicholls jar...@webkit.org wrote: On Apr 23, 2012, at 9:03 PM, Eric Seidel e...@webkit.org wrote: Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. Simon Fraser helped me set up WebKitBuild on one of my machines, but I don't really know how to repeat that process. 2. Xcode tries to Re-index WebCore, seemingly every time I open WebCore.xcodeproj. This is a hour+ process on my 12-core Mac Pro! The re-indexing takes a lot of processing power, and seems to render both my machine, and Xcode largely unusable. I understand that Xcode isn't really designed for projects as large as WebCore, but we've made it work in the past, and I'm curious if anyone is still making it work? If the Apple folks have any suggestions or updates to http://www.webkit.org/building/debug.html, they would be most appreciated. :) Thanks! -eric Xcode 4.2.1 Build version 4D502 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev I usually create an empty project, add the source files I care about, and then attach to the appropriate renderer process - but also use WebCore.xcodeproj directly on occasion. I run the same version as you and once ran into an infinite indexing cycle, but after a swift kick from Activity Monitor, I haven't seen it again. Xcode works great as a gdb front end for me. ___ 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] Double-Resolution (Retina) Images - Re: -webkit-image-set
2012/4/24 Tom Penzer tpen...@mailcan.com: Hi Everybody! As a first-time poster, I am sorry ahead of time for any lapses in etiquette. I am seeking feedback for my (hopefully relatively painless in practice compared to the alternatives - i.e. -webkit-image-set and html5 image) proposal to solve the problem of 2x-res (double-resolution) images with our current HTML and CSS standards for devices with high-resolution displays, such as 3rd Generation iPads and 4th generation iPhones and newer. This seems like a perfect use-case for the @media rule of CSS, does it not? It's obviously not up-to-date in its definition (eg. handheld devices are not typically small screen, limited bandwidth anymore), but on the other hand it allows undefined types as well so nothing prevents implementers to extend it beforehand (like is done with most CSS properties anyway). -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
