Dynamic Draw roadmap and beta tests

[NinthDesertDude]

6 hours ago, welshblue said:

being able to use [ ] to increase/decrease by 5 would be cool

I won't tie the shortcut to the UI control that has active focus because that would surprise most users, but modifying the keyboard shortcuts to incorporate the brackets is a good idea. So changing size doesn't require holding S. Hold R and use brackets to change rotation, A and brackets to change alpha.

 

New points:

- Adjust keyboard shortcuts to use brackets. User shouldn't have to hold Ctrl, but can to make size/rot/alpha change faster.

 

@null54 You're quite a professional programmer; can I take your advice on what you noticed needs overall improvement / rewriting in the code structure? I wrote this some time ago, and while I have a better understanding now, I'm sure it's not as good as yours. Interpolation for localized strings was an unknown pattern to me back then, for example; extern / Interop is still unknown to me.

[NinthDesertDude]

@welshblue I'm glad you said something, because changes to the keyboard shortcuts will require changing the wiki, which I forgot I wrote. I'm glad you found it useful.

Edited October 28, 2018 by Joshua Lamusga

[TrevorOutlaw]

5 hours ago, welshblue said:

Until I read  and went to play around, I didn't realise that Ctrl + [ ] changed the size by 5 ... then I read the Github link and learnt even more. (Always assumed that was for code ? Lesson - should never assume)  Extremely well written and comprehensive guide

 

That was a request I made on the previous page, and Null added that.  It made a huge difference as I didn't have to spend time fiddling with the slider.

[NinthDesertDude]

2 minutes ago, TrevorOutlaw said:

That was a request I made on the previous page, and Null added that.  It made a huge difference as I didn't have to spend time fiddling with the slider.

Well you never really did, unless you can't use mouse wheel. This is relevant because right now, Ctrl + R + mouse wheel and Ctrl + A + mouse wheel are the only ways to rotate and change alpha without using a slider.

[TrevorOutlaw]

35 minutes ago, Joshua Lamusga said:

Well you never really did, unless you can't use mouse wheel. This is relevant because right now, Ctrl + R + mouse wheel and Ctrl + A + mouse wheel are the only ways to rotate and change alpha without using a slider.

Perhaps I should be clear.

 

I was refering to a request to have CTRL + brackets to control the brush size.  Now, I didn't know about the other combination.  I don't recall seeing anything about those shortcut, so more to play with! 

[null54]

On 10/28/2018 at 9:57 AM, Joshua Lamusga said:

can I take your advice on what you noticed needs overall improvement / rewriting in the code structure?

 

I am not sure how much I would be able to help with the code structure, but I do have a few thoughts regarding the UI.

 

I have to agree with @welshblue that a combo box is difficult to use with a large number of brushes, this could become more important when users have multiple ABR files loaded (ABR files often contain 20+ brushes).

 

In the attached version I changed the dialog to use a customized ListView, it provides larger brush thumbnail images and tooltips with the brush name and location.

The other UI change I made was to replace the classic folder browser in the preferences dialog with the Vista-style version.

 

On 10/28/2018 at 9:57 AM, Joshua Lamusga said:

extern / Interop is still unknown to me.

 

I am probably one of the few Paint.NET plugin developers that uses native interop (P/Invoke, COM interop, etc).

C# and the Paint.NET API are powerful enough that most plugins do not need to interact directly with native libraries.

But it is required when your plugins host Photoshop filters or use the Google WebP library.

 

This attachment was superseded by the one in the following post:

https://forums.getpaint.net/topic/113361-whats-next-for-brush-factory/?do=findComment&comment=550627

 

[null54]

Glad you like it.

It could have different background colors based on the brush location, but with the tooltips I am not sure that is necessary.

 

14 minutes ago, welshblue said:

Nifty Add Brush Icon ? 

 

