[webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
Arunprasad Rajkumar
ararunprasad at gmail.com
Fri Mar 1 09:42:39 PST 2013
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 <kbalazs at 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 <zandobersek at gmail.com> wrote:
>
>> On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia <
>> jesus at webkit.org> wrote:
>>
>>> Hi,
>>>
>>> 2013/2/28 Darin Adler <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
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
>
> --
> *Arunprasad Rajkumar*
> http://in.linkedin.com/in/ararunprasad
>
>
> _______________________________________________
> webkit-dev mailing listwebkit-dev at lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
--
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130301/421f4958/attachment-0001.html>
More information about the webkit-dev
mailing list