On Thu, 5 Dec 2019 12:06:18 GMT, John Neffenger <github.com+1413266+jgn...@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