I combined two icons from the Visual Studio Image Library, I was expecting for it to be a placeholder until some of the artists on this forum came up with a better icon. ?

[null54]

I updated the build in the above post to fix an issue with selecting the last used brush when the dialog is displayed a second time.

[NinthDesertDude]

Why didn't I think of that? Here I was, ready to write a custom combo box. This is simply a better approach. I appreciate it.

 

Quote

I updated the build in the above post to fix an issue with selecting the last used brush when the dialog is displayed a second time.

Are you talking about how the brush resets when you open the dialog after you use a brush, select browse for additional brushes, cancel browsing, confirm the dialog and run it again? I was just about to say that it doesn't remember the brush in that corner case. I downloaded it half-an-hour after your message.

 

I'd approve this change if you pull my changes for keyboard shortcuts which I made after your previous merges and take a look at the issue I wrote above, which might be what you're talking about. These are useful changes, for sure.

[null54]

16 minutes ago, Joshua Lamusga said:

Are you talking about how the brush resets when you open the dialog after you use a brush, select browse for additional brushes, cancel browsing, confirm the dialog and run it again? I was just about to say that it doesn't remember the brush in that corner case. I downloaded it half-an-hour after your message.

 

No, but I can see how that behavior occurs.

Fixing it would require tracking the previously selected item index and using that for the brush index in the effect token.

 

One other thing I considered is changing the ListView Anchor styles so that it expands to fill the empty space in the dialog, this may help usability with large numbers of brushes.

[NinthDesertDude]

7 hours ago, null54 said:

I was expecting for it to be a placeholder

 

I can resolve the issue I mentioned by moving add brushes to a button below the list view, so it'll better separate concerns, improve user UI, and remove the need to solve that issue. The button will be the same width as the list view and might have its own icon. I made sample icons at 64 x 64, but I'll probably go for a smaller version of the gray one. The reason I didn't start off with a button was because it didn't look right with a combo box above it (ah, solving many UI problems at once).

 

The icons, if you're wondering.

    

[TrevorOutlaw]

@null54 and @Joshua Lamusga

 

One thing I have observed since updating the Brush Factory with the pull and released version of the plugin is this behavior:

 

When I load the ABR brush for the first time, the pluging goes through the conversion process of the ABR file, and when that does, the plugin window disappear for a second or two and reappear again.  I don't know if this a normal behavior, but I thought I would bring this up.  If you aren't understanding what I am talking about, I can record a screenshot of it using Parallel tool.

[NinthDesertDude]

Just now, TrevorOutlaw said:

If you aren't understanding what I am talking about, I can record a screenshot of it using Parallel tool.

Haven't seen it, could you?

[TrevorOutlaw]

6 minutes ago, Joshua Lamusga said:

Haven't seen it, could you?

 

[NinthDesertDude]

Thanks for the video. It looks like ordinary lag to me, which should be resolved by better image management when I implement lazy-loading brushes.

[null54]

1 hour ago, Joshua Lamusga said:

Thanks for the video. It looks like ordinary lag to me, which should be resolved by better image management when I implement lazy-loading brushes.

 

When you say lazy-loading brushes, do you mean that the brush collection will be populated on a background thread?

That would be easy to implement with a BackgroundWorker.

[NinthDesertDude]

2 hours ago, null54 said:

When you say lazy-loading brushes, do you mean that the brush collection will be populated on a background thread?

We can load all images and ABR files in a background thread and add them in real-time to the brush window, that's a start. Memory usage still increases as we load images, so I'd like to delay loading the images until the user can see the thumbnails in the list view (lazy-loading, or more aptly, load-on-demand).

 

This is how it will work:

1. On a separate thread when the plugin starts, crawl listed directories for .abr files and read the number of images in each .abr file.

2. Add an option to the list view for each image, then add an option for each entry in the .abr files we just read.

3. Options have metadata for: doPersist (true for default brushes), isActive (true for selected brush), filePath, isLoaded..

