Support for dashed lines about skiasharp HOT 16 CLOSED

Mattew is on vacation this week, and we were hoping to focus on merging our changes with upstream Google after that. So shortly after I would hope we could work on this.

from skiasharp.

Any idea when this might be implemented? Is it a fairly low priority thing?

from skiasharp.

I quickly found that this patch is more involved than adding a missing property or method. I have created a branch to discuss the best way to integrate PathEffects.

Ensuring that we wrap the return of the getter of the PathEffect property with the correct managed object is the point of discussion.

from skiasharp.

I don't think, in this particular case, that exposing subclasses of SkPathEffect serves any significant purpose, because the subclasses in the C++ API don't expose additional public members. I would just expose the single sealed class SKPathEffect, along with static Create function. E.g.:

static SKPathEffect CreateDashed(float[] intervals, float phase)

from skiasharp.

Obviously the other PathEffects would have their own CreateXXX function.

from skiasharp.

Could anyone, please, make a windows binary (dll) of SkiaSharp with SKPathEffect added?

from skiasharp.

I agree with Peter's take. We do not need to bind the subclasses (and in fact, I am wondering if we need to surface all of those SKStream subclasses in the first place as well).

We should just provide convenient factory methods to create these.

from skiasharp.

@migueldeicaza First I agree that we should do this. I need to check the remaining path effect classes to see if there are any critical members that will be missing.

There are some members on these effects, but they feel advanced to me. Also I do not think creating factory methods would stop us from later surfacing these if needed.

I see two similar options. One add the factory methods to the paint object in C# which will handle creating the effect and assigning in C. The other option is to create a C# class (SkPathEffect) that only has static factory methods that take the paint as an argument to assign the new effect to. Again in C.

In both options I think we need a way to clear the effect from the paint. That could be as simple as a ResetEffect method on the paint class.

Thoughts?

from skiasharp.

I like it.

from skiasharp.

I would have a read/write property on SKPaint of type SKPathEffect.

SKPathEffect would have only static creation methods, e.g.:

public static SKPathEffect CreateDashedPathEffect(...);

I think this is

1. most like the skia C++ api
2. discoverable
3. doesn't overly pollute the SKPaint members
4. could extend later if we allow user-written subclasses of SKPathEffect (I don't think we should be go here now though)

Peter

On Apr 7, 2016, at 2:12 PM, Bill Holmes [email protected] wrote:

@migueldeicaza First I agree that we should do this. I need to check the remaining path effect classes to see if there are any critical members that will be missing.

There are some members on these effects, but they feel advanced to me. Also I do not think creating factory methods would stop us from later surfacing these if needed.

I see two similar options. One add the factory methods to the paint object in C# which will handle creating the effect and assigning in C. The other option is to create a C# class (SkPathEffect) that only has static factory methods that take the paint as an argument to assign the new effect to. Again in C.

In both options I think we need a way to clear the effect from the paint. That could be as simple as a ResetEffect method on the paint class.

Thoughts?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

from skiasharp.

Is anything of SKPathEffect implemented in 1.49.2-beta?

from skiasharp.

@hypeartist no there is not

from skiasharp.

Is there any chance this will be implemented soon? At least in a branch so I can make a private nuget package? I would code it myself if I had any clue how to do so... :-\

from skiasharp.

The C code for this is in commit mono/skia@e31d35b
DIFF: mono/skia@xamarin-mobile-bindings...mono:feature-patheffect

C#: #112

from skiasharp.

This will be in the next release. It is currently merged into master.

from skiasharp.

Thanks a lot for all your efforts.

29 Июл 2016 г. 20:31 пользователь "Matthew Leibowitz" <
[email protected]> написал:

This will be in the next release. It is currently merged into master.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#47 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABlXL1r0vqzYPXKIOr2y_E9--gAath0pks5qakb_gaJpZM4Hz1wZ
.

from skiasharp.