LWChris

@Red ochre I looked at your plugin first, but the examples seemed way too complex for a simple non perspectivic non shaded 1px wide coiled line... maybe I need to look into it and play around with it.

Is there any method or plugin to create a line in the shape of a coil? Like this, but obviously "nice and clean"? I searched the plugin index for "spiral" (all seemed to be concentric), "coil" (1 result for Tesla coil lightning) and "twister" (no results) and I'm out of ideas what to look for. I can probably do it from hand, creating a single loop with mirrored parts from two differently sized ellipses for upper and lower half, and then copying that loop multiple times horizontally. But maybe there's something easier that I haven't found yet?

No it doesn't. PDN never crashes for me. It was running for about 3 and a half hours. Then I updated VS, and the instant the updater starts it crashed, then never again. It would be insanely weird coincidence if this happened in exactly that moment and had nothing to do with it. Yeah, my system has 16 GB and usually it's idling around 6-10 GB usage. What I find suspicious about this is the pagefile info from the crashlog. It says "20.420 MB pagefile (4.018 MB free)". But my pagefile is set to a managed size of 4096-8192 MB. So "20.420 MB pagefile" doesn't make sense unless it's combining the 16 GB = 16384 MB RAM + 4096 MB pagefile = 20480 MB - 68.5 reserved for hardware = ~ 20420 MB, but this calculation seems far fetched. So in order to verify whether those numbers make sense, how can I calculate them?

I just updated Visual Studio 2022 from 17.3.6 to 17.8.6. As soon as the VSInstaller started to download and update (i.e. not during the "Updating Installer" step but immediately thereafter), PDN, which had been sitting open in the background for at least several hours with just one screenshot clipping pasted onto the default canvas, crashed. I don't know if this is something that you can or want to look into, but I thought a) PDN would run independently and found it strange it would crash from updating an unrelated program, and b) every exception may still be worth catching and handling gracefully rather than crashing the app altogether Crash log attached. pdncrash.1.log

I would say the easiest way without plugins is: Color the background layer with your base color, eg. some █ dark olive green For each additional color of patches, repeat the following steps: Create a new layer (Ctrl+Shift+N) Reset colors to default black/white Use "Effects > Render > Clouds..." Use "Scale" to select number of patches: smaller values = more and smaller patches; bigger values = fewer but bigger patches Use "Roughness" to select uniformity of patches: smaller values = more uniformly sized, rounded patches; bigger values = more variously sized, jagged patches Use "Adjustments > Brightness/Contrast..." (Ctrl+Shift+T) to break it up into edges with sharp colors: Turn "Contrast" to 100% - this will basically split everything into either white or black Use "Brightness" to modify connectivity - adjust until you like either the size and distribution of white or black patches Use "Paint Bucket" tool (F) with "Flood Mode: Global" to color the patches in the desired color Use "Magic Wand" selection tool (S, S, S, S) with "Tolerance: 0%" to select the other parts and delete (Del) Tips: Rather than create one densely packed layer per patch color, create multiple loosely packed ones and mix the layer orders such that each color can overlay patches of other colors (e.g. Scale 100, Roughness 0.30, Brightness -40) If you have varying patch sizes, order layers from bigger to smaller patch sizes Create a top layer with medium sized patches of the base/background color

