On Feb 3, 2013, at 11:34 AM, noam.rosent...@nokia.com wrote: > > > On 2/3/13 7:46 PM, "ext Maciej Stachowiak" <m...@apple.com> wrote: > >> If you're asking about phasing it out entirely, we don't have any >> immediate plans to deprecate or remove the WebKit1 mac API. There are >> quite a few Apple and third-party apps using it, and WebKit2 is not even >> public API on Mac OS X currently. >> >> As for implementing aspects of the WebKit1 API in a less efficient but >> less WebCore-intrusive way, we could probably start doing that now, on a >> case-by-case basis. Do you have any specific constraints you're concerned >> about? > Maybe the problem is less about the WK1 API layer and more about > WebCore/platform.
I'm sure that's one problem, but I am still curious what Eric had in mind. > In many other projects, there is a common pattern of "platform adaptation > layer", where there is a clear semi-public and stable interface exposed by > the middleware, which allows platform adaptations to occur with less > intrusive dependencies. WebKit doesn't really have that notion, making it > impossible to "port" webkit without either participating in trunk or > forking. I think it would be a good direction to have a better platform adaptation layer. Specific measures that I'd support: - Incrementally move Source/WebCore/platform/ to Source/Platform/ as suggested by Adam et al. - Remove knowledge of WebCore-level concepts from platform/ where they have crept in - Avoid using PLATFORM() or the equivalent in WebCore as much as possible (though ENABLE macros are fine of course) > > Platform adaptations bring a lot of benefit since they allow flexibility, > but they come with the cost of not being able to always achieve the most > straightforward vertical integration. > Accelerated compositing is, in my view, a successful example of a platform > adaptation layer. GraphicsContext is perhaps less successful. > A successful platform adaptation is measured by how much access is needed > to the underlying platform-specific implementation. For GraphicsContext, > for example, we call platformContext() inside rendering code way too much. > > I suggest that a good (but difficult) starting point to separating WebCore > and the platform adaptation is to remove all or most calls to > GraphicsContext::platformContext(), adding the appropriate functionality > as public interface to GraphicsContext, making the rendering code truly > platform agnostic, and perhaps later externalized as a true platform > adaptation interface. > But I would let others say whether this is feasible/desirable :) I was ready to agree with you about platformContext() before I looked at the code. But checking WebCore/rendering/, it looks like the only calls to platformContext() are in port-specific theme files. The theme implementation is tricky because it needs knowledge of both rendering and platform/port-specific styles and drawing code. It seems to me that to have a truly clean interface for themes, you'd need to separate the part of the code that cares about Rendering classes and the part of the code that cares about platform stuff. Just adding a bunch of single-platform-only code to GraphicsContext to avoid calling platformContext() doesn't seem like it would actually make theme logic separate from the core. It's a problem worth solving, but the solution is not straightforward. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
