Hi Phil,
> I proposed 2 small fixes for jdk12... still to be done, as better
> solutions are not yet ready and I am completely overbusy on testing Java
> Sorting algorithms.
>
> Maybe I will give up fixing the native renderer, for these reasons:
> - stdlib qsort implementation and performance
Hi,
On 11/22/18 12:40 AM, Laurent Bourgès wrote:
Hi sergey,
I proposed 2 small fixes for jdk12... still to be done, as better
solutions are not yet ready and I am completely overbusy on testing
Java Sorting algorithms.
Maybe I will give up fixing the native renderer, for these reasons:
-
Hi sergey,
I proposed 2 small fixes for jdk12... still to be done, as better solutions
are not yet ready and I am completely overbusy on testing Java Sorting
algorithms.
Maybe I will give up fixing the native renderer, for these reasons:
- stdlib qsort implementation and performance (bentley
Hi, Laurent.
I do not think that we should postpone it to the next version.
Just send the changes when they are ready, if the review fails
to take place at the right time, then the fix will be
moved to the jdk13.
On 20/11/2018 00:28, Laurent Bourgès wrote:
As OpenJDK12 RDP1 is coming soon, I
On Tue, Nov 20, 2018 at 8:28 AM Laurent Bourgès
wrote:
> Will you have time to review 2 small patchs on time ?
If it would help for me to have a look, I am happy to do so.
Pete
Hi,
As OpenJDK12 RDP1 is coming soon, I propose this plan:
- integrate this basic fix in ShapeSpanIterator.c code to use stdlib sort
(mergesort on linux)
- integrate a very simple patch in Marlin renderer to disable insertion
sort for large arrays: 0.5s to 0.25s, few LOC
- postpone my changes to
On 26/10/2018 00:41, Laurent Bourgès wrote:
I suppose a JEP or RFE is required, isnt it ?
It depends from the changes, but such contributions are welcome!
Cheers,
Laurent
On 23/10/2018 13:37, Laurent Bourgès wrote:
> Phil,
> I quickly modified the final update & sort loop
Sergey,
Le mer. 24 oct. 2018 à 23:50, Sergey Bylokhov
a écrit :
> I have no comments about the current proposal(results is good), but is
> that really necessary to have this implementation in native code?
>
1. I read the academic papers "Sort Race", 2016 and I will experiment their
best merge6
I have no comments about the current proposal(results is good), but is that
really necessary to have this implementation in native code?
On 23/10/2018 13:37, Laurent Bourgès wrote:
Phil,
I quickly modified the final update & sort loop to:
- move sort in another block
- use qsort() using a new
Phil,
I quickly modified the final update & sort loop to:
- move sort in another block
- use qsort() using a new comparator sortSegmentsByCurX
This improves performance in PolyLineTest by 3 times: ~1s vs 3.5s !
Apparently qsort() is not optimal (comparator can not be inlined by c) so
it may
Phil,
Yesterday I started hacking ShapeSpanIterator.c to add stats: the last
stage (sort by x0) is the bottleneck.
In this case every sort takes up to 15ms per pixel row !
I will see if I can adapt Marlin's MergeSort.java to C to have an efficient
sort in-place.
Do you know if libawt has already
This has been given a Java bug number now: JDK-8212124
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8212124
I have been following the discussion here and I have a couple of
workarounds to try, which is great.
But, is there any more information you need from me? I'm always happy to
If there are no comments in the source, then there is no documentation :-(
Reverse engineering/studying the code is what we'd have to do if that were
the approach to be taken here.
-phil.
On 10/12/18, 2:18 AM, Laurent Bourgès wrote:
Phil,
I looked at the hostpot in
Phil,
I looked at the hostpot in
src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c (75%
cpu time) and its sort algorithm looks like an insertion sort ...
If you could give me some explanations (or documentation), I could try
optimizing this method.
Do you know if it uses an
Phil,
It reminds me I have rewritten in Marlin renderer the crossing sort at
every scanline.
Pisces was using a trivial insertion sort but it became very slow when the
crossing count is large.
I adopted a special merge sort as crossings are mostly ordered: big win.
What sort algo is in action in
And something else to try .. which I haven't tried, since I now believe
the problem isn't the drawing performance of a wide line, is to see
what happens if you do go that path - ie try 3,000 individual drawline
calls.
It depends how much overhead matters whether it is better than (say)
breaking
In my previous email I was asking only about the "older" system,
precisely because as you confirm below, I wanted to know that
it was operating on an unscaled graphics.
It is being triggered by the scale. If you add :
graphics.scale(1.25, 1.25)
in your application and run on 8 you'll see the
Hi,
One last thing about Marlin renderer:
it is available since OpenJDK9 and you can tune its subpixels to let say
1x1 ie 1 pixel: -Dsun.java2d.renderer.subPixel_log2_X=0
-Dsun.java2d.renderer.subPixel_log2_Y=0
I ran again the 'slow' test on linux ~ 0.5s:
- 4x faster than Marlin AA defaults
-
Hi Laurent,
Thanks for the detailed explanation. I quickly checked on the older
Windows system and the Java 11 window was the same size as the Java 8
one, implying no scaling was going on (I guess just because it has a
lower resolution monitor) - so that confirms your hypothesis.
If I use
Hi Peter,
I confirm that HiDPI support is causing your problem.
On linux (xrender), I added -Dsun.java2d.uiScale=2.5 and the performance
becomes poor ~ 3.3s vs 0.03s !
java -Dsun.java2d.uiScale=2.5 -DuseAA=false -jar dist/PolylineTest.jar
Java: 11 11+28
oct. 11, 2018 1:02:00 PM
I can answer part of that, but I can't get access to the older system just now.
On Wed, Oct 10, 2018 at 4:41 PM Philip Race wrote:
> In other words does
>
> -Dsun.java2d.uiScale=1.0
>
> even change the physical size of the window on JDK 9/10/11 ?
>
Yes, because I can run the same jar under Java
On 10/10/18, 6:07 AM, Peter Hull wrote:
On Wed, Oct 10, 2018 at 1:21 PM Peter Hull wrote:
-Dsun.java2d.uiScale=1.0
And this does make it fast again for me (paint time< 0.1sec)!
Which would sound like drawing wide lines on the software pipeline is
slowing
it down which makes sense
On Wed, Oct 10, 2018 at 1:21 PM Peter Hull wrote:
> -Dsun.java2d.uiScale=1.0
> And this does make it fast again for me (paint time < 0.1sec)!
Also I tried on an older system with "Intel HD Graphics 4600" and it
did not have the slow down problem. So it seems to be quite specific
to my system.
On Wed, 10 Oct 2018 at 11:55 Laurent Bourgès wrote:
>
> Peter,
> What is the corresponding bug ?
>
I don't know; I filled in the details and it said they would let me
know the bug number if & when it was accepted.
>
>
> I think it is -Djava2d.ui.scale=1.0 AFAIR.
It's
-Dsun.java2d.uiScale=1.0
Peter,
What is the corresponding bug ?
> > Peter, what is your hardware & OS info ?
> It's an Intel core i7-8750H, 8GB RAM, intel UHD 630 graphics
> Windows 10 Pro 1803 build 17134.320
>
> Note that Java 8 is still 'fast' so there must be some difference
> between 8 & 11.
>
> I saw that on Java
On Tue, Oct 9, 2018 at 3:52 PM Laurent Bourgès
wrote:
> Peter, what is your hardware & OS info ?
It's an Intel core i7-8750H, 8GB RAM, intel UHD 630 graphics
Windows 10 Pro 1803 build 17134.320
Note that Java 8 is still 'fast' so there must be some difference
between 8 & 11.
I saw that on Java
Hi Peter,
I tried on my linux laptop (i7 + nvidia binary driver) and my results are
the same on OpenJDK 8 / 11:
*- Java: 1.8.0_181 25.181-b13oct. 09, 2018 4:29:31 PM polylinetest.Canvas
paintComponentINFOS: Paint Time: 0,078soct. 09, 2018 4:29:31 PM
polylinetest.Canvas paintComponentINFOS:
27 matches
Mail list logo
