virtual functions in ChromeClient and other clients

[Yong Li-4]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Adam Barth-3]

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.li@...> 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@...
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Yong Li-4]

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" <abarth@...>
To: "Yong Li" <yong.li@...>
Cc: "WebKit Development" <webkit-dev@...>
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.li@...> 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@...
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Yong Li-4]

Oops, even m_page is a data member.

Hm... I need to think more about it.

-Yong

----- Original Message -----
From: "Yong Li" <yong.li@...>
To: "Adam Barth" <abarth@...>
Cc: "WebKit Development" <webkit-dev@...>
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" <abarth@...>
> To: "Yong Li" <yong.li@...>
> Cc: "WebKit Development" <webkit-dev@...>
> 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.li@...> 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@...
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Adam Treat-2]

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.li@...>
> To: "Adam Barth" <abarth@...>
> Cc: "WebKit Development" <webkit-dev@...>
> 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" <abarth@...>
> > To: "Yong Li" <yong.li@...>
> > Cc: "WebKit Development" <webkit-dev@...>
> > 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.li@...> 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@...
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@...
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Eric Seidel-6]

On Thu, Oct 22, 2009 at 12:20 PM, Yong Li <yong.li@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Yong Li-4]

Ha, never mind, then.

-yong

----- Original Message -----
From: "Eric Seidel" <eric@...>
To: "Yong Li" <yong.li@...>
Cc: "WebKit Development" <webkit-dev@...>
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.li@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev