Hi Balazs, Then the role of the new platform layer sounds similar like existing one :) Only it will be moved from Source/WebCore/platform from Source/Platform. Instead of having extra capabilities under a preprocessor define, why can't we define a class which has a superset of all platform capabilities, but it is upto the Platform layer to implement it or leave it umimplemented.
Kind Regards, Arun On 1 March 2013 22:45, Balazs Kelemen <kbal...@webkit.org> wrote: > 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, Žan Doberšek <zandober...@gmail.com> wrote: > >> On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia < >> je...@webkit.org> wrote: >> >>> Hi, >>> >>> 2013/2/28 Darin Adler <da...@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@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> > > > -- > *Arunprasad Rajkumar* > http://in.linkedin.com/in/ararunprasad > > > _______________________________________________ > webkit-dev mailing > listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev