R C-R

You can trust what Acrobat or Apple's Preview app's "Inspector" window shows, or just about any other app that shows the dimensions of the image. Just don't trust Finder's "Get Info" window.

Games are very different from graphics apps because the latter frequently need to write very large amounts of data back to files with 100% accuracy. Games don't need to do that -- in fact, they don't even have to render everything on screen with pixel for pixel or texel for texel accuracy. Game engines are optimized to do a few things very well but they would not be able to handle the much broader range of things graphics creation apps must be able to do. Where a typical graphics app might have 5% of its code suitable for parallel processing in GPU cores, game engines typically are optimized for much higher percentages. There is no getting around it: the number of CPU cores any general purpose app can use will vary greatly depending on the process, the amount of data that needs to be processed, how much of it can be offloaded to the GPU, how many other processes the OS runs concurrently independently of or as a service provided to the app, the amount of RAM the OS allows the app to use, & all the rest of it. So while the developers might be willing to give you a maximum number of cores the Affinity apps can use under ideal conditions, it would come with so many qualifiers & caveats that it would just about meaningless. If you want to configure a system to maximize its performance with Affinity, you have to consider it from a systems standpoint, which means considering everything that contributes to that, not just one "figure of merit" that only applies to a small part of it. That would be like trying to judge how well a car will perform based only on the peak horsepower its engine can develop. It is never that simple.

Inpainting algorithms typically look for a mix of structural & textural patterns in variable sized areas surrounding the selection to determine what to fill the selected area with & how to blend in the edges of the filled in area. Because of this, excluding a part of those surrounding areas usually would not work very well since it would likely cause the algorithm to miss patterns needed to produce a good fill & blend. For much the same reason starting with a small selection often produce the best results because nearby areas are more likely to include patterns better suited for the fill. Repeating the process with a larger selection area enclosing the already inpainted one or more often just around its edges can sometimes improve the results. It all depends on the patterns the algorithm has to work with, which is why using a combination of inpainting & the other retouching tools often produces the best results. It is somewhat like the process used by art restorers on physical artwork -- human judgement is a necessary part of it because algorithms can't (yet) "see" things like humans do. But unlike the restorers, working in the digital realm gives us the ability to undo results we don't like very easily.

Typically in Affinity Photo Select > Select Sampled Color is used to make a selection & then a brush or fill tool (or possibly a style) is used to change the color of the selection. Selections can also be saved to a spare channel or to a file while can be loaded back into the document or into others, somewhat like the Save & Load options in PS.

It is hard to tell from the tiny screenshot, but it looks like you have downloaded the Affinity Photo trial instead of the Affinity Designer one. Symbols are a feature of Affinity Designer but not Affinity Photo.

Just curious, but how would you want to see this implemented? The Context toolbar dropdown can't be made much larger -- as it is, it already takes up a lot of screen space that on smaller screens obscures the canvas. So if some of that space is devoted to a search field like in the Swatches Studio panel, it would subtract from the area that displays to color swatches, which would mean more scrolling for swatch categories like the Pantone ones that have a lot of entries. Personally, I would find that annoying. I much prefer to use the Swatches panel for that, in part because it can be resized as needed and/or dragged out of the Studio to become a 'floating' panel when that is more convenient. Floating panels can be collapsed to just their titlebars by double-clicking on their title bar names & restored to full size with a single click on the collapsed titlebar, which makes it quick & easy to collapse them when they would obscure the work area & open them back up when needed.

There is no 'magic wand' tool in Affinity Designer. For raster image work (bitmaps & pixel based layers) you really need Affinity Photo, which has many tools more like those in Photoshop, including a 'magic wand' tool called the "Flood Select Tool" in AP.

@RITESH Please understand that these forums are intended for topics related specifically to the Affinity applications, not for very broad topics like how computers work or how to code in C++. If you need help with things like that, search the web, buy a few books, or enroll in classes.

Like @kaffeeundsalz said, for this particular image the Recolor adjustment in Affinity Designer's Pixel Persona will do the job nicely. You will probably want to make a selection first to exclude the Nolan logo & the text next to it, easily done by using the Rectangular Marquee Selection Tool to select a white area that includes it & then using the Select menu > Invert Pixel selection to invert the selection. Otherwise, you may find that parts of this area take on the blue color because they are anti-aliased in greys that contain some green.