That's also how I do it in the PoC. What I find difficult about this is - how would you implement rotation? Because for a rotated ellipse for example, "top left" of input can't be "easily" reflected (or at least I wouldn't trust that mathematical calculations of reflected pixels about a randomly slanted symmetry axis will never ever create a result with a gap in the outline), and for output the "top left" isn't enough and also potentially not a rectangle. Sadly, I noticed it's not necessarily limited to 1px outlines if you consider rotation. This is how a 34x11 ellipsis with border thickness 2 looks like when rotated exactly 90°: While doing this example, I also noticed that in PDN, the outline of ellipses grow symmetrically around the set size. E. g. for a 20x20 rectangle with border thickness 6, all border pixels lie within that 20x20 (the fill is 8x8). But switch to ellipse, and now 3 pixels are inside, 3 are outside, meaning the resulting shape is actually 26x26 in size. However don't think changing that to a consistent behavior (where I prefer the rectangle one) would be detrimental to anyone (except for that one person drawing ellipses using an AutoHotkey macro on a daily basis). [Edit: I now realized that "rectangle" and "rounded rectangle" are the outliers here; all other shapes grow symmetrically around the set size, only those two grow within. I still like the rectangle's behavior better, because it preserves size while changing outline thickness or form fill mode from to ]

I have created a proof of concept for a custom renderer that handles circles, ellipses, and rounded rectangles. There is not yet any ability to rotate a shape and to be fair that is something I haven't even gotten around to think about. @Rick Brewster I published the code under MIT license. If you want to take a look, or use my code (or the "thickness = 1" bits) as base for your own custom renderer that you have not gotten around to since 2010, feel free. Also, if you want me to strip the code to only the "thickness = 1" case first, and/or want to see inclusion of rotations as well, please let me know.

Okay, so from what I have read here, the issue seems to be that PDN is using Direct2D for drawing shapes, and while the antialiased version are good, the aliased geometry is poor and that causes the problem. What's really interesting is that this only happens at thickness 1. Thickness 2 seems to be symmetrical for non-rotated shapes.

A 20x20 rounded rectangle with border width 1 and corner radius 4 looks like this: For some reason, 3 out of 4 corners get a "different" version of how a rounded corner looks like; only the top right seems to be actually 4x4. This is what radius 5 looks like: None of these corners have a 5x5 footprint. Here's radius 6: You get the idea... I tested all values from 1 to 10, and none of these values resulted in a symmetrical shape. I'm not sure it has always been like this, or if that's a regression, but something's odd about the rounding here, resulting in that I effectively cannot use this tool unless I want to check and tidy up 3 or all 4 corners, which may be feasible for radii up to 8, but beyond that it's very cumbersome.

Yes, my bad. I drew a shape without prior selection, and since it had that "9 nodes plus anchor" look it had the same UI features like a selection. So I just used that word without thinking about that an actual selection can also exist while creating a new shape.

Ctrl+Alt+V already exists, but I think it's not a problem. Ctrl+V can always just paste to the best of its possibilities. If you copied an editable state, it pastes the editable state, if you merely copied pixels, it pastes the pixels. My #1 use case is to alleviate the pain of my own stupidity: creating some object and customizing it, only to realizing I started on the wrong layer. Right now, there's not much I can do in that case, except for Ctrl+Z and start over again on the correct layer. A rich copy feature could be enabled for shapes but also lines, gradients, or even text I would think, and crucially it can copy and restore their editable states opposed to just the committed results, so making variants is much easier.

In a twisted way, this confirms my other point of "as a developer you don't care about sharing libraries to save memory and RAM". I am a professional developer of 16 years, and I've never [been] bothered to familiarize with the GAC or any of that stuff. You just reference a DLL in your project, it gets copied alongside your DLLs, you ship your own copies of the DLLs you need, and you never bother to try and make anything "shared" or access something that could probably be "shared" apart from the default runtime environment... Hence I didn't even know they abolished the GAC concept. But they probably did it for exactly that reason... managing 20+ of versions of a file which are all called "System.Windows.dll" in a "common" folder and have everyone who asks for "System.Windows" with an arbitrary version [range] get the right version and load all that conflict-free in an interoperable manner is a nightmare task. So we gave up on that front and that's probably a good thing for keeping everything smoothly running - everybody gets served exactly what they expected and nothing else.

Yes you are right, there is the "ant border" area selection and then the shape with its nodes and anchor etc. The cool part is - Ctrl+C might actually copy both, that is the selection and the shape configuration, such that Ctrl+V on another layer would create the same selection and the not-yet-commited shape. Or maybe just implement that as "Ctrl+Alt+C Copy objects", and keep Ctrl+C as it is.

I've used "Costura.Fody" in many different projects so far. It is as easy as adding the NuGet package to your project, and *poof* the next build should yield one big DLL instead of multiple small ones, no questions asked. At least that's been my experience so far. Installing the package will create a "FodyWeavers.xml" config file and add it to your project plus an xsd (XML schema definition for XML validation). Don't worry about those. It essentially contains nothing but an empty configuration node, which you could edit to manage linking to a finer detail, but the default config yielded from that empty config should be fine for most people and use cases. Also, I wanted to address the concerns about "loading a shared library twice": The proper way to distribute actual shared libraries would be to register them in the GAC (global assembly cache) which is a folder full of DLLs in all versions ever registered, that the assembly resolver looks into to find DLLs of a specific version [range]. Doing this however requires elevated process rights upon installation, and I think also special preparations for the DLLs (namely signing them with strong name keys, but then again IIRC only for .NET Framework not for .NET Core bla bla bla). Long story short, it's stuff that is a lot to ask for from your hobbyist programmer. So the main benefit of "sharing" has become not so much about RAM conservation but rather about code deduplication. A shared library from the perspective of a programmer is often just generic code that they use in multiple projects, so it's a library of shared code, that you only needed to write once, and maintain once, and bugfix once, etc. for all the projects to benefit from the work. Now that computer memory (permanent or RAM) has been increasing by orders of magnitude, loading the same DLL three or four times in isolated contexts is itching the perfectionist's brain because "this is not how it should be", but it's rarely ever a problem in the real world.

When I have an image and draw a shape, say, I pull a circle, and it's not yet commited, then there is this outline that suggests that the current "selection" is that shape. But when I hit Ctrl+C and then Ctrl+V, PDN pastes the whole layer again, not a new shape, because Ctrl+C without selection by default copies the whole layer. A clipboard can hold "rich objects" that can be converted to simpler things for uses outside the program, but stay rich for uses inside the program. For example if you create a table in MS Excel and make a graph out of that, then copy the graph, and paste it into Word, then Word will paste an interactive graph that's even still linked to the data in the Excel, meaning changing the data in Excel will change the graph in Word. But pasting that graph into PDN will create an image of that graph. It would be really cool if Paint.NET made use of that cool feature in .NET to copy and paste rich objects, such as shapes, multiple layers, etc. Then it could be implemented that when in "Shape creation mode", Ctrl+C copies the information that it is a shape, and Ctrl+V could commit the current shape and then create a new shape object on top that can be moved or edited, while Ctrl+X can put that shape into the clipboard and cancel creation, but Ctrl+V re-spawns that (useful if after creating the perfect shape you realize you're on the wrong layer, just cut, swap layer, paste, and continue creation from there). If the conversion interface is properly implemented for that "CopiedShape" object, this would also mean pasting that object to another Paint.NET file would also create an editable shape there, while pasting it into MSPaint or Word would just appear as if I had copied a rectangular image with nothing but the commited shape on a transparent background.