Effect plugins: Request for additional EffectFlags

[midora]

The developers know that the content of the destination surface is declared as undefined.

Main reason: It's a waste of time if Paint.NET would prepare the surface and the effect plugin does its own filling.

 

Some additional EffectFlags may be used to inform Paint.NET how the surface could be prepared:

 

EffectFlags.FillDestinationWithSource:  The plugin can expect that the destination contains the content of the source

EffectFlags.FillDestinationWithTransparentWhite:  The destination is filled with transparent white

EffectFlags.FillDestinationWithPrimary:  The destination is filled with the primary color

EffectFlags.FillDestinationWithSecondary: -"- secondary color

 

If none of the flags is set then we are in the undefined content mode (like now).

 

This may speed up the effect because Paint.NET could select the optimal method to do the basic fill operation.

Edited June 2, 2013 by midora

[BoltBait]

Have you played with the "File > New" Codelab templates?

[Rick Brewster]

An effect can already easily accomplish all of those flags by itself. There is no good reason to add them.

[midora]

Sorry for some reason I missed the responses.

 

Have you played with the "File > New" Codelab templates?

 

I know them but the reason for the request was not to save coding time.

 

An effect can already easily accomplish all of those flags by itself. There is no good reason to add them.

 

 

For sure effects can do this. The main reason is to improve the speed. It is much easier to implement and maintain the best perfomant algorithm in the caller and not in the plugins.

 

The reason why I found this thread now ;-) is an additional request for an 'Unlimited' EffectFlag.

Sometimes you really like to change pixels outside of the selection. And I can't see a reason why this should be evil.

In general I agree that user experience of functionality should not differ too much in the same group of functions.

But I do not expect that users would have a problem to understand this (quite the contrary).

 

I just did a spirit level tool to rotate selection/layer according to a reference line. And it is just not nice that the selection cuts the rotated part. For sure a user could just do select ->cut->copy to new layer->deselect->rotate->flatten. Or I could implement the funtionality as part of the path tools.

 

BTW: On my wishlist: A menu function "Image->Rotate..." which increases the document automatically to avoid cutting of part of the image.