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 (bentley qsort 93 or merge > sort on linux) is platform dependent, so it may take time to validate its > behaviour (small vs large arrays, not really random, closer to almost > sorted data) > > > I don't think we should use anyC++ stdlib:: code here if that is what you > mean. >
No I proposed to use stdlib (C) qsort(... cmp) as it is done in the same class to sort initially edges, i.e. see my previous diff => ~1s time. I prefer focusing on integrating Marlin nonAA (like jfx) to get rid of this native code, than fixing C code, except such simple change. > > Any small improvements we can make by having a better sort in our sources > would > be better. > If they aren't ready for 12, no problem. 13 is around the corner .. > Yes, I know, but if you have time, I can propose a very simple Marlin patch to improve a bit its sorting performance in such extreme case: ~0.5s to 0.22s ! > - AA rendering is now the common case where the Marlin renderer is active > & fast enough. > > Would you accept enabling antialiasing by default in jdk12 ? > Up to now, RenderingHint.ANTIALIASING_DEFAULT means ANTIALIASING_OFF. > > > That is a big change and I do not think we should do it. > Yes it is a one-liner but it can have large impacts, so I agree it should be discussed in CSR ... so maybe in 13 ? Cheers, Laurent Several users faced performance issues with the native renderer (hidpi, complex shapes, clipping dashed shapes) where the Marlin renderer performs far better. Finally I can now focus on a trivial Marlin patch to tune its sort algorithm selection... Cheers, Laurent Le jeu. 22 nov. 2018 à 00:04, Sergey Bylokhov <sergey.bylok...@oracle.com> a écrit : > 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 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 Marlin sort & Marlin nonAA renderer integration > in OpenJDK 13 > > > > Will you have time to review 2 small patchs on time ? > >