Updates to New-graphics-settings-are-coming-to-binjr post

docs/blog/posts/New-graphics-settings-are-coming-to-binjr.md

@@ -1,6 +1,6 @@
 ---
-draft: false 
-date: 2024-02-25 
+draft: false
+date: 2024-02-27
 tags:
   - HiDPI
   - Graphics
@@ -19,7 +19,7 @@ comments: true
 
 I'm considering adding a new sub-category to binjr's `Settings` panel, which, for the time being, goes by the woefully unimaginative name of "Graphics".  
 
-Not that I am planning to turn binjr into a video game engine or anything, but because I've recently felt the need to surface some existing JavaFX properties pertaining to how its rendering stack operates and which are otherwise only settable via undocumented command line arguments, directly into the application, in a more accessible way.
+Not that I am planning to turn binjr into a video game engine or anything, but because I've recently felt the need to surface some existing JavaFX properties pertaining to how its rendering stack operates directly into the application. Up until now those were only settable via undocumented command line arguments, and having a more accessible way to control them seemed like a good idea.
 
 <!-- more -->
 
@@ -30,7 +30,7 @@ Not that I am planning to turn binjr into a video game engine or anything, but b
 
 binjr, courtesy of JavaFX, has always been capable of using hardware accelerated rendering on all supported platforms; via OpenGL on Linux and macOS (JavaFX Metal support is currently under development) and Direct3D on Windows. The framework automatically chooses the most appropriate rendering pipeline, falling back to a software-only implementation in the event that a suitable HW back-end could not be found.  
 
-It generally does a good job at that on pretty much all OS, but there are some cases were it can be useful to override its decision, in a way or the other: for instance you might want to try to force using the HW back-end even when the heuristics decided against that, like when running inside a virtual machine, or on some more exotic hardware.
+It generally does a good job at that on pretty much all OS, but there are some cases were it can be useful to override its decision, in one way or the other: for instance you might want to try and force using the HW back-end even when the heuristics weighted against that, like when running inside a virtual machine or on some more exotic hardware.
 
 Conversely, you might want to forcibly **disable** HW acceleration, if you experience rendering glitches or if the application is unstable.
 
@@ -44,7 +44,8 @@ And because this scaling doesn't rely on the underlying operating system's graph
 
 But since JavaFX's scaling is entirely independent from the environment it runs on, this means the framework has to be able to retrieve the underlying platform-wide scaling factor and apply it internally by default in order to make users' life simple. It usually does a good job at this, but it can sometime be a bit problematic.
 
-Fist of all, there are some cases where detecting the scale factor automatically just doesn't work well: on Windows or macOS, this is generally not an issue, but on Linux is can be tricky. For instance, JavaFX will attempt to retrieve that info from configuration files typically used by GNOME, which can leaves users of other desktop environments out of luck. And while it's always possible for savvy users to add the right bits of configuration to their desktop to workaround the issue (i.e. set `org.gnome.desktop.interface scaling-factor` or export `GDK_SCALE`), the results can sometimes be unsatisfactory: for example, forcing GNOME's lack of support for fractional scale factors onto KDE, which **does** support those.
+Fist of all, there are some cases where detecting the scale factor automatically just doesn't work well: on Windows or macOS, this is generally not an issue, but on Linux is can be tricky. For instance, JavaFX will attempt to retrieve that info from configuration files typically used by GNOME, which can leaves users of other desktop environments out of luck.  
+And while it's always possible for savvy users to add the right bits of configuration to their desktop to workaround the issue (i.e. set `org.gnome.desktop.interface scaling-factor` or export `GDK_SCALE`), the results can sometimes be unsatisfactory, for example forcing GNOME's lack of support for fractional scale factors onto KDE, which does support those.
 
 And of course, regardless of the environment, there can always be cases where a user might want to use a different scale for their binjr window than for the rest of their desktop.
 
@@ -57,7 +58,7 @@ This feels like a good compromise in exposing _some_ of the possibilities enable
 
 With that said, this is still a work-in-progress, so feel free to chime in if you'd like to propose something else.
 
-Please note that this option is unfortunately **not available** on macOS, since apparently JavaFX lacks a way to override the detect scaling factor on this platform. Although, as mentioned earlier, the automatic detection is usually flawless on macOS, it is this still a bit disappointing, as scaling an app's window independently from the rest of the desktop could always prove useful (unless the OS itself already has this built-in? I must admit I don't know much about macs).
+Please note that this option is unfortunately **not available** on macOS, since apparently JavaFX lacks a way to override the detect scaling factor on this platform. Although, as mentioned earlier, the automatic detection is usually flawless on macOS, it is this still a bit disappointing, as scaling an app's window independently from the rest of the desktop could always prove useful (unless the OS itself already has this built-in? I must admit I don't know much about Macs).
 
 
 ## Screenshot scaling factor