[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices
From:       Kevin Rushforth <kcr () openjdk ! java ! net>
Date:       2020-04-28 23:35:44
Message-ID: coIm5qrZy3NNHlTcD3iAI_gmgZFs1fe_yignOzOqiJE=.2b73131f-359d-4640-80f8-8031175ea73a () github ! com
[Download RAW message or body]

On Fri, 17 Apr 2020 19:11:19 GMT, John Neffenger \
<github.com+1413266+jgneff@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


[prev in list] [next in list] [prev in thread] [next in thread]