Jump to content

null54

Moderator
  • Posts

    1,962
  • Joined

  • Last visited

  • Days Won

    89

Everything posted by null54

  1. @TrevorOutlaw Now the crash should hopefully be fixed. No it looks like another multi-threading race condition, it amazes me how many of those I keep finding.
  2. Actually the stable version of Brush Factory (1.6) can load ABR files. @Joshua Lamusga released that version on the 29th of October, but he did not create a new post to bump the topic in the list. The in-development version will load faster and be easier to use, due to changes in how the brushes are loaded and displayed. But as @welshblue stated you should save your work before using it as there may still be bugs that can cause it to crash.
  3. Fixed. Also I am now including the pdb file with the effect, this should provide me with more information in the event of a crash. Both files should be placed in the Effects folder.
  4. @Joshua Lamusga Two pull requests: Moving the undo files out of the temp folder: https://github.com/JoshuaLamusga/Brush-Factory/pull/8 Downscale brushes larger than the maximum brush size: https://github.com/JoshuaLamusga/Brush-Factory/pull/9 I am still trying to decide how I want to submit the ListView and background loading changes. I am thinking that making those separate PRs would be easier to read, due to the amount of changes involved.
  5. Upgraded to the October 25 2018 release of DirectXTex, file version updated to 1.8.6.0.
  6. 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.
  7. The issues with loading PNG files and the Clear Brushes crash should be fixed. Updated the attachment in the above post.
  8. @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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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. 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. ?
  14. 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. 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
  15. @Joshua Lamusga Removed the PresentationCore dependency: https://github.com/JoshuaLamusga/Brush-Factory/pull/6 Added the ABR loading code: https://github.com/JoshuaLamusga/Brush-Factory/pull/7
  16. @Joshua Lamusga A pull request for the EnumerateFiles code: https://github.com/JoshuaLamusga/Brush-Factory/pull/5
  17. Glad that it works for you. @Joshua Lamusga Another pull request: https://github.com/JoshuaLamusga/Brush-Factory/pull/4
  18. Then it is strange that it does not work for you. I updated the build in my first post to remove the extra "\r" from the saved brush paths, try it and see if the other folders now load.
  19. @Joshua Lamusga A pull request for the case-insensitive path comparisons: https://github.com/JoshuaLamusga/Brush-Factory/pull/3 @welshblue What version of Windows are you using? I noticed when debugging that all but the last of the saved brush paths have an "\r" appended to the end (Windows uses \r\n as a line terminator and the code only checks for \n). This could cause the OS to look for a non-existent sub-directory named "r" in each folder. While this does not appear to cause any issues on Windows 10 version 1803 it may cause issues for other Windows versions.
  20. Added to the version in my first post. @Joshua Lamusga A pull request for the brush size shortcuts: https://github.com/JoshuaLamusga/Brush-Factory/pull/2 I also noticed that the file extension and custom search path comparisons are case-sensitive. This causes the plugin to not detect files with upper-case extensions and have duplicate custom search paths. I will be submitting pull requests to fix that and change the folder searching to use Directory.EnumerateFiles soon.
  21. Updated the attachment in my previous post to fix a crash when loading version 2 brushes.
  22. Here is a build that loads ABR files based on the code from my Photoshop Brush FileType plugin (which is on GitHub under the MIT license). If @Joshua Lamusga agrees I will fork the project and submit a pull request with the code. This build may also improve the speed when scanning the custom brush folders, I switched it to use Directory.EnumerateFiles instead of Directory.GetFiles. Removed because Brush Factory can load ABR files as of version 1.6. https://forums.getpaint.net/topic/110673-brush-factory-v16-oct-29th-2018/
  23. The version on this website is free, the Windows Store version is paid. See the following thread for more information.
  24. You can also change the default selection mode in the settings menu.
×
×
  • Create New...