Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set

[Maciej Stachowiak]

It would be more readable to use:

@media screen and (min-device-pixel-ratio: 2) { … }

The -webkit-image-set proposal explains why it is a useful shorthand despite 
the existing device pixel ratio option.

Regards,
Maciej


On Apr 23, 2012, at 11:11 PM, Eric Seidel wrote:

> Assuming I'm understanding Kalle correctly, it seems this could
> already be accomplished with @media resolution?
> 
> http://www.w3.org/TR/css3-mediaqueries/#resolution
> 
> @media screen and (min-resolution: 264dpi) { … }
> 
> Which according to:
> http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
> 
> Would match both the new iPad and the iPhone 4.
> 
> I don't know if webkit supports "resolution" in media queries yet?
> 
> On Mon, Apr 23, 2012 at 9:28 PM, Kalle Vahlman  
> wrote:
>> 2012/4/24 Tom Penzer :
>>> 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
>>> ) 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
> ___
> 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

[Eric Seidel]

To answer my own question:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/MediaQueryEvaluator.cpp#L66

On Mon, Apr 23, 2012 at 11:11 PM, Eric Seidel  wrote:
> Assuming I'm understanding Kalle correctly, it seems this could
> already be accomplished with @media resolution?
>
> http://www.w3.org/TR/css3-mediaqueries/#resolution
>
> @media screen and (min-resolution: 264dpi) { … }
>
> Which according to:
> http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
>
> Would match both the new iPad and the iPhone 4.
>
> I don't know if webkit supports "resolution" in media queries yet?
>
> On Mon, Apr 23, 2012 at 9:28 PM, Kalle Vahlman  
> wrote:
>> 2012/4/24 Tom Penzer :
>>> 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
>>> ) 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
___
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

[Eric Seidel]

Assuming I'm understanding Kalle correctly, it seems this could
already be accomplished with @media resolution?

http://www.w3.org/TR/css3-mediaqueries/#resolution

@media screen and (min-resolution: 264dpi) { … }

Which according to:
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density

Would match both the new iPad and the iPhone 4.

I don't know if webkit supports "resolution" in media queries yet?

On Mon, Apr 23, 2012 at 9:28 PM, Kalle Vahlman  wrote:
> 2012/4/24 Tom Penzer :
>> 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
>> ) 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
___
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

[Kalle Vahlman]

2012/4/24 Tom Penzer :
> 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
> ) 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

Re: [webkit-dev] Debugging With Xcode

[Ryosuke Niwa]

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  wrote:

> On Apr 23, 2012, at 9:03 PM, Eric Seidel  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] Debugging With Xcode

[Jarred Nicholls]

On Apr 23, 2012, at 9:03 PM, Eric Seidel  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

[Dan Bates]

On Mon, 23 Apr 2012 18:02:51 -0700, Eric Seidel  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,
.

Also, I've updated  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,
.

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

[Alexis Menard]

Hi,

On Mon, Apr 23, 2012 at 10:07 PM, Mark Rowe  wrote:
>
> On 2012-04-23, at 18:02, Eric Seidel  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
>  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

[Mark Rowe]

On 2012-04-23, at 18:02, Eric Seidel  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 
 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

[webkit-dev] Debugging With Xcode

[Eric Seidel]

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] FYI: sub-pixel layout landing soon

[Levi Weintraub]

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  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  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

Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set

[Tom Penzer]

On Apr 23, 2012, at 3:42 PM, Ryosuke Niwa  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

[webkit-dev] Process for importing third party tests

[Jacob Goldstein]

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

[Ryosuke Niwa]

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  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:
>
> 
>
> 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 ' 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

Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set

[Edward O'Connor]

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 ) 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] webkit2 with v8

[Sam Weinig]

Without considerable more demand, I don't think we want this.

-Sam

On Apr 23, 2012, at 3:20 PM, Balazs Kelemen  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 Kelemen  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] webkit2 with v8

[Balazs Kelemen]

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 Kelemen  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

[Maciej Stachowiak]

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  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] FYI: sub-pixel layout landing soon

[Adele Peterson]

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  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

[Sam Weinig]

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  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

[Levi Weintraub]

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  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] Double-Resolution (Retina) Images - Re: -webkit-image-set

[Tom Penzer]

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 ) 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:



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 '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:


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 '', 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: '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, ', 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 'images="_2x" assume-present=false />', and use the 'double-resolution'  
attribute to flag img assets with a double-resolution asset available,  
such as ', 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 to this, a similar approach could be used to add  
support for different image formats without losing backwards- 
compatibility, and again saving many precious developer-years. Imagine  



-Tom P.
__

[webkit-dev] PSA: Commit-queue/Cr-Linux Delays expected until EOD

[Eric Seidel]

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

Re: [webkit-dev] FYI: sub-pixel layout landing soon

[Adele Peterson]

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] FYI: sub-pixel layout landing soon

[Levi Weintraub]

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

Re: [webkit-dev] WebCore's ResourceLoader

[Nate Chapin]

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  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] win-ews linker error

[Konrad Piascik]

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:
12>WebCore.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)
12>WebCore.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)
12>WebCore.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)
12>WebCore.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

[webkit-dev] webkit2 with v8

[Balazs Kelemen]

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

Re: [webkit-dev] How to deal with the difference between JS IDL and V8 IDL?

[xuewen]

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 > 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
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 
> 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





-
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] How to deal with the difference between JS IDL and V8 IDL?

[Ryosuke Niwa]

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  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 
> 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

[webkit-dev] WebCore's ResourceLoader

[Boris Brönner]

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?

[Kentaro Hara]

> 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  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] How to deal with the difference between JS IDL and V8 IDL?

[xuewen]

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