On Fri, 17 Apr 2020 19:11:19 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 | > > John Neffenger has refreshed the contents of this pull request, and previous > commits have been removed. The incremental > views will show differences compared to the previous content of the PR. Looks good to me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/60