It looks pixelated at high zoom levels because even though the ice cream cone layer is a resolution-independent vector curve layer, it is filled with a low resolution bitmap image, probably a png judging by the transparency that allows the purple layer below it to show where there are no cones or candy sprinkles. That may be fine if it will only be used at 100% size, but if not either replace the bitmap fill with a higher resolution version or draw the ice cream cones & sprinkles using vector shapes. Symbols would be ideal for this -- draw one instance of the cone, make it a symbol, & place more instances of it at the other locations, rotated as needed to match the bitmap.

FWIW, I downloaded your file onto my older iMac (specs below in my sig) & I do not see much CPU use or an appreciable lag when enabling/disabling layers or changing the adjustment layer settings or anything else I have tried with it. As you can tell from the specs, my iMac is a far less powerful system than yours, so I do not know why you are seeing slowdowns or high CPU use. Are you maybe running some third party system "enhancements" that could cause this? EDIT: I also just noticed that the Abandoned_Row_Houses.afphoto as downloaded from this page is, according to Finder's Get Info, 419,107,618 bytes (419.1 MB on disk), many times larger than 24 MB figure you mentioned. Are you sure you attached the correct .afphoto file to your post?

It is more about all the individual operations being performed than anything else. Some will use more cores when no other processes with higher priorities are using them, some won't. It is somewhat like multi-threading, another form of parallelism. Some operations can benefit from multi-threading because their threads can be programmed to run independently of the others but when they can't, the the slowest thread(s) will dictate how quickly the operation can be completed before the next one can begin. Of course, it is really much more complicated than that, but the point is there is always much more going on in the system than just the operation(s) initiated by any one app, & the OS controls how much CPU time each of them gets. The same thing applies for memory allocation & every other system resource. It isn't like the old days when the primitive OS's of that era relied on cooperative multitasking that gave nearly unlimited control over system resources to each app in turn. Now everything relies on preemptive multitasking strictly controlled by the OS. Among other things, that's why apps can crash without bringing down the whole system. I have no idea what the maximum number of cores the Affinity apps could use, but I doubt any process can use all of them for more than very brief intervals, & only a few processes could even do that.

Where did you find the QuickStart_Guide.pdf file? Normally, I would expect the .afmacros files to be in the same location.

Thanks for the confirmation that I guessed right. Since I have not touched a PC for about two decades, I am never sure about the Windows equivalents for Mac keyboard shortcuts. Regarding that, do Windows menus show the assigned shortcuts next to the menu item names like they do on Macs, or otherwise indicate what they are?

The download should be a zipped file named Affinity free-macro-pack.zip, downloaded to whatever is the default location for downloads on your system. Without knowing if you are using a Mac or PC I can't help you determine that, but if you search on that name you should be able to find it easily enough. Then just unzip the file, using whatever utility or method your OS supports. You should end up with a folder with several .afmacros files & a QuickStart_Guide.pdf that explains the install procedure.

Assuming you are using Affinity Photo, the Select menu > Select Sampled Color is probably the best way to do this. The help topic "Sampled color pixel selections" explains how this works, but keep in mind that even for very simple png files what appears to be a single color most likely is really a range of similar colors, so you will probably have to do a little experimentation with the tolerance & sample point to select everything you want to change & nothing that you do not. This usually is easiest to do when zoomed in so you can see the individual pixels that are being selected. Once you have the selection you want, use the Paint Brush Tool set to your color B to paint over the selected pixels.

My guess is you have accidentally invoked the View menu > Studio submenu "Hide Studio" command, probably by typing its keyboard shortcut. On Macs the default shortcut is Shift + Command + H. On Windows I think it is Shift + Control + H, but if you open the menu it should display whatever the shortcut is on your system.

