Bitwise puzzle in com.sun.glass.ui.monocle.Framebuffer

[John Neffenger]

I am completely puzzled by the bitwise operations in the Framebuffer 
class (package com.sun.glass.ui.monocle). I'm overriding its methods to 
support a "Y8" 8-bit grayscale frame buffer, yet I have no idea why it's 
doing what it's doing. Can anyone shed light on its complexity?


The Framebuffer class converts a buffer with 32-bit pixels in ARGB32 
format into a buffer with 16-bit pixels in RGB565 format, as illustrated 
below for one pixel.


          
-->  rggg  gggb 

I would convert the pixels with a method like the following:

void copyNextPixel(IntBuffer source, ShortBuffer target) {
int pixel32 = source.get();
int r = (pixel32 >> 8) & 0xF800;
int g = (pixel32 >> 5) & 0x07E0;
int b = (pixel32 >> 3) & 0x001F;
int pixel16 = r | g | b;
target.put((short) pixel16);
}

The JavaFX Framebuffer class converts the pixels like this:

void copyNextPixelOriginal(IntBuffer source, ShortBuffer target) {
int pixel32 = source.get();
int r = pixel32 >> 19) & 31) * 539219) >> 8) & (31 << 11);
int g = pixel32 >> 10) & 63) * 265395) >> 13) & (63 << 5);
int b = (((pixel32 >> 3) & 31) * 539219) >> 19;
int pixel16 = r | g | b;
target.put((short) pixel16);
}

Both of these methods produce identical results when tested against all 
16,777,216 possible 24-bit RGB values. To understand what is happening, 
I show each step in the creation and positioning of the 5-bit red color 
value for both algorithms below (best viewed in a monospaced font).


My version
int r = (pixel32 >> 8) & 0xF800;

            pixel32 (x = red)
            >> 8
       x000     & 0xF800

JavaFX version
int r = pixel32 >> 19) & 31) * 539219) >> 8) & (31 << 11);

            pixel32 (x = red)
         ___x   >> 19
         000x   & 31 = 0x1F
    x___        * 539219 = 2^19 + 14931
       x___     >> 8
       x000     & (31 << 11) = 0xF800

Why all the back and forth? Why introduce varying bits to the right of 
the red color value (* 539219), only to clear those bits later? The last 
three steps could be replaced with a single logical shift left operation 
(<< 11).


The Framebuffer class was added to the repository on January 21, 2014, 
by Daniel Blaukopf.


Thank you,
John

Re: Support of SVG ImageLoader in JavaFX

[Tom Schindl]

You can use a custom URLStreamHandler not?

Tom

On 05.11.18 12:03, René Reiß wrote:
> Hi,
> 
> In Java 8 I used a SVGImageLoader to support SVGs in css-Files,
> something like
> -fx-background-image : url("/svg/minusicon.svg");
> 
> see also
> https://blog.codecentric.de/en/2015/03/adding-custom-image-renderer-javafx-8/
> 
> 
> In Java 11 I get an IllegalAccessError
> 
> java.lang.IllegalAccessError: superinterface check failed: class
> SvgImageLoaderFactory (in unnamed module @0x2a8d6c41) cannot access
> class com.sun.javafx.iio.ImageLoaderFactory (in module javafx.graphics)
> because module javafx.graphics does not export com.sun.javafx.iio to
> unnamed module @0x2a8d6c41
> 
> I know, the ImageLoaderFactory is not part of the official JavaFX public
> API. But, why not? Why it is no more possible to write an own
> ImageLoader? It is planned for the future?
> 
> Is there another possibility to support SVGs in JavaFX applications?
> Otherwise I have to convert all SVGs to png or jpegs, but this will be a
> step backwards for me.
> 
> Thanks,
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Support of SVG ImageLoader in JavaFX

[René Reiß]

Hi,

In Java 8 I used a SVGImageLoader to support SVGs in css-Files, 
something like

-fx-background-image : url("/svg/minusicon.svg");

see also 
https://blog.codecentric.de/en/2015/03/adding-custom-image-renderer-javafx-8/


In Java 11 I get an IllegalAccessError

java.lang.IllegalAccessError: superinterface check failed: class 
SvgImageLoaderFactory (in unnamed module @0x2a8d6c41) cannot access 
class com.sun.javafx.iio.ImageLoaderFactory (in module javafx.graphics) 
because module javafx.graphics does not export com.sun.javafx.iio to 
unnamed module @0x2a8d6c41


I know, the ImageLoaderFactory is not part of the official JavaFX public 
API. But, why not? Why it is no more possible to write an own 
ImageLoader? It is planned for the future?


Is there another possibility to support SVGs in JavaFX applications?
Otherwise I have to convert all SVGs to png or jpegs, but this will be a 
step backwards for me.


Thanks,

--

René Reiß

Re: JavaFX 11.0.1-ea+1 release

[Michael Paus]

Hi,
sorry fo the confusion. I thought I was using the 11.0.1 SDK on my Mac
but actually I wasn't. Eclipse again played a prank on me with the 
modulepath.


Am 04.11.18 um 20:26 schrieb Johan Vos:

It should.
I have the following:
javafx.version = 11.0.1-ea

Are you using an SDK or maven artifacts? For which platform?

- Johan

On Sun, Nov 4, 2018 at 4:07 PM Michael Paus > wrote:


My application is reporting the following values for the respective
properties:

java.runtime.version: 11.0.1+13
java.class.version: 55.0
java.version: 11.0.1
javafx.version: 11

Shouldn't "javafx.version" follow the same naming conventions as
used by
"java.version"?


Am 02.11.18 um 09:59 schrieb Johan Vos:
> Hi,
>
> We are about to release JavaFX 11.0.1, containing the fixes that
made it
> into the 11-dev repository.
> An early-access build for this is available as SDK/jmods at
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>


>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>
> The maven artifacts are available in the usual repositories,
with version
> tag being "11.0.1-ea+1" e.g.
>
> org.openjfx:javafx-base:11.0.1-ea+1 (see
>
http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>
> If we don't hear major issues with this ea, it should become the
11.0.1
> release.
>
> - Johan