[webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

Balazs Kelemen kbalazs at webkit.org
Fri Mar 1 09:15:39 PST 2013


On 03/01/2013 06:03 PM, Arunprasad Rajkumar wrote:
> Hi,
>
> Please ignore if it is really out of context.
>
> It would be nice to define a Class by Class 
> roles/responsibilities/expectations from Platform layer before 
> starting implementation. May be it is a kind of Class/Function 
> standardization process :). I agree that currently we have 
> standardized platform specific interface classes like GraphicsContext, 
> ResourceHandle, ImageFrame,.. but the issue is each port has its own 
> extensions to those classes to make the process easier, PSB

If I got it correctly than exactly these are the classes that should 
leave in Platform (among others). The fact that their feature set is not 
equivalent is orthogonal to this. It's a fact that each platform has 
it's own extra capabilities and we should be able to utilize them. 
Guarding them with preprocessor directives and relying on the convention 
that only platform code will actually use them is one way to do this, 
probably not the best.

> class GraphicsContext {
> ...
> #if PLATFORM(QT)
>         ShadowBlur* shadowBlur();
> #endif
> ...
> #if USE(CAIRO)
>         GraphicsContext(cairo_t*);
> #endif
> ..
> #if USE(CG)
>         void applyStrokePattern();
>         void applyFillPattern();
>         void drawPath(const Path&);
>
>         void drawNativeImage(NativeImagePtr, const FloatSize& 
> selfSize, ColorSpace styleColorSpace, const FloatRect& destRect, const 
> FloatRect& srcRect, CompositeOperator = CompositeSourceOver, BlendMode 
> = BlendModeNormal, ImageOrientation = DefaultImageOrientation);
>
>         // Allow font smoothing (LCD antialiasing). Not part of the 
> graphics state.
>         void setAllowsFontSmoothing(bool);
>         void setIsCALayerContext(bool);
>         bool isCALayerContext() const;
>
>         void setIsAcceleratedContext(bool);
> #endif
>
> };
>
> How we are going to address these?. After this work whether we have 
> all these defines?
>
> Kind Regards,
> Arun
>
> On 1 March 2013 21:50, Z(an Dobers(ek <zandobersek at gmail.com 
> <mailto:zandobersek at gmail.com>> wrote:
>
>     On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia
>     <jesus at webkit.org <mailto:jesus at webkit.org>> wrote:
>
>         Hi,
>
>         2013/2/28 Darin Adler <darin at apple.com <mailto:darin at apple.com>>:
>         > To do this, we need to eliminate dependencies from the
>         platform directory to the rest of WebCore.
>         >
>         > At this time, we are far from that. Many dependencies on the
>         DOM and other such things have crept into the platform directory.
>
>         I would be happy to help fixing this, Darin. Are the bugs blocking
>         https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to
>         start
>         list or is there something more urgent?
>
>
>     Violations reported by those bugs are most likely still valid.
>     There are of course probably other existing violations that
>     haven't been reported yet.
>
>     -Z
>
>
>         Cheers,
>         jesus
>
>
>
>     _______________________________________________
>     webkit-dev mailing list
>     webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>     https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> -- 
> *Arunprasad Rajkumar*
> http://in.linkedin.com/in/ararunprasad
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130301/bfec9b2f/attachment.html>


More information about the webkit-dev mailing list