Jump to content
You must now use your email address to sign in [click for more info] ×

Pixel Persona - Smudge Brush Tool Issues in RGB/8 Color Space and RGB/16 Stroke Lag


Collin S.

Recommended Posts

Hello,

I don't know if these are bugs or just limitations of the application and iPad, but I figured I would write a bug report about them since these issues strongly hinder how I use Affinity Designer on my iPad. I am also bundling what I would normally consider two separate bugs because I found them together and they cause mutually exclusive issues for me. If you guys want me to format my report any differently in the future, just let me know.

Ok, so the issues I am having stem from the smudge brush tool and specifically how it works when the color space is set to RGB/8. I was experimenting using the smudge brush to create a smooth blend between two colors. What ended up happening, however, is that the colors would become very distorted. When I was trying to blend a burnt orange and dark-ish blue, the blending would eventually smear to pink in stark contrast from what the blend is supposed to make (see first attached image). I tested the same blend in Procreate as a reference and it had no such issues at all. I got the weird smeary brown I expected to get.

After experimenting to try to understand the issue better, I found that if I set the color space of the document to RGB/16 instead of RGB/8 that the issue went away entirely. I tried the same blend of colors and got the correct result I was expecting to get from smudging these two colors together (see first attached image again). I also found that blending colors in general via any method seemed to generally work better in the RGB/16 color space (I kept getting a sort of stripy effect in RGB/8) so I was very pleased with the find.

So with that, I thought, problem fixed! I can do everything I want now with no issues. I was anticipating a performance hit of some kind for using the higher bit depth, but there didn't seem to be any downside to the change. Well, that held true until I tried to do some hatching. So, what I found is that I can make a singular contiguous stroke of any length at any speed my hand can manage and Affinity Designer responds amazingly quick, almost instantaneously. It is wonderful. However, I also found that if I make a lot of rapid strokes of any length with any brush, Affinity cannot keep up. If I keep making little hatching strokes, the delay can range from 0.5-1.5 seconds to 5-10 seconds. So I can make a lot of marks, then pull my pen away from the screen, and over the next several seconds watch as Designer slowly populates in my brush strokes. This is a fairly frustrating issue because I use hatching a lot and it even hinders normal handwriting. Please see the attached video to see my demonstration of the issue. 

Also, the delay in fast stroke rendering varies over time and seems to change based on the length of time I have been using my iPad, not with document complexity or resolution. The delay is smallest after I freshly restart my iPad, and is longest after using it for some hours. 

I also tested these issues in Affinity Photo. I found that the behavior of the Smudge Brush Tool is the same, but there is no delay in rendering fast strokes in RGB/16 mode. With that being the case, I could theoretically just use Affinity Photo for drawing/painting instead of Designer, but the Artboards feature of Designer is just so dang useful that I loath to give it up. 

For my hardware and software info, I am using the 2020 iPad Pro and the version of Affinity Designer is 1.8.6.1. The version of Affinity Photo I am using is 1.8.6.198.

Let me know if you have any questions or if you need any additional information from me.

Thank you,

Collin

 

Image 1: Demonstration of RGB/8 vs. RGB/16 smudging

277344199_Screenshot2020-12-14at4_33_54PM.thumb.png.14d5f511ecca639bccea54309dea4262.png

Video 1: Demonstration of the delay in rendering fast strokes in RGB/16 mode

Link to comment
Share on other sites

Update: In a strange twist, today I opened up Designer to do some sketching and found that now I am getting the opposite behavior of the stroke lag I showed in my video. My color space is still set to RGB/16 like it was in my video, but now if I make tons of short fast strokes there is no lag whatsoever; I can hatch as fast as my hand can go and it keeps up. However, now when I make a long singular stroke, if I move my hand moderately fast the single stroke rendering can't keep up and I can watch the stroke finish for a few seconds after I take my hand away. High frequency scribbling over a small area of canvas doesn't seem to trigger the lag, it seems to only be if my stroke is quickly traversing larger sections of the canvas. I guess this behavior is more what I would expect for a performance constrained program. 

If I notice any other changes in behavior I will post further updates. 

Link to comment
Share on other sites

So, after continuing to use Designer the last few days, I have observed the behavior of the stroke lag flip multiple times. One day it will be fast long strokes and slow short strokes, and the next it will be slow long strokes and fast short strokes. Seems really odd to me that it would change over time. As far as I am aware I am not doing anything that would trigger the behavior difference, and as far as I can tell it doesn't correlate with anything else. Just sometimes it is one way, and sometimes it is the other. Sometimes it will be one way all day, sometimes it will change multiple times in a day.

Also, after doing a little more experimenting, I found that while the number of layers and objects in the document doesn't seem to affect the stroke lag, document resolution does (which makes sense). I've been using 11"x17" document size at a DPI of 400 (74,800 pixels), which is where I have observed the lag. If I make the same 11"x17" document at 300 DPI (56,100 pixels), it no longer lags. If I expand the artboard to say, 11"x19" at 300 DPI (62,700) I start to see lag, but it is only really noticeable on either long strokes or lots of short strokes, but not both, like I've been seeing on my 11"x17" 400 DPI documents. When I get to ridiculous sizes, all brush strokes become unusably laggy, even with RGB/8, which is what I expect.

I also noticed that the performance of a pixel layer depends completely on the resolution of the artboard it was created on at the time the pixel layer was created. If I make a small artboard and make a pixel layer on it, then resize the artboard to very large and make another pixel layer on it, the first pixel layer will not lag when I draw on it at the new size and the second pixel layer will. I also noticed strange behavior in how pixel layers resize themselves. If I make a pixel layer on an artboard, then expand the artboard in all directions from the center, then try drawing on the old pixel layer in the new artboard space, the pixel layer will expand in the left and upward directions indefinitely, but will not expand past the original right and bottom edges of the artboard when I try to draw in the right and bottom spaces of the new artboard area. Rasterizing the layer will force it to match the artboard's current resolution and dimensions, and the performance of the layer adjusts accordingly. 

So, like I said in my opening post, I don't know if the lag issue is really a bug or if it is just the performance limitation of the iPad and how Affinity is built (which, Affinity already performs so well in general it feels like magic). That said, I am used to working on large-ish documents at 400 DPI, and it is disappointing to see such a drag in performance when using RGB/16. If the blending issues I observed at RGB/8 were to get resolved, I would probably switch back to RGB/8 just so I can have better performance at the artboard sizes I usually use. If the Affinity team somehow squeezes more performance out of RGB/16 mode, I will likely stick with that since color blending seems to work better in general in that mode. 

Link to comment
Share on other sites

  • 2 weeks later...

It's all good, I saw a post somewhere regarding the holiday closure and expected the delay. I hope you all had an enjoyable time off!

Thank you for taking the time to read through my reports. If you ever have any questions for me, just let me know. I try to check back here periodically. 

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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.