[webkit-dev] How to cancel a resource request
Hi, In my WebKit port (based on the GTK port) I would like to cancel a resource request depending on the resource length or its MIME type. I thought, dispatchDidReceiveResponse(DocumentLoader*, ...) in my WebCore::FrameLoaderClient implementation could be a good place for such action as I can retrieve the length and the MIME type from the ResourceResponse argument there. However I did not find the way how to cancel the request. Any help would be appreciated. Thanks, -- Jarda http://jagpdf.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebGL performance
I have an question regarding the WebGL implementation. It already seems to be very fast. Of course a lot of stuff is important like in native GL programs (rendering triangle stripes vs. X and stuff). But how far do you think will a future stable release of WebGL match a native GL implementation in performance? Is JavaScript speed a big show stopper there? or because the GL surface is not fullscreen and can be overlayed with other layers (which is also a big peformance impact on any system which overlays something over the opengl surface / view).___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] GNUstep port of WebKit
Hello all, I am currently working on a port of WebKit to GNUstep. I plan on having tons of questions as I go forward on this. As I go along I would like to commit what I have to the repository. What is the correct procedure for this? Is it possible for me to commit my changes to a branch, or is the convention to put such things on the trunk? Sorry for the newbie questions, thanks for any feedback you might have. Thanks, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
How would the class implementing ChromeClient hold any data members?
I guess we could use pimpl...
Adam
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote:
Hi All,
ChromeClient and other clients defined in webkit are using a lot of WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
always implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those virtual functions? One reason might
be for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we can
make this mandatory, then we can remove these virtual words from these
client interface, and then the compilers could make those functions inline
whenever suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li
___
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] virtual functions in ChromeClient and other clients
Oops, even m_page is a data member.
Hm... I need to think more about it.
-Yong
- Original Message -
From: Yong Li yong...@torchmobile.com
To: Adam Barth aba...@webkit.org
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, October 22, 2009 3:28 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
Usually, those clients call WebPage or WebFrame to access the data
members.
For example:
ChromeClient::doSomething()
{
m_page-doSomething();
}
-Yong
- Original Message -
From: Adam Barth aba...@webkit.org
To: Yong Li yong...@torchmobile.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, October 22, 2009 3:25 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
How would the class implementing ChromeClient hold any data members?
I guess we could use pimpl...
Adam
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote:
Hi All,
ChromeClient and other clients defined in webkit are using a lot of
WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
always implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those virtual functions? One reason
might
be for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we
can
make this mandatory, then we can remove these virtual words from these
client interface, and then the compilers could make those functions
inline
whenever suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li
___
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] WebGL performance
On Oct 20, 2009, at 5:58 AM, Boris Stock wrote: I have an question regarding the WebGL implementation. It already seems to be very fast. Of course a lot of stuff is important like in native GL programs (rendering triangle stripes vs. X and stuff). But how far do you think will a future stable release of WebGL match a native GL implementation in performance? Is JavaScript speed a big show stopper there? or because the GL surface is not fullscreen and can be overlayed with other layers (which is also a big peformance impact on any system which overlays something over the opengl surface / view). At the moment there are not any significant webgl based apps (due to the current state of the spec) so we don't yet know what issues will be performance problems. On the topic of overlay performance, there is the requirement that a canvas element (WebGL or simple 2D) must composite correctly, which effectively requires a call to glReadPixels if the renderer is not able to composite on a hardware directly. There are other costs that currently don't show up as they're not implemented, most notably shader validation -- basically the UA is required to parse shaders itself and validate against a reduced subset of the GL|ES 2.0 version of GLSL (which is a subset of desktop GLSL). --Oliver ___ 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] virtual functions in ChromeClient and other clients
If i remember correctly another strike against this is SVG. I believe that
SVG uses a different set of empty clients. This would make that more difficult?
On Thursday 22 October 2009 03:29:28 pm Yong Li wrote:
Oops, even m_page is a data member.
Hm... I need to think more about it.
-Yong
- Original Message -
From: Yong Li yong...@torchmobile.com
To: Adam Barth aba...@webkit.org
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, October 22, 2009 3:28 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
Usually, those clients call WebPage or WebFrame to access the data
members.
For example:
ChromeClient::doSomething()
{
m_page-doSomething();
}
-Yong
- Original Message -
From: Adam Barth aba...@webkit.org
To: Yong Li yong...@torchmobile.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, October 22, 2009 3:25 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
How would the class implementing ChromeClient hold any data members?
I guess we could use pimpl...
Adam
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote:
Hi All,
ChromeClient and other clients defined in webkit are using a lot of
WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
always implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those virtual functions? One reason
might
be for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we
can
make this mandatory, then we can remove these virtual words from these
client interface, and then the compilers could make those functions
inline
whenever suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li
___
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] WebGL performance
On Oct 22, 2009, at 12:38 PM, Oliver Hunt wrote: On Oct 20, 2009, at 5:58 AM, Boris Stock wrote: I have an question regarding the WebGL implementation. It already seems to be very fast. Of course a lot of stuff is important like in native GL programs (rendering triangle stripes vs. X and stuff). But how far do you think will a future stable release of WebGL match a native GL implementation in performance? Is JavaScript speed a big show stopper there? or because the GL surface is not fullscreen and can be overlayed with other layers (which is also a big peformance impact on any system which overlays something over the opengl surface / view). At the moment there are not any significant webgl based apps (due to the current state of the spec) so we don't yet know what issues will be performance problems. On the topic of overlay performance, there is the requirement that a canvas element (WebGL or simple 2D) must composite correctly, which effectively requires a call to glReadPixels if the renderer is not able to composite on a hardware directly. Note that WebCore does have support for accelerated composting of web content (see the ACCELERATED_COMPOSITING code paths), and WebGL makes use of this, so there is very little performance impact of layering content on top of a 3d canvas for platforms that have an ACCELERATED_COMPOSITING implementation. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote: ChromeClient and other clients defined in webkit are using a lot of WebCore objects. So it seems impossible to provide a ChromeClient from another binary other than webkit itself. In other words, ChromeClient is almost always implemented in a static lib that's linked with WebCore together. This statement is false. WebCore is built as a dynamic library on Mac OS X. WebKit provides a ChromeClient: http://trac.webkit.org/browser/trunk/WebKit/mac/WebCoreSupport/WebChromeClient.h -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
Ha, never mind, then. -yong - Original Message - From: Eric Seidel e...@webkit.org To: Yong Li yong...@torchmobile.com Cc: WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, October 22, 2009 3:52 PM Subject: Re: [webkit-dev] virtual functions in ChromeClient and other clients On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote: ChromeClient and other clients defined in webkit are using a lot of WebCore objects. So it seems impossible to provide a ChromeClient from another binary other than webkit itself. In other words, ChromeClient is almost always implemented in a static lib that's linked with WebCore together. This statement is false. WebCore is built as a dynamic library on Mac OS X. WebKit provides a ChromeClient: http://trac.webkit.org/browser/trunk/WebKit/mac/WebCoreSupport/WebChromeClient.h -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:22 PM, David Hyatt hy...@apple.com wrote: I've actually been super frustrated with WebKit's selection behavior for a long time, precisely because it tries to let you select everything. In Concrete examples of where something weird happens would be helpful. The gap code is obviously not perfect and so there's plenty of room for improving it, which will help out Chrome on Mac users even if Chrome on Windows goes to a different style of behavior. This likely isn't what PK was talking about, but it's a good example in its irony. Try selecting a paragraph on the front page of webkit.org; you'll see weird gap painting over the navbar on the left. http://imgur.com/fd1Ck (happens on Safari too, just was easier to screenshot locally) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Thu, Oct 22, 2009 at 2:37 PM, Evan Martin ev...@google.com wrote: This likely isn't what PK was talking about, but it's a good example in its irony. Try selecting a paragraph on the front page of webkit.org; you'll see weird gap painting over the navbar on the left. Ben has suggested to me that this is the kind of issue he's interested in seeing fixes for, and he's less interested in more drastic proposals. (I still want to do copy as plain text though.) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Thu, Oct 22, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Thu, Oct 22, 2009 at 2:37 PM, Evan Martin ev...@google.com wrote: This likely isn't what PK was talking about, but it's a good example in its irony. Try selecting a paragraph on the front page of webkit.org; you'll see weird gap painting over the navbar on the left. Ben has suggested to me that this is the kind of issue he's interested in seeing fixes for, and he's less interested in more drastic proposals. (I still want to do copy as plain text though.) That sounds fine to me btw. -Ben ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 22, 2009, at 2:38 PM, Evan Martin wrote: On Mon, Oct 19, 2009 at 1:22 PM, David Hyatt hy...@apple.com wrote: I've actually been super frustrated with WebKit's selection behavior for a long time, precisely because it tries to let you select everything. In Concrete examples of where something weird happens would be helpful. The gap code is obviously not perfect and so there's plenty of room for improving it, which will help out Chrome on Mac users even if Chrome on Windows goes to a different style of behavior. This likely isn't what PK was talking about, but it's a good example in its irony. Try selecting a paragraph on the front page of webkit.org; you'll see weird gap painting over the navbar on the left. http://imgur.com/fd1Ck (happens on Safari too, just was easier to screenshot locally) Seems like a bug to me. Selection draws over content that won't get copied. You also get some double-drawn selection if you Select All on the webkit.org front page. Please file. http://daringfireball.net/ is another site that has the same problem, likely for the very same reason. I expect this will happen on any site uses a large left margin on the main content to lay out around an absolute-positioned sidebar. Some sites use floats for this kind of thing and are not affected. I'm not sure what the best fix is. Maybe we should be stopping selection painting at the border box and not draw into margins. I'm not sure if this would have negative consequences on other sites. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Thu, Oct 22, 2009 at 4:22 PM, Maciej Stachowiak m...@apple.com wrote: Seems like a bug to me. Selection draws over content that won't get copied. You also get some double-drawn selection if you Select All on the webkit.org front page. Please file. https://bugs.webkit.org/show_bug.cgi?id=30694 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
