A_B_C Posted September 6, 2017 Share Posted September 6, 2017 You are right, the initial brush strokes (red-orange) kept their original dimensions after resizing the document, but you will also notice that the area that accepted my new (blue-green) brush strokes after resizing was exactly four times the area of the original pixel layer. So the resizing had an effect on the area that is susceptible to “paint,” if you see what I mean. Hmm … Link to comment Share on other sites More sharing options...
lepr Posted September 6, 2017 Share Posted September 6, 2017 . A_B_C 1 Link to comment Share on other sites More sharing options...
Bri-Toon Posted September 6, 2017 Share Posted September 6, 2017 That's what I'm thinking. Could it be triggered by size variation? In that file I attached, I inserted a background layer from another drawing in which the the canvas was resized. I wonder if bringing in to that other file corrupted it or if that's not possible. Something that these two issues do have in common, however, is that it's a problem with pixel layers. There is something else, not related to the above. Create two shapes. One with say a gradient fill but no stroke, and the other can have any look as long as it has a stroke. Copy the gradient shape, and then paste the style to the stroked shape. The stroked shape will now have the gradient style like the other. Now undo it. You will see that you cannot bring back the stroke. The website is still a work in progress. The "Comics" and "Shop" sections are not yet ready. Feel free to connect with me and let me know what you like or what can be improved. You can contact me here, on my contact page, YouTube channel, or Twitter account. Thanks and have a great day! Link to comment Share on other sites More sharing options...
A_B_C Posted September 7, 2017 Share Posted September 7, 2017 You are right. Pixel layers should be susceptible to “paint” everywhere. However, I just checked the App Store version, and it behaves the same as the Beta under resizing operations. Only the fancy effects of the redrawing bug are missing … Link to comment Share on other sites More sharing options...
Morten_Hjort Posted September 10, 2017 Share Posted September 10, 2017 Maybe its already been posted, but I'm on a 2016 15" tMBP and when I activate Metal as a renderer (Sierra) the performance is pretty bad. Changing it to OpenGL make it fast again. Shouldn't Metal in general have better performance? Link to comment Share on other sites More sharing options...
Frank Jonen Posted September 11, 2017 Share Posted September 11, 2017 (edited) Here's something that's bothersome for me with the output to PDF. I have a vector shape, within that shape I have bitmaps and other vector shapes nested. A couple of LUT layers and bitmap comps later and I output to PDF. The bitmap sections itself are cut up pretty well by features, so that's cool. There was pretty much zero waste there. However I lose the vector outline of the base shape that the other stuff was nested in. This increases the file size quite a bit since it introduces an extra alpha to the file. The PDF output should retain the outline and just have PNG portions overlaid on top for transparency. It could be that it's too hard for the app to figure out which outline to retain in a mixed media comp. I'm way out of Illustrator territory here, so I don't really have a comparison. If that's an issue, maybe we could help it along by tagging a shape with 'vector cut' for example. Which then would also carry through to any bitmap format that can carry outlines (to flow text around and make vector knock outs). We can already exclude shapes from snapping, maybe that could be added to the same menu section and be displayed similarly in the layer stack. (Probably something worth having anyway). Edit: Nesting the layer group in another shape retains the outline as vector in the output. But then I have both, the PNG alpha in addition to the new shape which bear the potential of a moiré effect. Edited September 11, 2017 by Frank Jonen Comment on nesting Link to comment Share on other sites More sharing options...
Dazmondo77 Posted September 11, 2017 Share Posted September 11, 2017 Possible bug with type on a path control points? I'm not able to move the red control points, it's as-if they are locked? predick 1 Mac Pro Cheese-grater (Early 2009) 2.93 GHz 6-Core Intel Xeon 48 GB 1333 MHz DDR3 ECC Ram, Sapphire Pulse Radeon RX 580 8GB GDDR5, Ugee 19" Graphics Tablet Monitor Triple boot via OCLP 1.2.1 - Mac OS Monterey 12.7.1, Sonoma 14.1.1 and Mojave 10.14.6 Affinity Publisher, Designer and Photo 1.10.5 - 2.2.1 www.bingercreative.co.uk Link to comment Share on other sites More sharing options...
Staff MattP Posted September 11, 2017 Author Staff Share Posted September 11, 2017 21 hours ago, Morten_Hjort said: Maybe its already been posted, but I'm on a 2016 15" tMBP and when I activate Metal as a renderer (Sierra) the performance is pretty bad. Changing it to OpenGL make it fast again. Shouldn't Metal in general have better performance? I'm developing on the 15" 2016 MacBook Pro with TouchBar - and Metal is noticeably faster on mine I've just fixed something over the weekend that was causing simple documents to go slower than they should've done, so maybe that might help? It'll be in this week's beta (I was trying to fix that problem last week, so wasn't in a position to launch a new Beta last week - but I can launch one soon, now) Let me know if this changes things for you in the next beta version! bagmetv 1 Link to comment Share on other sites More sharing options...
Staff MattP Posted September 11, 2017 Author Staff Share Posted September 11, 2017 1 hour ago, Dazmondo77 said: Possible bug with type on a path control points? I'm not able to move the red control points, it's as-if they are locked? I think this was a beta version bug that was fixed then accidentally re-broken. It is fixed again for the next beta I believe - sorry! predick and bagmetv 2 Link to comment Share on other sites More sharing options...
wingsline Posted September 12, 2017 Share Posted September 12, 2017 Thank you for the new beta. The Recent, Used, etc. font categories are very blurry on the font selector. Using non-retina screen with MacOS Sierra. Link to comment Share on other sites More sharing options...
Staff MEB Posted September 13, 2017 Staff Share Posted September 13, 2017 Hi arpadolasz, Thanks for the heads up. Issue logged. A Guide to Learning Affinity Software Link to comment Share on other sites More sharing options...
ianrobertdouglas Posted October 23, 2017 Share Posted October 23, 2017 On 8/27/2017 at 0:07 PM, MattP said: We need a little more information though - because I’m not seeing the same stability problems. I’m guessing it may have a lot to do with the kind of objects you use inside the symbol, or the structure of the items inside the symbol? Maybe even constraints? It would help a lot to see a sample document that gives you issues as we can look through the document in the debugger and see what’s likely to be causing the issues you see... thanks for any help you can give Sorry to be so late to reply. I think it may be a matter of the complexity of the symbols (I don't use constraints: I'm talking about using symbols in geometrical graphic design), or perhaps hitting font limits because of the sandboxing issue (which I truly hope was not the case). At any rate, the next time this happens in the normal flow of my work I will save the file aside and send it to you. MattP 1 Link to comment Share on other sites More sharing options...
Recommended Posts