GPU accelerated computing works by offloading computationally intensive tasks to the GPU to take advantage of the massive parallelism of its cores. But that limits its usefulness to iterative tasks that are independent of each another & do not need to be processed sequentially or interactively. As the NVIDIA chart shows, that often is no more than 5% of the code. It is also limited by how much data needs to be offloaded to the GPU to perform the computations, how quickly that can be done, & how quickly the results can be sent back to the CPU for further processing, stored in working memory, or eventually written to a file. In a nutshell, what this means is there are not as many processes that actually benefit from GPU acceleration as one might think -- often, the overhead of moving the data into & out of the GPU's cores would take longer than simply doing everything in the CPU, particularly when the amount of data is large. It also means that the CPU & supporting buss architecture that connects everything together must still be of sufficiently high performance & the OS must provide app access to low level routines that minimize overhead to see any overall performance improvements. Additionally, there must be enough real memory (RAM) installed to handle not just the app's needs but also all the other processes the OS must run concurrently, which will vary depending on the OS version, its configuration, the size of the files & the amount of code that need to be loaded into memory at any one time, & so on. So if you are looking for simple "one size fits all" answers, there aren't any. Some operations will benefit most from a more powerful CPU & others from a more powerful GPU. Some will benefit significantly from more available memory while it won't make any difference for others. What matters most is that no one part of the system causes a bottleneck that prevents the other parts from working at their maximum efficiency.

DPI is irrelevant for exporting to pixel-based (rasterized) file formats for web pages. What matters is the pixel resolution of the file (how many total pixels it includes), its intended display size on the web page (like covering most of the page or just a small section of it), & the most acceptable tradeoff between high quality (which requires larger file sizes with more pixels & no or little lossy compression & thus longer download times) & fast loading of the page. Your web developer should be able to advise you about this, based on the layout of the pages & what you find most acceptable in terms of quality vs. load times.

There are many ways to do this. The simplest one that occurred to me was to use layer clipping, something like this ad box.afdesign file. You can set the background to whatever color you want with the fill property of the larger rectangle.

That is up to you. If the 3D effect is an important part of the logo, either allow rasterization or (tediously) recreate it using multiple vectors of different colors stacked to get (more or less) the same look. Well, in a sense clipping is cropping, but even so I think the 'round trip' export & import of the SVG version should have the same or nearly the same layer structure. I also have no idea why Finder views & Quick Look display the exported SVG with the texture over the tan rectangle & properly clipped to it, but the implication is the SVG import function in Affinity still needs work. It might be better in the current 1.6 beta but I have not tried it with that.

I am not sure what you want me to see. The original issue (from 2015) was about the search function not working in the Swatches panel. That was fixed long ago. But there was never a search field in the Context toolbar's color swatches dropdown, which only appears temporarily when an item that supports fill & stroke colors is selected with a tool that allows setting them. The dropdown can't be resized so you should see a scrollbar when there are more color swatches than will fit in it, like this (although it may appear only when scrolling, depending on your System Preferences settings): Since unlike the Studio panel the dropdown is of a fixed size, only appears in some contexts, & won't stay open, there isn't any compelling reason I can think of for the UI to be consistent for both.

Why would you need to do that?

Sorry for the misunderstanding. However, if you mean mixing & grouping tools from different Personas into one Tool panel, it is unlikely that will ever be supported for three reasons: 1. A primary design feature of the Affinity apps is to split functions into the different Personas. This is done to reduce clutter in both the Tool panel & in the main Toolbar & to allow the apps to run on smaller screens without the need to do excessive scrolling or resort to other means to cram everything into one UI. 2. Many of the tools & main toolbar items only apply to one Persona, so mixing tools from different Personas would mean a lot of items were greyed out unless you were in the appropriate one. 3. Splitting functions into different Personas allows various "under the hood" optimizations in the code that reduce memory & CPU requirements. This is part of what makes the Affinity apps responsive enough to provide realtime previews of effects, blend modes, etc., to handle extremely large files without taxing the system, & to run on relatively low powered hardware.

Rasterize nothing won't preserve the 3D effects on the letters, so the SVG export will look something like this: Also, reimporting the SVG export back into Affinity Designer I get this: With the layers panel expanded for the lower section, there is a cropping mask, a crosshatch image, & a tan rectangle, but they do not combine to form the same texture effect as in the first image above: However, using Quick Look or Finder to view the exported SVG (with or without rasterizing) the texture looks fine.