Hi Sergey,
We started using XRSurfaceType (surface type from XRSurfaceData) after
integration of JDK-8204931 [1]. Before that fix getSurfaceType() was not
overridden in XRGraphicsConfig and surface type from
X11GraphicsConfig/X11SurfaceData, (i.e. X11SurfaceType) was used for
XRWindowSurfaceDa
I don't really understand why this only affects XVFB/X11VNC ?
The bug evaluation is vague in explaining the root cause.
What are they doing that is different ?
Is there an unexpected alpha channel ?
If so,
- are we then selecting a loop which is supplying a zero value alpha
channel instead of an o
This is a known problem of sorts. It is called the Raster Problem.
JDK 9 and later support windows hi-dpi mode so you now have a scaled JPanel.
Something like 1.33 scale, the exact value depending on your windows DPI
setting.
The lines are all drawn independently, and the "y" is mapped to the
Hi Phil,
Thank you for the very comprehensive answer.
I was suspecting this must be something with trying to fit into the device DPI
but the hint about -Dsun.java2d.uiScale=1 helps when you really want to hit the
pixel.
With your permission I’d like to share your answer on StackOverflow so othe
You can post a link to
https://mail.openjdk.java.net/pipermail/2d-dev/2019-January/009805.html
Just to be clear, using
-Dsun.java2d.uiScale=1
means that on hi-dpi devices such as a Surface Pro or many laptops
the JDK window will likely be too small to read the text .. which was
of course the mo