4. Find which items are visible in the list view. If !isLoaded && (doPersist || isActive)), load it from the filePath. If !doPersist && !isActive && isLoaded, unload it.

5. When you load and unload images, do it asynchronously and dispose properly.

 

It would be great if you could develop/inform me about reading the number of images in each .abr file, null54.

Edited October 31, 2018 by Joshua Lamusga

[null54]

1 hour ago, Joshua Lamusga said:

It would be great if you could develop/inform me about reading the number of images in each .abr file

 

It would be fairly difficult to read an ABR file in chunks (especially the modern version 6+ files), the format appears to have been designed to be read all at once.

Even getting the count for version 6+ files requires a large amount of parsing, and those files also have images that are scaled down dynamically instead of storing the smaller images in the file.

 

One alternative would be to change the brush format to only store the ListView thumbnails in memory for the non-default brushes, with the full-size brush being moved into memory from a temporary file on disk when the item is selected and back to disk when it is not selected.

That would reduce the overall memory usage while still allowing the ListView to provide responsive scrolling to the user, it would also improve performance versus having to recreate the brush thumbnail each time the ListView redraws.

[NinthDesertDude]

6 hours ago, null54 said:

One alternative would be to change the brush format to only store the ListView thumbnails in memory for the non-default brushes, with the full-size brush being moved into memory from a temporary file on disk when the item is selected and back to disk when it is not selected.

Since it's hard to read .ABR files in pieces, this becomes the best solution. It also simplifies loading / unloading on demand when everything is in picture files only. I used it on another project with file copy operations until I realized the latter was taking too long, so I'm familiar with the strategy.

[null54]

@TrevorOutlaw

Here is a version that implements background loading of the brushes.

It also implements the memory optimization that I described in my previous post.

 

Larger brushes will cause lag when selecting them, it takes longer to load them into memory.

I had to implement an optimization that forces the ListView to repaint immediately for larger brush sizes, it was taking several seconds for the UI to update the selected brush when loading some ABR brushes with images more than 2000 pixels wide.

 

@Joshua Lamusga

 

Should there be a limit on how large a brush can be before the plugin scales it down or ignores it?

 

Removed because the official 1.7 release includes these changes.

https://forums.getpaint.net/topic/110673-brush-factory-v17-dec-8th-2018/?do=findComment&comment=551750

[Pixey]

I downloaded v1.6 today and found that the Add New brushes would upload and work, but they didn't save.

 

I just downloaded the Brush Factory Lazy Load and the Add Brushes load, but appear as a line and draw as lines

 

 

[null54]

The issues with loading PNG files and the Clear Brushes crash should be fixed.

Updated the attachment in the above post.

[NinthDesertDude]

9 hours ago, null54 said:

Should there be a limit on how large a brush can be before the plugin scales it down or ignores it?

Resizing to sliderBrushSize.MaxValue for the largest dimension would be a good idea (currently 500). Maybe add the resize function to Utils.cs. We can ignore brushes bigger than 3000 pixels in either direction because it's just nonsense at that point. I say 'either direction' because images are padded to be square so that rotation doesn't skew the image.

 

Quote

 

When loading a .png it loaded as a default brush

That's what I get for only testing that the .abr format works. It sounds like @null54 fixed that, so I'll hold tight for a PR. I'll take the listview changes, too.

[NinthDesertDude]

Please note that the versions posted on this thread aren't the official versions, so they'll have bugs, bad bugs and worse on occasion. It's nice to note, though, but it's no measure of failure.  Pixey and Welshblue, you are both using a version on this thread; I also tested against the official version and it doesn't have those bugs (phew).

[null54]

4 hours ago, welshblue said:

Clear Custom Brushes ❌ 

 

That should hopefully be fixed.

It appears to have been a race condition when modifying the brush list from multiple threads.

 

Also brush sizes larger than the maximum brush size are now down-scaled.