[Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices
kcr at openjdk.java.net
Tue Apr 28 23:35:44 UTC 2020
On Fri, 17 Apr 2020 19:11:19 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 |
> 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).
More information about the openjfx-dev