[OpenJDK 2D-Dev] Black screen on Raspberry Pi / Manjaro

2021-07-28 Thread Kustaa Nyholm
Hi,

I'm afraid this is the wrong mailing list or venue but have to start from 
somewhere.

I just tested my Swing app using OpenJDK 11.0.1 on Raspberry Pi 4 / Manjaro and 
it worked great.

I then enabled the OpenGL pipeline with

-Dsun.java2d.opengl=True

and console confirmed that the pipeline was enabled.

The rending now  fails as follows:

During the initial rendering of Swing components (it is a bit slow so I can see 
what happens)
a lot of extra black follows or preceeds rendering  of every Swing component. 
When the
rendering is complete the whole window goes black except a white border around 
an
OpenGL canvas component. 

As I move the cursor around the component under the cursor flashes correctly 
rendered but
remains black.

If I resize the window, the whole window flashes briefly (much much faster that 
what
normal rendering takes place) with the correct rendering but then goes black 
again.

I tried this with X11 and Wayland enabled KDE (if it makes a difference, 
perhaps Java2D
rendring is not affected by the Desktop rendering


Is this a driver issue?

If so where should I turn next to ask questions like what driver I'm using and 
whom 
to report the problem?


I'm rather new to Linux / Raspberry so the driver / open source bug reporting
is kind of unclear to me...

wbr Kusti



[OpenJDK 2D-Dev] [jdk17] Withdrawn: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

2021-07-28 Thread Alexey Ushakov
On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov  wrote:

> Implemented blit via compute kernel

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk17/pull/62


Re: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v5]

2021-07-28 Thread Alexey Ushakov
On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov  wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

Moving this request to jdk18

-

PR: https://git.openjdk.java.net/jdk17/pull/62


Re: [OpenJDK 2D-Dev] RFR: 8181571: printing to CUPS fails on mac sandbox app

2021-07-28 Thread NikolayTach
On Wed, 21 Jul 2021 15:45:55 GMT, Alexander Scherbatiy  
wrote:

> The issue is reproduced on macOS Big Sur 11.0.1 with jdk 16.0.1+9.
> 
> Create a native macOS app from the Hello.java file, sign and run it in 
> sandbox:
> 
> import javax.print.*;
> import javax.swing.*;
> 
> public class Hello {
> 
> public static void main(String[] args) throws Exception {
> SwingUtilities.invokeAndWait(() -> {
> boolean isSandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") 
> != null;
> PrintService defaultPrinter = 
> PrintServiceLookup.lookupDefaultPrintService();
> PrintService[] services = 
> PrintServiceLookup.lookupPrintServices(null, null);
> 
> StringBuilder builder = new StringBuilder();
> builder.append("is sandboxed: ").append(isSandboxed).append("\n");
> builder.append("default printer: 
> ").append(defaultPrinter).append("\n");
> int size = services.length;
> for (int i = 0; i < size; i++) {
> 
> builder.append("printer[").append(i).append("]=").append(services[i]).append("\n");
> }
> JOptionPane.showMessageDialog(null, builder.toString());
> });
> }
> }
> 
> The signed app in sandbox shows null default printer and 
> PrintServiceLookup.lookupPrintServices(null, null) returns "Unix Printer: lp".
> ![PrintSandboxedApp](https://bugs.openjdk.java.net/secure/attachment/95629/PrintSandboxedApp.png)
> 
> The problem has been discussed on  2d-dev mail list:
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-June/008375.html
>   https://mail.openjdk.java.net/pipermail/2d-dev/2017-July/008418.html
> 
> According to the discussion:
> 
>> I've submitted a DTS incident to Apple and a friend there has followed-up.
>> Their unofficial position is that java should be connecting to the cups 
>> interface returned
>> by the cupsServer() function and not changing the interface string to 
>> "localhost".
>> Security changes in 10.12.4 reject the TCP connection which they say confuses
>> network-client access with print access.  They don't seem interested in 
>> loosening that change.
> 
> 
> The proposed solution is to use the domain socket pathname in 
> httpConnect(...) cups function and cupsGetDests(...) to get list of printers 
> from cups  when the app is signed and is run in sandbox on MacOs.

[JDK-8247768 ](https://bugs.openjdk.java.net/browse/JDK-8247768)
Same here played 6 times yet moved, 8 issues missed.

-

PR: https://git.openjdk.java.net/jdk/pull/4861