ImagePattern, WritableImage, and Shapes

[Daniel Zwolenski]

The more type safe / explicit API would justify it for me as developers are stopped from doing something dumb at compile time instead of runtime (same reason I like java and not scripting languages) but then maybe in the context of a core API (as opposed to an app) the drivers are different. 

Good to know the reasons in any case, cheers. 



On 13/12/2012, at 7:23 AM, Richard Bair <richard.bair at oracle.com> wrote:

> In this case, my only reason for not suggesting the interface (which I certainly thought about) was that it was an additional class. Is it really paying its weight?
> 
> On Dec 12, 2012, at 12:18 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
> 
>> Is there a reason not to do something simple/normal like:
>> 
>> interface MutablePaint {
>>   void setOnChanged(ActionEvent) // or whatever 
>> }
>> 
>> Implemented by ImagePattern and not Color and Gradient. 
>> 
>> I know it's an interface but in this case I don't think the usual backwards compatability problems are overly relevant. It's not really a 'thing', just a marker interface. 
>> 
>> Having a no-op method is a less honest API to having the method not available at all (adding a Boolean isMutable is only slightly more honest).
>> 
>> More just curious than anything.
>> 
>> 
>> 
>> On 13/12/2012, at 5:22 AM, joe andresen <joseph.andresen at oracle.com> wrote:
>> 
>>> I definitely think ImagePattern is better off being acknowledged as mutable, I'll think about what I can do to my current change in regards to public api.
>>> 
>>> -J
>>> 
>>> On 12/11/2012 5:19 PM, Richard Bair wrote:
>>>> It seems to me that we ought to allow the ImagePattern to be a mutable paint. Maybe we don't even need to have an "isMutable" method, but just have the "addPaintChangeListener" method that takes a runnable (or something, maybe an event! Seems heavy) and then just have them be no-ops on the mutable paints and document that they are no-ops because the paints never change, and then have it implemented on the ImagePattern.
>>>> 
>>>> What do you think?
>>>> Richard
>>>> 
>>>> On Dec 11, 2012, at 2:18 PM, Joe Andresen<joseph.andresen at oracle.com>  wrote:
>>>> 
>>>>> Hey Fellow JFXers!
>>>>> 
>>>>> I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif).
>>>>> 
>>>>> I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created.
>>>>> 
>>>>> Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill.
>>>>> 
>>>>> The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(.
>>>>> 
>>>>> Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work".
>>>>> 
>>>>> So we have 2 options:
>>>>> 
>>>>> 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change.
>>>>> 
>>>>> 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked).
>>>>> 
>>>>> Thoughts?
>>>>> -Joe
>>>>> 
>>>>> 
>>>>> 
>>> 
>