Changes and improvements to the documentation (#3253)

* FEATURES.md improvements

* docs improvements

* typo fix: 'mean' -> 'main'

Co-authored-by: daxpedda <daxpedda@gmail.com>

---------

Co-authored-by: daxpedda <daxpedda@gmail.com>

src/dpi.rs

@@ -4,13 +4,13 @@
 //!
 //! Modern computer screens don't have a consistent relationship between resolution and size.
 //! 1920x1080 is a common resolution for both desktop and mobile screens, despite mobile screens
-//! normally being less than a quarter the size of their desktop counterparts. What's more, neither
-//! desktop nor mobile screens are consistent resolutions within their own size classes - common
+//! typically being less than a quarter the size of their desktop counterparts. Moreover, neither
+//! desktop nor mobile screens have consistent resolutions within their own size classes - common
 //! mobile screens range from below 720p to above 1440p, and desktop screens range from 720p to 5K
 //! and beyond.
 //!
 //! Given that, it's a mistake to assume that 2D content will only be displayed on screens with
-//! a consistent pixel density. If you were to render a 96-pixel-square image on a 1080p screen,
+//! a consistent pixel density. If you were to render a 96-pixel-square image on a 1080p screen and
 //! then render the same image on a similarly-sized 4K screen, the 4K rendition would only take up
 //! about a quarter of the physical space as it did on the 1080p screen. That issue is especially
 //! problematic with text rendering, where quarter-sized text becomes a significant legibility
@@ -25,12 +25,12 @@
 //!
 //! The solution to this problem is to account for the device's *scale factor*. The scale factor is
 //! the factor UI elements should be scaled by to be consistent with the rest of the user's system -
-//! for example, a button that's normally 50 pixels across would be 100 pixels across on a device
+//! for example, a button that's usually 50 pixels across would be 100 pixels across on a device
 //! with a scale factor of `2.0`, or 75 pixels across with a scale factor of `1.5`.
 //!
 //! Many UI systems, such as CSS, expose DPI-dependent units like [points] or [picas]. That's
-//! usually a mistake, since there's no consistent mapping between the scale factor and the screen's
-//! actual DPI. Unless you're printing to a physical medium, you should work in scaled pixels rather
+//! usually a mistake since there's no consistent mapping between the scale factor and the screen's
+//! actual DPI. Unless printing to a physical medium, you should work in scaled pixels rather
 //! than any DPI-dependent units.
 //!
 //! ### Position and Size types
@@ -42,11 +42,11 @@
 //! coordinates as input, allowing you to use the most convenient coordinate system for your
 //! particular application.
 //!
-//! Winit's position and size types types are generic over their exact pixel type, `P`, to allow the
+//! Winit's position and size types are generic over their exact pixel type, `P`, to allow the
 //! API to have integer precision where appropriate (e.g. most window manipulation functions) and
 //! floating precision when necessary (e.g. logical sizes for fractional scale factors and touch
 //! input). If `P` is a floating-point type, please do not cast the values with `as {int}`. Doing so
-//! will truncate the fractional part of the float, rather than properly round to the nearest
+//! will truncate the fractional part of the float rather than properly round to the nearest
 //! integer. Use the provided `cast` function or [`From`]/[`Into`] conversions, which handle the
 //! rounding properly. Note that precision loss will still occur when rounding from a float to an
 //! int, although rounding lessens the problem.
@@ -55,34 +55,34 @@
 //!
 //! Winit will dispatch a [`ScaleFactorChanged`] event whenever a window's scale factor has changed.
 //! This can happen if the user drags their window from a standard-resolution monitor to a high-DPI
-//! monitor, or if the user changes their DPI settings. This gives you a chance to rescale your
-//! application's UI elements and adjust how the platform changes the window's size to reflect the new
-//! scale factor. If a window hasn't received a [`ScaleFactorChanged`] event,  then its scale factor
+//! monitor or if the user changes their DPI settings. This allows you to rescale your application's
+//! UI elements and adjust how the platform changes the window's size to reflect the new scale
+//! factor. If a window hasn't received a [`ScaleFactorChanged`] event, its scale factor
 //! can be found by calling [`window.scale_factor()`].
 //!
 //! ## How is the scale factor calculated?
 //!
-//! Scale factor is calculated differently on different platforms:
+//! The scale factor is calculated differently on different platforms:
 //!
 //! - **Windows:** On Windows 8 and 10, per-monitor scaling is readily configured by users from the
 //!   display settings. While users are free to select any option they want, they're only given a
-//!   selection of "nice" scale factors, i.e. 1.0, 1.25, 1.5... on Windows 7, the scale factor is
+//!   selection of "nice" scale factors, i.e. 1.0, 1.25, 1.5... on Windows 7. The scale factor is
 //!   global and changing it requires logging out. See [this article][windows_1] for technical
 //!   details.
-//! - **macOS:** Recent versions of macOS allow the user to change the scaling factor for certain
-//!   displays. When this is available, the user may pick a per-monitor scaling factor from a set
-//!   of pre-defined settings. All "retina displays" have a scaling factor above 1.0 by default but
-//!   the specific value varies across devices.
+//! - **macOS:** Recent macOS versions allow the user to change the scaling factor for specific
+//!   displays. When available, the user may pick a per-monitor scaling factor from a set of
+//!   pre-defined settings. All "retina displays" have a scaling factor above 1.0 by default,
+//!   but the specific value varies across devices.
 //! - **X11:** Many man-hours have been spent trying to figure out how to handle DPI in X11. Winit
 //!   currently uses a three-pronged approach:
-//!   + Use the value in the `WINIT_X11_SCALE_FACTOR` environment variable, if present.
+//!   + Use the value in the `WINIT_X11_SCALE_FACTOR` environment variable if present.
 //!   + If not present, use the value set in `Xft.dpi` in Xresources.
 //!   + Otherwise, calculate the scale factor based on the millimeter monitor dimensions provided by XRandR.
 //!
 //!   If `WINIT_X11_SCALE_FACTOR` is set to `randr`, it'll ignore the `Xft.dpi` field and use the
 //!   XRandR scaling method. Generally speaking, you should try to configure the standard system
 //!   variables to do what you want before resorting to `WINIT_X11_SCALE_FACTOR`.
-//! - **Wayland:** Scale factor is suggested by the compositor for each window individually. The
+//! - **Wayland:** The scale factor is suggested by the compositor for each window individually. The
 //!   monitor scale factor may differ from the window scale factor.
 //! - **iOS:** Scale factors are set by Apple to the value that best suits the device, and range
 //!   from `1.0` to `3.0`. See [this article][apple_1] and [this article][apple_2] for more

src/lib.rs

@@ -10,12 +10,12 @@
 //! let event_loop = EventLoop::new().unwrap();
 //! ```
 //!
-//! Once this is done there are two ways to create a [`Window`]:
+//! Once this is done, there are two ways to create a [`Window`]:
 //!
 //!  - Calling [`Window::new(&event_loop)`][window_new].
 //!  - Calling [`let builder = WindowBuilder::new()`][window_builder_new] then [`builder.build(&event_loop)`][window_builder_build].
 //!
-//! The first method is the simplest, and will give you default values for everything. The second
+//! The first method is the simplest and will give you default values for everything. The second
 //! method allows you to customize the way your [`Window`] will look and behave by modifying the
 //! fields of the [`WindowBuilder`] object before you create the [`Window`].
 //!
@@ -56,7 +56,7 @@
     doc = "`EventLoopExtPumpEvents::pump_events()`"
 )]
 //! [^1]. See that method's documentation for more reasons about why
