RFR: 8227425: Add support for e-paper displays on i.MX6 devices

Thu Dec 5 12:06:18 UTC 2019

On Thu, 5 Dec 2019 12:06:18 GMT, John Neffenger <github.com+1413266+jgneff at openjdk.org> wrote:

> This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* repository. Some of the changes were made to support the new device models, while others are minor changes to the existing support in JavaFX 13.
> 
> The following changes were made to support the new device models.
> 
> * Work around problems on the Kobo Glo HD Model N437.
> 
>     Ignore the error ENOTTY (25), "Inappropriate ioctl for device," when setting the waveform modes. The IOCTL call is ignored by the driver on the Kobo Glo HD where the error occurs, anyway.
> 
>     Use the visible y-resolution (`yres`), not the virtual y-resolution (`yres_virtual`), when calculating the capacity of the off-screen byte buffer and the length of the frame buffer mapping. The virtual y-resolution reported by the frame buffer device driver can be an incorrect value.
> 
> * Work around problems on the Kobo Clara HD Model N249.
> 
>     The Kobo Clara HD requires the native screen width to be set to the visible x-resolution (`xres`), instead than the normal virtual x-resolution (`xres_virtual`), when using an unrotated and uninverted 8-bit grayscale frame buffer. The work-around is provided through a new Boolean system property called *monocle.epd.fixWidthY8UR*.
> 
> The following changes were made to the existing code that supports e-paper displays in JavaFX 13.
> 
> * Use the correct constant for the number of bytes per pixel.
> 
>     Use the number of bytes per pixel (`Integer.BYTES`), not the number of bits per pixel (`Integer.SIZE`), when calculating the capacity of the 32-bit off-screen byte buffer.
> 
> * Do not round the luma value to the nearest integer.
> 
>     Use the value of luma rounded toward zero automatically by Java when converting a `float` to an `int` instead of rounding to the nearest integer. The additional rounding operation can decrease performance anywhere from zero to 10 percent and doesn't seem worth it for a display with just 16 levels of gray.
> 
> * Change camel case of system property *y8inverted*.
> 
>     Change the camel case of the system property *monocle.epd.y8inverted* to the form *monocle.epd.Y8Inverted* so that it is consistent with the other system properties containing Y1, Y4, and Y8 in their names.
> 
> * Improve error handling when mapping the frame buffer.
> 
>     Log the mapping and unmapping of the frame buffer. Log any errors that occur on either of the system calls. Handle a `null` return value from `EPDFrameBuffer.getMappedBuffer`.
> 
> * Replace non-ASCII characters with their ASCII equivalent.
> 
>     Replace non-ASCII characters in comments and log messages as follows:
> 
>     * "×" with "x" for display resolution and color depth,
>     * "×" with "*" for multiplication,
>     * "→" with "to" for transition, and
>     * "°C" with "degrees Celsius" for temperature.
> 
> * Add descriptions to Monocle EPD system properties.
> 
>     Add Javadoc comments to each constant that defines a Monocle EPD system property.
> 
> * Rename `IntStructure.getInteger` to `IntStructure.get`.
> 
>     Rename the methods `getInteger` and `setInteger` in `IntStructure` to avoid confusion with the Java method `Integer.getInteger`, which gets the integer value of a system property.
> 
> Below are some of the more interesting test results.
> 
> * The Kobo Glo HD and Kobo Clara HD implement a true GC4 waveform mode that displays only pixels with the four gray values `0x00`, `0x55`, `0xAA`, and `0xFF`. On the older Kobo Touch models, the GC4 waveform mode is the same as GC16.
> 
> * When the *forceMonochrome* update flag is enabled, the Kobo Clara HD uses a zero-percent threshold that displays black for pixels with the value `0x00` and white for all other values. The other models use a 50-percent threshold that displays black for values `0x7F` or less and white for values `0x80` or greater.
> 
> * The OpenJDK 11 package in Ubuntu 18.04 LTS runs twice as fast as the AdoptOpenJDK build of OpenJDK 13 for some of the tests. The speed difference is greatest for the tests that require pixel conversion into an 8-bit or 16-bit frame buffer. I plan to investigate the cause of the performance difference.
> 
> * In general, the faster processor and memory bus of the newer models does not fully compensate for the threefold increase in the number of pixels in their displays. The table below shows the animation speed of each model in milliseconds per frame and frames per second.
> 
>     | Product Name  | Speed (ms) | Rate (fps) |
>     | ------------- |:----------:|:----------:|
>     | Kobo Touch B  | 125        | 8.0        |
>     | Kobo Touch C  | 130        | 7.7        |
>     | Kobo Glo HD   | 140        | 7.1        |
>     | Kobo Clara HD | 145        | 6.9        |
> 
> ----------------
> 
> Commits:
>  - aa335246: 8227425: Add support for e-paper displays on i.MX6 devices
> 
> Changes: https://git.openjdk.java.net/jfx/pull/60/files
>  Webrev: https://webrevs.openjdk.java.net/jfx/60/webrev.00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8227425
>   Stats: 238 lines in 7 files changed: 193 ins; 2 del; 43 mod
>   Patch: https://git.openjdk.java.net/jfx/pull/60.diff
>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/60/head:pull/60

/signed

PR: https://git.openjdk.java.net/jfx/pull/60