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

fde101

Members
  • Posts

    4,951
  • Joined

  • Last visited

Everything posted by fde101

  1. Not sure why this would block access to GPUs as even a number of Intel-compiled games for Windows run smoothly with accelerated 3D under ARM builds of Windows 11. For moderate project sizes I would not think the translation layer would be a major performance barrier - slower than native, sure, but it's not THAT bad, unless you are pushing the limits of what the system can handle with a relatively large/complex project. Note that the x64 emulation is only provided by Windows 11 on ARM, not by Windows 10, so the Affinity apps would not work under Windows 10 on ARM - only on 11 - but I'm not sure why GPU support would be a limitation. The CPU type should be completely irrelevant to that.
  2. I would rather pay $100 a year to upgrade a software product than a penny a decade for a subscription. Ick. No thanks.
  3. I believe the intended workflow is that you select a vector shape (such as a rectangle or a cat) then use the color picker to pick a color from somewhere else in the document to apply it to that shape. It is fairly obvious when paying attention that the tool was engineered around a vector workflow, not a raster one.
  4. This is not at all clear. There are plenty of companies which own other companies but have different business models from the companies they own. Image-Line (makers of the DAW FL Studio) own several highly recognizable plugin vendors (ex. UVI) which have very different business models from I-L itself; they have owned several of those companies for several years now and have not made any attempts to change their business models. I am taking a wait-and-see approach on this. There is no point speculating, only time will tell. No, in other words, you will need to pay for version 3 just like you had to pay for version 2 when it came out. Free updates to v2 for those who own v2, then pay for v3.
  5. When "Apply to Selection" is not checked, the color which is picked up is placed in the circle used by the color picker which is embedded in the Color panel, which you can click on to set it as the fill or stroke color (depending on which of the circles is selected there). It is not directly selected as a stroke or fill color, possibly because doing so might have the side-effect of setting the fill or stroke color for whatever is selected? Alternatively, you do not need to have a layer selected if the "Source" is set to "Global" in the context toolbar. If you keep all layers deselected, then you can leave "Apply to Selection" checked and the color will be set by the tool without impacting the colors of the existing layers.
  6. One problem you are going to face is that as soon as you export it to some vector format it will *always* be an approximation of some sort. Sine and cosine waves are interchangeable with each other, but neither can be perfectly represented as a Bézier curve, and they cannot be coded into most vector graphics formats. There is some discussion around this here: https://math.stackexchange.com/questions/4235124/getting-the-most-accurate-bezier-curve-that-plots-a-sine-wave PostScript does have a few trig functions, including sine and cosine, so PDF might as well (I can't seem to figure out the right search terms to identify this), so it *might* be possible to code this into a PDF, but other vector formats (such as SVG) would only be able to contain approximations.
  7. One thing to remember is that Photo *never* actually opens a JPEG. It always works with its own custom document format. When you "open" / import a JPEG image, it is being placed on a layer in an Affinity document. When you "save" / "export" the document, you are exporting the Affinity document, not just the JPEG image. Even if the image itself was not touched, you are not exporting the original JPEG, but the Affinity document which just happens to match its appearance. Consequently, you are not "recompressing" the JPEG, but newly compressing the Affinity document which did not previously exist.
  8. It does that. All of the Affinity products do; this does not mean there is a leak. If you had evidence that there was a leak, then it should be filed as a bug report. This part of the forum is meant for feature requests. Bug reports go here: https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/
  9. The problem here is that the export persona is decidedly biased toward artboard-based documents, while Publisher is intended primarily toward page-based documents, with rather different requirements for export and publication. The Photo persona in Publisher makes sense to allow manipulation of photos embedded within publications, and the Designer persona similarly to enhance the ability to work with vector artwork within publications, but while it is possible to work with artboard-based documents (as well as standalone photos) within these personas within Publisher, that does not seem to be the intended function of their inclusion. Including the Photo and Designer personas within Publisher does not strike me as an inconsistency in these statements as their inclusion does well to support Publisher's primary function of supporting page-oriented print-focused document preparation, but the additional personas (Export, Tone Mapping, Liquify) do not really contribute toward this purpose, and so would be much more out of place within the product.
  10. It probably will as Serif has consistently indicated over the years that they have no intention of merging the apps; examples:
  11. This section of the forum is for feature requests. Bug reports belong in a different part of the forum.
  12. Publisher does offer limited access to the Develop persona, but it is slightly hidden. If you insert a RAW image, the context toolbar shows a "Develop Image" button that switches to the Develop persona for that image. While Photo does allow access to the Develop persona for non-RAW images, it doesn't really make that much of a difference since just about everything that can be done in the Develop persona with a non-RAW image could be done just as well in the Photo persona. What is really "missing" in Publisher mostly amounts to the Liquify, Tone Mapping and Export personas. Personally I think that is fine - I would rather they add a Prepress persona to Publisher and a Tracing persona to Designer.
  13. You do realize you can do stuff like that in the Finder too, right? You can set up the search and save it, with the option to include the saved search in the sidebar.
  14. Agreed, and that was never the issue here. When I first saw the post it struck me as reading like a bug report, but it was posted in the section of the forum meant for feature requests. I was questioning if it was posted in the right section on the forums, not whether or not it was permitted to be posted at all.
  15. The purpose of which is defined here: https://forum.affinity.serif.com/index.php?/forum/122-feedback-for-the-affinity-v2-suite-of-products/ This is primarily a section of the forum intended for feature requests. Granted the name is a bit confusing given that function, but that is how it is set up for use.
  16. You may be better off pushing the Wine project to improve their Windows emulation support in the areas that currently prevent the Windows version from working well via that mechanism. You would *definitely* have been better off adding this to one of the existing threads on the topic rather than forking off yet another pointless duplicate one.
  17. Is this a feature request (you want Serif to continue breaking things with every update), or is it a misplaced bug report in the wrong place on the forums?
  18. Agree, 96 = 4 * 24, 72 = 3 * 24, so need 12 * 24 = 288 to make this work.
  19. I believe the file format was designed to allow the file to be updated in place rather than replaced as a performance optimization. Rather than writing everything each time you save, the application only needs to rewrite parts of the file that have changed. If that is an accurate assessment, then a feature such as the one you describe would defeat that optimization and slow down the save process by forcing the application to write the entire file every time it gets saved, as Photo does now when doing PSD round-trips with DAM/raw processors such as Capture One, which takes quite noticeably longer than saving a native Affinity document does after the initial save. This is not to say that it couldn't be done, or that it shouldn't be considered, but it is a factor to bear in mind that would likely be impacted by enabling a feature like this.
  20. Not sure that I agree on that one, but regardless, there is usually more space to make a set of sliders wider than taller, and a longer slider allows for more precision. That said, a slider will never offer the same level of precision for a wide range of values that you can obtain with controls that allow for direct or relative entry as they are always constrained by the pixel resolution sitting underneath them (most GUIs do not allow for sub-pixel mouse tracking so if the slider is 150 pixels in length, for example, the slider can only input 150 distinct values). EDIT: if you were able to dedicate a display to the controls, you might have a case for a more mixer-like interface with a bunch of vertical sliders spread across the screen and controlling various parameters. In practice many of us are on single screens and the time taken to move the mouse from one screen to another (to make a selection on the image then go across to manipulate the values) would probably slow things down, and using that type of interface on a screen shared with the image would result in too little horizontal space for the image itself. A touchscreen could eliminate the mouse movement issue, and one interesting possibility might be an iPad-based remote app (or Android tablet for that matter) to control the parameters of the image displayed on the computer, but for the interface on the computer itself, I'm not sure if a statistically significant percentage of users would find that type of interface to be a net gain.
  21. It actually stores and uses non-integer values behind the scenes, but rounds them for display. Some values allow the rounding to be adjusted in Preferences/Settings, but I don't see one for percentage values (which would be nice to have added). I believe that may have been requested before.
  22. The Arm64EC thing is kind of interesting, but it is basically a transitional tool for developers to use to gradually provide native ARM64 ports as part of the development process, it is not how the "emulation" Windows provides work. My comment was more that I don't think Serif is doing this at all - I don't think they are explicitly transitioning their apps to ARM for Windows (yet?) - so they are likely fully "emulated" at this point (in whatever sense Windows "emulates" x64 under ARM64 systems).
  23. UI font size should really be controlled by the operating system rather than the application, but there actually is a "Large" option under the User Interface section of Preferences/Settings (at least on macOS; from what I have seen on the forums the Windows version is missing a few of the UI options that the macOS version offers).
×
×
  • 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.