-//! it's discouraged, beyond compatibility reasons.
+//! it's discouraged beyond compatibility reasons.
 //!
 //!
 //! ```no_run
@@ -92,9 +92,9 @@
 //!
 //!             // Queue a RedrawRequested event.
 //!             //
-//!             // You only need to call this if you've determined that you need to redraw, in
+//!             // You only need to call this if you've determined that you need to redraw in
 //!             // applications which do not always need to. Applications that redraw continuously
-//!             // can just render here instead.
+//!             // can render here instead.
 //!             window.request_redraw();
 //!         },
 //!         Event::WindowEvent {
@@ -118,7 +118,7 @@
 //!
 //! # Drawing on the window
 //!
-//! Winit doesn't directly provide any methods for drawing on a [`Window`]. However it allows you to
+//! Winit doesn't directly provide any methods for drawing on a [`Window`]. However, it allows you to
 //! retrieve the raw handle of the window and display (see the [`platform`] module and/or the
 //! [`raw_window_handle`] and [`raw_display_handle`] methods), which in turn allows
 //! you to create an OpenGL/Vulkan/DirectX/Metal/etc. context that can be used to render graphics.
@@ -183,13 +183,13 @@ pub mod window;
 pub mod platform;
 
 /// Wrapper for objects which winit will access on the main thread so they are effectively `Send`
-/// and `Sync`, since they always excute on a single thread.
+/// and `Sync`, since they always execute on a single thread.
 ///
 /// # Safety
 ///
-/// Winit can run only one event loop at the time and the event loop itself is tied to some thread.
-/// The objects could be send across the threads, but once passed to winit, they execute on the
-/// mean thread if the platform demands it. Thus marking such objects as `Send + Sync` is safe.
+/// Winit can run only one event loop at a time, and the event loop itself is tied to some thread.
+/// The objects could be sent across the threads, but once passed to winit, they execute on the
+/// main thread if the platform demands it. Thus, marking such objects as `Send + Sync` is safe.
 #[doc(hidden)]
 #[derive(Clone, Debug)]
 pub(crate) struct SendSyncWrapper<T>(pub(crate) T);