[β103] Lag when editing Live Procedural Texture mask

[R C-R]

When I try to edit the mask of a Live Procedural Texture filter, for example by painting on it with the Erase or Paint Brush tool, the brush response on the canvas is OK for textures created from simple equations, but it quickly becomes increasingly laggy & less usable as the complexity of the filter increases. This is true even for simple documents containing just one pixel & one live filter layer on small sized canvases.

For example, this Proc texture mask lag demo.afphoto file is only 800 x 600 px. I applied the following admittedly fairly complex live procedural texture to its "texture 1" layer:

Trying to paint on its built-in mask results in extremely jerky, laggy brush response. I realize my iMac is old & underpowered, but I am hoping there is some way of improving brush performance before the final release, because otherwise it will be just about unusable on machines like mine.

The texture is a variant of the built-in Marble preset, modified (somewhat blindly due to the lack of documentation) to produce a multicolored texture. As you can see from the above, I saved it as a custom preset with the name "Colored Clouds," & exported it as Colored Clouds.aftoolpresets.

 

[Polygonius]

Can not confirm, i had a gradient-mask of the layer itself and jump all presets - no problem so far. Even with filigran brush-strokes it works fast, i would say IMMEDIATELY. 

I guess its a question of HW - my activitymonitor shows for very short a lot of CPU by changing the "mask" or switch the prestes, but came back to normal < 0,5 secondes ???

However you can rasterize the textrure filter, if inside a group with a filled pixel-layer in. Maybe than it works better on your HW? 

 

[R C-R]

3 hours ago, Polygonius said:

I guess its a question of HW - my activitymonitor shows for very short a lot of CPU by changing the "mask" or switch the prestes, but came back to normal < 0,5 secondes ???

For me, Activity Monitor shows very brief but not very tall CPU use spikes when changing from one procedural filter to another. But the weird thing is even if I am not actually painting on the mask to change its opacity & just moving the tool around on the canvas with the filter layer selected, without pressing the mouse button still I get very tall use spikes that persist for as long as I am moving the pointer. They are not proportional to the brush size, or as far as I can tell to any other brush parameter, so it seems to be that it is the process of drawing the brush preview on the canvas itself that is using unusually large amounts of CPU time.

[Old Bruce]

35 minutes ago, R C-R said:

so it seems to be that it is the process of drawing the brush preview on the canvas itself that is using unusually large amounts of CPU time.

Makes perfect sense.

[Polygonius]

2 hours ago, R C-R said:

 They are not proportional to the brush size, or as far as I can tell to any other brush parameter, so it seems to be that it is the process of drawing the brush preview on the canvas itself that is using unusually large amounts of CPU time.

I can draw even brushes with 1% repeat (i guess the size ist not relevant, just the repeat in which variation, how often in variance??????) , directly on the "mask" of this filter.... no, never, nothing...  but i agree... this was LONG TIME a big problem... NOW with metal-on- ON MY SYSTEM .

I´m very very happy with that performances. Seems to be really assembler-work... However thank you SERIF????  I do not know, but its marvelous! 

---

2 hours ago, R C-R said:

For me, Activity Monitor shows very brief but not very tall CPU use spikes when changing from one procedural filter to another. But the weird thing is even if I am not actually painting on the mask to change its opacity & just moving the tool around on the canvas with the filter layer selected, without pressing the mouse button still I get very tall use spikes that persist for as long as I am moving the pointer. They are not proportional to the brush size, or as far as I can tell to any other brush parameter, so it seems to be that it is the process of drawing the brush preview on the canvas itself that is using unusually large amounts of CPU time.

 

Maybe "drawing" the filter itself could solve the Cpud-problem??? How much "back to future" has an app be????  Why not Why not raster, if (almost) happy, especially with your "grandpa-HW"?????? 

Other option??? think no! And thats okay! We change the White-knigjt position: In this case i guess SERIF is doing a lot "ASSEMBLER" code for each CURRENT HW. AFAIK its the most complicated, or Time-INTENSIV code... ever. Rusty HW will not supported anymore? Is 7 eras old?  Thats a really good question Mr. Una ( nope i mean this really "OPEN" i can understand this guy, in such things....)

Keeping this in mind, where should they say... its end here? By Madam Ada Lovelace? 

YOU would be the first person to defend SERIF, if there is just small small--wisch-for 1-hour-code-please-an option-OPTION... NOW they should ASSEMBLE just for you and your "vetrean- HW"....????? 

It a very good question in the Moore-Age, how long commit a non written-compact for how long, if the subkects permanantl cahnege? 

[h_d]

My HW is slightly more ancient than yours @R C-R (mid-2012 MacBook Air) but my OS is slightly newer (10.14 Mojave) and I'm seeing something similar. Very laggy drawing of the brush preview, but the brush itself works smoothly while painting. And no lag of any kind with the Eraser tool.

 

Cheers,

H

[R C-R]

1 hour ago, Polygonius said:

Why not Why not raster, if (almost) happy, especially with your "grandpa-HW"?????? 

If you mean using the regular instead of live version of the filter, it is because I want to be able to adjust the opacity of the built-in mask, just like for any other filter, & of course because I want to be able to adjust the filter itself non-destructively. Isn't that obvious?

I can't make much sense of the rest of your post, but from what I can tell it isn't relevant to the issue I am seeing in this beta version.

56 minutes ago, h_d said:

My HW is slightly more ancient than yours @R C-R (mid-2012 MacBook Air) but my OS is slightly newer (10.14 Mojave) and I'm seeing something similar. Very laggy drawing of the brush preview, but the brush itself works smoothly while painting. And no lag of any kind with the Eraser tool.

For me, both the Paint & Eraser Brush tools lag behind the pointer's position on the canvas while painting on the mask. Visually, it looks a lot like the effect seen in a low frame rate GIF animation where the tool's effect jumps between frames, making it look jittery. I don't know how else to describe it.

[Chris B]

It's very slow on my 2017 MacBook Pro without Metal and my Windows machine almost gave up the ghost at one point. I can pass this back to the developers to see if anything can be done.

[R C-R]

I don't know if this will be of any help but the way the mask preview is rendered on the document looks very similar to the way the screen is refreshed when my Macs are booted into Safe Mode -- slowly, line by line, from top to bottom. Since in Safe Mode all screen rendering is done in software, I suspect rendering the changes to the mask of a procedural texture isn't being done with the fastest available GPU acceleration (Metal, OpenGL, whatever).

Since the 103 build still hasn't fixed the missing Preferences > Performance > Display menu options issue, I wonder if that has something to do with it, like maybe on some Mac models the display rendering is defaulting to OpenGL (Basic) & we just can't see it?

Anyway, I hope the developers can find some way to speed this up on the affected machines.