Jump to content

What's next for brush factory?


Recommended Posts

16 hours ago, Joshua Lamusga said:

1. When settings were moved, my .xml file ended with "settings>ings>" which caused it to crash, We should try...catch and regenerate the file if it fails to de/serialize.

 

Fixed: Use FileMode.Create when writing the settings

 

16 hours ago, Joshua Lamusga said:

2. Default brushes only load on subsequent runs.

3. On subsequent runs, custom brushes are appended to the first run's brushes, so it's custom brushesdefaultcustom brushes. No change observed with further runs.

4. The brush I had selected in a previous run is selected, but as brushes load in, the selected brush changes to the last one.

 

Another pull request: Fix the default brush loading

 

16 hours ago, Joshua Lamusga said:

- Your changes to the inherited RenderArgs code and undo/redo fixed the long-standing transparency bug for the most part; drawing is still a problem. If you can find the fix for that, I'll be pretty happy. 

 

After reading the linked thread I am wondering if GDI+ may be converting the 32bppARGB images to 32bppPARGB as part of its internal processing.

This would make sense if it is calling any GDI functions because 32bppPARGB is the only 32-bit alpha channel format that GDI supports.

 

It also appears to be fairly well documented that GDI+ performs best when it is using 32bppPARGB, a few links below as examples.

This could indicate some kind of format conversion is being skipped.

 

https://richorama.github.io/2016/08/10/image-interpolation-benchmarks/

https://www.gamedev.net/forums/topic/467752-maximizing-gdi-speed/

https://microsoft.public.dotnet.framework.drawing.narkive.com/Pb9bQRzv/great-speed-improvement-trick-format32bpppargb

PdnSig.png

Plugin Pack | PSFilterPdn | Content Aware Fill | G'MICPaint Shop Pro Filetype | RAW Filetype | WebP Filetype

The small increase in performance you get coding in C++ over C# is hardly enough to offset the headache of coding in the C++ language. ~BoltBait

 

Link to comment
Share on other sites

Thanks for fixing those bugs, Null54. There are a couple more since I git pulled:

 

1. In subsequent runs, if I have moved or deleted a folder from the custom brush locations that had successfully loaded on the first run, it will crash with DirectoryNotFoundException.

 

2. It seems that it no longer loads .abr files.

Edited by Joshua Lamusga

Untitled.png.28dedeebdce78c42589f24716981923f.png

Link to comment
Share on other sites

1 hour ago, Joshua Lamusga said:

1. In subsequent runs, if I have moved or deleted a folder from the custom brush locations that had successfully loaded on the first run, it will crash with DirectoryNotFoundException. 

 
55 minutes ago, Joshua Lamusga said:

2. It seems that it no longer loads .abr files. 

 

I am not able to reproduce that.

PdnSig.png

Plugin Pack | PSFilterPdn | Content Aware Fill | G'MICPaint Shop Pro Filetype | RAW Filetype | WebP Filetype

The small increase in performance you get coding in C++ over C# is hardly enough to offset the headache of coding in the C++ language. ~BoltBait

 

Link to comment
Share on other sites

PdnSig.png

Plugin Pack | PSFilterPdn | Content Aware Fill | G'MICPaint Shop Pro Filetype | RAW Filetype | WebP Filetype

The small increase in performance you get coding in C++ over C# is hardly enough to offset the headache of coding in the C++ language. ~BoltBait

 

Link to comment
Share on other sites

  • 2 years later...

@Ego Eram Reputo Hey, I've got a really really early version of this change done enough that it will hopefully not break on your side of things.
Try it herehttps://drive.google.com/file/d/1P3lz5c63fmKgz-h_6U1_8tVNCb4OWgSC/view?usp=sharing

I switched from tabs to expandable sections in the UI since I would've had to add another tab and there'd be two lines of tabs, which is horrible. Plus it's much easier to just move things around. Let me know any thoughts you have about tablet functionality, the UI, etc.

 

Things to know:
- The WinTabDN dll file is what makes tablet recognition possible. Place in Effects folder with the other
- All tablet pressure controls go from no effect at 0% pressure exerted to full effect at 100% pressure exerted (the range isn't stated anywhere though)

Known issues since I only spent 2 days on this so far:
 - tabbing through buttons is messed up right now
 - new buttons don't have tooltips at the bottom bar yet. Sometimes I wonder if anyone sees that bar anyway
 - panning with tablet or using any of the tablet buttons isn't done yet. Trying to close the BrushFactory window via tablet click will fail
 - the rapid change in pressure when setting or removing the stylus from the draw surface plays ugly with pronounced pressure-sensitive effects a user may set

Let me know what you think Ego and everyone else, and if you have problems. I want to rule out any major tablet issues before starting to polish things.

Untitled.png.28dedeebdce78c42589f24716981923f.png

Link to comment
Share on other sites

Downloaded.

 

First impression: Looks good! I'll spend some time with it this weekend 👍

Link to comment
Share on other sites

I'm getting some odd tracking of the cursor using my tablet. I'm talking about the vertical strokes here.

Brush-Factory.png

 

I turned off Native Pointer Input (PDN Settings) but it didn't change the behaviour. From what I'm seeing, there appear to be two cursors. One on the canvas and another at the top of the screen. The 'trails' appear to be drawn between these two points.

 

If I persist in attempting to draw with the tablet I often end up with the Brush Factory dialog repositioned halfway down the screen.

Link to comment
Share on other sites

25 minutes ago, Ego Eram Reputo said:

I'm getting some odd tracking of the cursor using my tablet. I'm talking about the vertical strokes here.

 

I turned off Native Pointer Input (PDN Settings) but it didn't change the behaviour. From what I'm seeing, there appear to be two cursors. One on the canvas and another at the top of the screen. The 'trails' appear to be drawn between these two points.

 

If I persist in attempting to draw with the tablet I often end up with the Brush Factory dialog repositioned halfway down the screen.

Never heard of the native point input setting. When I turn it off, I can actually use the tablet with paint.net. That's new on me. But even with that off, I still get my plugin behaving normally. I'm not sure if it's an issue of your driver working better than mine, or your driver not conforming to whatever the tablet reading code in Brush Factory expects. If you were using Huion or Wacom, I'd guess it's my plugin that's in error, but you're using one I've never heard of before, so it's a real possibility your tablet isn't detected right. How about pressure sensitivity, can you make brush size change based on pressure sensitivity or something and see if it works? That would tell me a lot actually.

Untitled.png.28dedeebdce78c42589f24716981923f.png

Link to comment
Share on other sites

1 hour ago, NinthDesertDude said:

How about pressure sensitivity, can you make brush size change based on pressure sensitivity or something and see if it works? That would tell me a lot actually.

 

No, pressure sensitivty doesn't seem to be working. I had a couple of animated circles encircling the cursor when I was altering the pressure - but it didn't change the brush.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...