Re: Question/discussion about JDK-8129582

[Itai]

Hello,

In hopes of getting this bug fixed, I have made changes to
`PangoGlyphLayout` so that is only allocates the FT2 FontMap once, and uses
a `PlatformImpl.FinishListener` to unref it when the JavaFX platform exits.
Attached is the modified version of the file.
In my personal tests, depending on hardware used, there is a speedup of
between x2 and x10 in layout times, and scrolling large Lists/Tables feels
as snappy with CTL languages as with any other language.
For anyone wanting to test it, remember this bug only affects Linux, and
only CTL languages (such as Arabic, Farsi, Hebrew and Hindi).

Regards,
Itai.

On Sun, Jan 8, 2017 at 11:39 PM, Itai <itai...@gmail.com> wrote:

> I think I have found two problems. The first, and probably most critical
> one, is that a new PangoFontMap is created for every call of
> PangoGlyphLayout#layout. It is not entirely clear from the Pango
> documentation what the lifetime or intended usage of a PangoFontMap is, but
> I have found this comment in [1]:
>
> "But note that a PangoFontMap is a big expensive object. So, you
> *really* want to be using only one for your entire program.
> Frequently calling pango_ft2_font_map_new() is going kill
> the performance of your application."
>
> This seems to imply PangoFontMap is intended as a global (per display?)
> font cache. Indeed, creating only one PangoFontMap seems to improve
> performance drastically, although I'm not sure what is the best way to
> handle this object (i.e. when and how it should be re-used and freed), as
> it should probably (?) be held for the entire lifetime of the JavaFX
> application.
>
> The second problem is probably less significant, but could still
> theoretically hurt performance - it has to do with the usage of
> g_list_nth_data, which as per [2] has O(N) complexity, and is called once
> per item in the list, which yields O(N^2) complexity. Replacing it with
> linked-list traversal with g_list_next should reduce this back to O(N).
>
> I hope this information is clear enough. As I said I lack the overall
> understanding of the JavaFX platform to know where and how to manage a
> global object, such as PangoFontMap should apparently be, so I refrain from
> posting any patch that I know would be wrong.
>
> Regards,
> Itai.
>
> [1]: https://mail.gnome.org/archives/gtk-list/2005-April/msg00105.html
> [2]: https://developer.gnome.org/programming-guidelines/
> stable/glist.html.en
>
> On Sun, Jan 8, 2017 at 8:08 PM, Itai <itai...@gmail.com> wrote:
>
>> Thank you for the link, it's an interesting read indeed!
>>
>> I wasn't really skipping layout, just using the much simpler layout used
>> by Latin scripts, but you are correct that this will break for anything
>> more complex - this has nothing to do with BiDi though, more to do with
>> complex layout elements (like diacritic or cantillation marks for Hebrew,
>> or general Arabic/Farsi text).
>> Indeed, this can't be a general solution, but I guess I was driven by
>> frustration.
>>
>> I have tried some more configurations though, and found that on Windows
>> the loss of performance is much less noticeable, which seems to mean that
>> the problem is either:
>> 1. Pango is inherently slow / inherently slow when laying out BiDi text.
>> 2. JavaFX uses Pango in a sub-optimal / redundant way.
>> 3. The JNI / native calls to Pango are done in a sub-optimal way.
>>
>> Option 1 can be easily debunked, as general Gnome/GTK applications run as
>> smoothly with BiDi text as with Latin / LTR text.
>> For options 2 and 3 I guess some more digging into the code must be done.
>> My understanding is that JNI calls are not likely to incur performance loss
>> to such a degree, unless very large amounts of memory are copied back and
>> forth between Java and native code, so I'll start by reading into the Pango
>> documentation and understanding the logic of PangoGlyphLayout.
>>
>> If you have any input on this or believe my assumptions or conclusions
>> are wrong I'd be glad to hear. I realize you are all busy with the upcoming
>> 9 release, so I'll try to get as detailed a result as I can.
>>
>> Regards,
>> Itai.
>>
>> On Wed, Jan 4, 2017 at 8:44 PM, Phil Race <philip.r...@oracle.com> wrote:
>>
>>> You can't skip layout just because it is bidi ..
>>> where here you are apparently implicitly meaning Hebrew.
>>> This might be apparently working but may not always work even
>>> for Hebrew and will be a disaster for Arabic.
>>>
>>> Here is a web page which talks about OTL (OpenType Layout) for Hebrew :
>>> https://www.microsoft.com/typography/OpenTypeDev/hebrew/i

Re: System font fails to load on Windows 7 - possible causes/fixes?

[Itai]

Removing the font "Segoe UI Semilight" indeed solves the problem, although
there are still messages saying it failed to load "Segoe UI Regular".
However, this time the fallback is listed as Tahoma.

I have tested this on a system on which I am certain no custom fonts were
installed.
This font may have been pushed into Windows 7 in some Windows Update:
https://support.microsoft.com/en-ie/help/3102429/update-that-supports-azerbaijani-manat-and-georgian-lari-currency-symb

Or perhaps it got in the system via Office:
https://support.microsoft.com/en-my/help/2800393/fonts-that-are-installed-with-microsoft-office-2013-products


So I am not convinced it would be incompatible with Windows 7 - that would
be very strange, considering also only JavaFX seems to suffer from it.
Could it be that the error message simply means it had determined it needs
to use a fallback for displaying Hebrew glyphs? That may explain why the
error is still displayed after removing Segoe UI Semilight (this time only
for Segoe UI Regular). If the fallback mechanism only considers one step of
fallback then Segoe UI -> Segoe UI Semilight would fail, but removing
Semilight would make the fallback chain Segoe UI -> Tahoma, which would
work?
Unfortunately I cannot test this by removing "Segoe UI Regular" as it is a
"protected system font", and so Windows won't allow me to delete it.




On Tue, Nov 28, 2017 at 5:35 PM, Itai <itai...@gmail.com> wrote:

> As far as I know this is a default Windows 7 installation, but it is
> entirely possible a font was added at some point. I don't know where it was
> sourced if that is the case.
>
> I will try removing this font to see if it makes a difference, but note
> that Prism also seems to be failing to load "Segoe UI Regular", which as I
> understand is meant to be the normal "Segoe UI" font?
>
> The only font this program loads by name is FontAwesome, which is embedded
> in the JAR. There is no reference to either Segoe UI or Segoe UI Semilight
> in the code, so if it tries to load them I'm assuming it is from the
> Windows fonts directory.
>
> On Tue, Nov 28, 2017 at 1:51 AM, Phil Race <philip.r...@oracle.com> wrote:
>
>> It seems to be mostly about this font  that is NOT your system font ..
>> but one
>> you are loading from somewhere.
>> Temp file created: C:\Users\user\AppData\Local\Te
>> mp\+JXF7252213042545373012.tmp^M
>> Mapping IDWriteFont="Segoe UI Semilight" Postscript
>> name="SegoeUI-Semilight" Win32 name="Segoe UI Semilight Regular"
>>
>> The repeated error is for that one font
>> Mapping IDWriteFont="Segoe UI Semilight" Postscript
>> name="SegoeUI-Semilight" Win32 name="Segoe UI Semilight Regular"^M
>>  Failed to map IDWriteFont to Prism 
>>
>> So it looks as if DirectWrite does not like that font.
>> Where did you get it ?
>>
>> according to Microsoft it is only available as part of Windows 8
>> https://www.microsoft.com/typography/fonts/font.aspx?FMID=1945
>>
>> So perhaps it isn't compatible with DW on Windows 7.
>>
>> -phil
>>
>>
>> On 11/26/2017 12:16 AM, Itai wrote:
>>
>>> I have recently come across a problem where some systems don't show
>>> Hebrew
>>> glyphs using JavaFX, where all other programs run perfectly fine.
>>>
>>> Changing the system font seems to be a workaround, but this is
>>> undesirable
>>> from the user's standpoint.
>>> At first I thought it was some issue with font substitution, so I ran the
>>> program with the option `-Dprism.debugfonts=true`, and apparently JavaFX
>>> completely fails to load the defined system fonts (which are the Windows
>>> 7
>>> standard, Segoe UI).
>>> I'm getting a lot of :
>>>
>>>    Failed to map IDWriteFont to Prism 
>>>
>>> What can be the cause for this, and how do I go about further diagnosing
>>> the issue? I suppose this is some bug, but I'm not sure where or what
>>> exactly it is, so I don't know what details to give in a bug report.
>>>
>>> Attached is the full log of running with `-Dprism.debugfonts=true`.
>>>
>>> Thanks,
>>> Itai.
>>>
>>
>>
>

Re: System font fails to load on Windows 7 - possible causes/fixes?

[Itai]

As far as I know this is a default Windows 7 installation, but it is
entirely possible a font was added at some point. I don't know where it was
sourced if that is the case.

I will try removing this font to see if it makes a difference, but note
that Prism also seems to be failing to load "Segoe UI Regular", which as I
understand is meant to be the normal "Segoe UI" font?

The only font this program loads by name is FontAwesome, which is embedded
in the JAR. There is no reference to either Segoe UI or Segoe UI Semilight
in the code, so if it tries to load them I'm assuming it is from the
Windows fonts directory.

On Tue, Nov 28, 2017 at 1:51 AM, Phil Race <philip.r...@oracle.com> wrote:

> It seems to be mostly about this font  that is NOT your system font .. but
> one
> you are loading from somewhere.
> Temp file created: C:\Users\user\AppData\Local\Te
> mp\+JXF7252213042545373012.tmp^M
> Mapping IDWriteFont="Segoe UI Semilight" Postscript
> name="SegoeUI-Semilight" Win32 name="Segoe UI Semilight Regular"
>
> The repeated error is for that one font
> Mapping IDWriteFont="Segoe UI Semilight" Postscript
> name="SegoeUI-Semilight" Win32 name="Segoe UI Semilight Regular"^M
>  Failed to map IDWriteFont to Prism 
>
> So it looks as if DirectWrite does not like that font.
> Where did you get it ?
>
> according to Microsoft it is only available as part of Windows 8
> https://www.microsoft.com/typography/fonts/font.aspx?FMID=1945
>
> So perhaps it isn't compatible with DW on Windows 7.
>
> -phil
>
>
> On 11/26/2017 12:16 AM, Itai wrote:
>
>> I have recently come across a problem where some systems don't show Hebrew
>> glyphs using JavaFX, where all other programs run perfectly fine.
>>
>> Changing the system font seems to be a workaround, but this is undesirable
>> from the user's standpoint.
>> At first I thought it was some issue with font substitution, so I ran the
>> program with the option `-Dprism.debugfonts=true`, and apparently JavaFX
>> completely fails to load the defined system fonts (which are the Windows 7
>> standard, Segoe UI).
>> I'm getting a lot of :
>>
>>    Failed to map IDWriteFont to Prism 
>>
>> What can be the cause for this, and how do I go about further diagnosing
>> the issue? I suppose this is some bug, but I'm not sure where or what
>> exactly it is, so I don't know what details to give in a bug report.
>>
>> Attached is the full log of running with `-Dprism.debugfonts=true`.
>>
>> Thanks,
>> Itai.
>>
>
>

Re: PathTransition jitter

[Itai]

Hermann - I believe this bug is due to a combination of Mesa and X.org - it
seems to be resolved by using Mesa>=13.0 *and* X.org>=1.18.4 . Since this
is a Linux-only bug, I don't think it's the same as the TransitionPath
jitter, as it reportedly happens on Windows as well.

On Sun, May 7, 2017 at 12:57 PM, Hermann Maier  wrote:

> I can reproduce the problem as well on my system with (X)Ubuntu 16.04
> 64-Bit and Mesa 12.0.6, with JDK 8u131.
> Also, the CPU usage of the Java process and the Xorg process is increasing
> constantly until the application gets completely laggy and unusable (like
> every application that is using some JavaFX animation under Linux with the
> hardware renderer). This bug is already known [1], the resource leak is
> happening on my system too and it's very annoying (e.g. I made a game with
> JavaFX and realized this too late…). Thus I would suggest that raising the
> priority of that bug would be appropriate?
> However, when I use the Software Renderer there's nothing like described
> above, so it's really likely related to Mesa/Xorg.
>
>
> Cheers
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8161914
>
> Am 07.05.2017 um 06:03 schrieb Jose Martinez:
> > Looks like I am unable to update the Jira ticket so I guess I'll update
> the bug in here.
> > Kevin mentioned that there is some relief if
> "-Djavafx.animation.fullspeed=true" VM option is used.  I notice that it
> does improve but not remove the problem.  Also, the jitter is not limited
> to PathTransition.  In the example below the problem is reproduced by using
> Timeline and no PathTransition.
> > Since like this is not just an issue with PathTransition, would it be
> possible to bump up the priority on this?  The Jira mentions the fix is
> scheduled for Java 10.  Does this affect all animation in JavaFX?  Is there
> anyway to move objects on the screen without jitter?
> >
> > private void pathJitterBug(Stage primaryStage) {
> > //Circle circle = new Circle(30, Color.RED);
> > //Path path = new Path();
> > //path.getElements().add(new MoveTo(100, 100));
> > //path.getElements().add(new LineTo(500, 100));
> > //path.getElements().add(new LineTo(500, 500));
> > //path.getElements().add(new LineTo(100, 500));
> > //path.getElements().add(new LineTo(100, 100));
> > //
> > //PathTransition pathTransition = new
> PathTransition(Duration.seconds(10), path, circle);
> > //pathTransition.setCycleCount(Animation.INDEFINITE);
> > // pathTransition.setOrientation(PathTransition.OrientationType
> .ORTHOGONAL_TO_TANGENT);
> > //pathTransition.playFromStart();
> > //
> > Circle circle2 = new Circle(20, Color.BLUE);
> > Timeline tl = new Timeline(
> > new KeyFrame(Duration.ZERO, new
> KeyValue(circle2.centerXProperty(), 125), new
> KeyValue(circle2.centerYProperty(), 125)),
> > new KeyFrame(Duration.seconds(5), new
> KeyValue(circle2.centerXProperty(), 425), new
> KeyValue(circle2.centerYProperty(), 425))
> > );
> > tl.setCycleCount(Timeline.INDEFINITE);
> > tl.setAutoReverse(true);
> > tl.playFromStart();
> > //
> > Circle circle3 = new Circle(20, Color.GREEN);
> > Timeline tl2 = new Timeline(
> > new KeyFrame(Duration.ZERO, new
> KeyValue(circle3.centerXProperty(), 425), new
> KeyValue(circle3.centerYProperty(), 125)),
> > new KeyFrame(Duration.seconds(5), new
> KeyValue(circle3.centerXProperty(), 125), new
> KeyValue(circle3.centerYProperty(), 425))
> > );
> > tl2.setCycleCount(Timeline.INDEFINITE);
> > tl2.setAutoReverse(true);
> > tl2.playFromStart();
> > //
> > Group root = new Group();
> > //root.getChildren().addAll(circle, circle2, circle3);
> > root.getChildren().addAll(circle2, circle3);
> > Scene scene = new Scene(root, 600, 600);
> > primaryStage.setTitle("Hello World!");
> > primaryStage.setScene(scene);
> > primaryStage.show();
> > }
> >
> >
> >   From: Kevin Rushforth 
> >  To: Jose Martinez 
> > Cc: "openjfx-dev@openjdk.java.net" ; Lord
> Chaos 
> >  Sent: Friday, April 14, 2017 9:29 AM
>
> >  Subject: Re: PathTransition jitter
> >
> > And here is the direct link in JBS:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8178805
> >
> > -- Kevin
> >
> >
> > Jose Martinez wrote:
> >> Thank you Kevin.
> >> For those interested here is the bug report:
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805
> >>
> >>
> >>
> >>
> >>   From: Kevin Rushforth 
> >>   To: Jose Martinez 
> >> Cc: "openjfx-dev@openjdk.java.net" 
> >>   Sent: Thursday, April 13, 2017 7:49 AM
> >>   Subject: 

Will JDK-8150946 be backported to 8?

[Itai]

Looking at https://bugs.openjdk.java.net/browse/JDK-8150946 , it seems to
be fixed in 9 but not in 8. The similar JDK-8136838 (
https://bugs.openjdk.java.net/browse/JDK-8136838) was backported to 8 , but
it seems the spinner behavior of not saving values on focus lost still
exists in 8.

Is this likely to be backported? If not the whole focus-loss semantics,
maybe just making Spinners and ComboBoxes have consistent behavior?

Regards,
Itai.

Re: Question/discussion about JDK-8129582

[Itai]

I think I have found two problems. The first, and probably most critical
one, is that a new PangoFontMap is created for every call of
PangoGlyphLayout#layout. It is not entirely clear from the Pango
documentation what the lifetime or intended usage of a PangoFontMap is, but
I have found this comment in [1]:

"But note that a PangoFontMap is a big expensive object. So, you
*really* want to be using only one for your entire program.
Frequently calling pango_ft2_font_map_new() is going kill
the performance of your application."

This seems to imply PangoFontMap is intended as a global (per display?)
font cache. Indeed, creating only one PangoFontMap seems to improve
performance drastically, although I'm not sure what is the best way to
handle this object (i.e. when and how it should be re-used and freed), as
it should probably (?) be held for the entire lifetime of the JavaFX
application.

The second problem is probably less significant, but could still
theoretically hurt performance - it has to do with the usage of
g_list_nth_data, which as per [2] has O(N) complexity, and is called once
per item in the list, which yields O(N^2) complexity. Replacing it with
linked-list traversal with g_list_next should reduce this back to O(N).

I hope this information is clear enough. As I said I lack the overall
understanding of the JavaFX platform to know where and how to manage a
global object, such as PangoFontMap should apparently be, so I refrain from
posting any patch that I know would be wrong.

Regards,
Itai.

[1]: https://mail.gnome.org/archives/gtk-list/2005-April/msg00105.html
[2]: https://developer.gnome.org/programming-guidelines/stable/glist.html.en

On Sun, Jan 8, 2017 at 8:08 PM, Itai <itai...@gmail.com> wrote:

> Thank you for the link, it's an interesting read indeed!
>
> I wasn't really skipping layout, just using the much simpler layout used
> by Latin scripts, but you are correct that this will break for anything
> more complex - this has nothing to do with BiDi though, more to do with
> complex layout elements (like diacritic or cantillation marks for Hebrew,
> or general Arabic/Farsi text).
> Indeed, this can't be a general solution, but I guess I was driven by
> frustration.
>
> I have tried some more configurations though, and found that on Windows
> the loss of performance is much less noticeable, which seems to mean that
> the problem is either:
> 1. Pango is inherently slow / inherently slow when laying out BiDi text.
> 2. JavaFX uses Pango in a sub-optimal / redundant way.
> 3. The JNI / native calls to Pango are done in a sub-optimal way.
>
> Option 1 can be easily debunked, as general Gnome/GTK applications run as
> smoothly with BiDi text as with Latin / LTR text.
> For options 2 and 3 I guess some more digging into the code must be done.
> My understanding is that JNI calls are not likely to incur performance loss
> to such a degree, unless very large amounts of memory are copied back and
> forth between Java and native code, so I'll start by reading into the Pango
> documentation and understanding the logic of PangoGlyphLayout.
>
> If you have any input on this or believe my assumptions or conclusions are
> wrong I'd be glad to hear. I realize you are all busy with the upcoming 9
> release, so I'll try to get as detailed a result as I can.
>
> Regards,
> Itai.
>
> On Wed, Jan 4, 2017 at 8:44 PM, Phil Race <philip.r...@oracle.com> wrote:
>
>> You can't skip layout just because it is bidi ..
>> where here you are apparently implicitly meaning Hebrew.
>> This might be apparently working but may not always work even
>> for Hebrew and will be a disaster for Arabic.
>>
>> Here is a web page which talks about OTL (OpenType Layout) for Hebrew :
>> https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm
>> I can't say offhand why this might be exclusive to FX.
>> That test case would be handy.
>> So this needs more analysis even if you found a way to limit this to
>> specifically Latin+Hebrew.
>>
>> -phil.
>>
>>
>> On 01/04/2017 10:32 AM, Itai wrote:
>>
>> Some quick-and-dirty thing I hacked now and seems to improve the
>> performance drastically is something like:
>>
>> if (complex but not bidi) {
>>use GlyphLayout.
>> } else if (bidi) {
>>use java.text.Bidi.reorderVisually to get visual glyph order, then use
>> same implementation as non-bidi non-complex layout
>> } else {
>>...
>> }
>>
>> Very minimal tests show it working correctly, and performance is 8-10
>> times faster (on par with non-bidi text).
>> Do you think this solution makes sense? Can you see any obvious pitfalls?
>> If it seems OK I'll try some more tests and then work it into something
&g

Re: Question/discussion about JDK-8129582

[Itai]

Thank you for the link, it's an interesting read indeed!

I wasn't really skipping layout, just using the much simpler layout used by
Latin scripts, but you are correct that this will break for anything more
complex - this has nothing to do with BiDi though, more to do with complex
layout elements (like diacritic or cantillation marks for Hebrew, or
general Arabic/Farsi text).
Indeed, this can't be a general solution, but I guess I was driven by
frustration.

I have tried some more configurations though, and found that on Windows the
loss of performance is much less noticeable, which seems to mean that the
problem is either:
1. Pango is inherently slow / inherently slow when laying out BiDi text.
2. JavaFX uses Pango in a sub-optimal / redundant way.
3. The JNI / native calls to Pango are done in a sub-optimal way.

Option 1 can be easily debunked, as general Gnome/GTK applications run as
smoothly with BiDi text as with Latin / LTR text.
For options 2 and 3 I guess some more digging into the code must be done.
My understanding is that JNI calls are not likely to incur performance loss
to such a degree, unless very large amounts of memory are copied back and
forth between Java and native code, so I'll start by reading into the Pango
documentation and understanding the logic of PangoGlyphLayout.

If you have any input on this or believe my assumptions or conclusions are
wrong I'd be glad to hear. I realize you are all busy with the upcoming 9
release, so I'll try to get as detailed a result as I can.

Regards,
Itai.

On Wed, Jan 4, 2017 at 8:44 PM, Phil Race <philip.r...@oracle.com> wrote:

> You can't skip layout just because it is bidi ..
> where here you are apparently implicitly meaning Hebrew.
> This might be apparently working but may not always work even
> for Hebrew and will be a disaster for Arabic.
>
> Here is a web page which talks about OTL (OpenType Layout) for Hebrew :
> https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm
> I can't say offhand why this might be exclusive to FX.
> That test case would be handy.
> So this needs more analysis even if you found a way to limit this to
> specifically Latin+Hebrew.
>
> -phil.
>
>
> On 01/04/2017 10:32 AM, Itai wrote:
>
> Some quick-and-dirty thing I hacked now and seems to improve the
> performance drastically is something like:
>
> if (complex but not bidi) {
>use GlyphLayout.
> } else if (bidi) {
>use java.text.Bidi.reorderVisually to get visual glyph order, then use
> same implementation as non-bidi non-complex layout
> } else {
>...
> }
>
> Very minimal tests show it working correctly, and performance is 8-10
> times faster (on par with non-bidi text).
> Do you think this solution makes sense? Can you see any obvious pitfalls?
> If it seems OK I'll try some more tests and then work it into something
> clean enough to submit as a patch suggestion.
>
>
> On Wed, Jan 4, 2017 at 7:48 PM, Itai <itai...@gmail.com> wrote:
>
>> Thanks for replying.
>> I think I understand what you're saying about the cache. As for
>> complexity - I'm mostly working with text which is only in Hebrew, which
>> isn't complex as far as I understand the definition (no glyph "fusing" as
>> in Arabic or Farsi). I can work with minor performance drops, but when the
>> same window takes more than 10 times to show if it has Hebrew labels is a
>> lot more than minor - and this is exclusive to JavaFX, so it's not like
>> this problem is unsolvable.
>>
>> Perhaps the caching is indeed not the correct solution, but maybe there
>> can be a way to simplify the layout in non-complex BiDi cases? Or optimize
>> PangoGlyphLayout.layout?
>>
>> Thank you again for replying, I really hope this issue can see some
>> improvement.
>>
>> On Wed, Jan 4, 2017 at 7:26 PM, Philip Race < <philip.r...@oracle.com>
>> philip.r...@oracle.com> wrote:
>>
>>> The cache is a heuristic optimisation and whether it helps depends on
>>> how well that cache is used.
>>> It is a time-space trade-off and I'd expect it to show up as helping
>>> more in micro-benchmarks or
>>> text-intensive benchmarks which use the same text broken in the same way.
>>> Complex text layout is inherently slower and if you are doing a lot of
>>> it .. it will be slow .. and
>>> unless it is repeated a cache won't help.
>>> During start-up I'd *expect* that there isn't a lot of re-use going on.
>>>
>>> You would need to profile how often  the same text (and attributes) are
>>> passed through this code.
>>> If you could provide us a test case we could examine it too.
>>>
>>> If it were a real use case, then we'd mo

Re: Question/discussion about JDK-8129582

[Itai]

Some quick-and-dirty thing I hacked now and seems to improve the
performance drastically is something like:

if (complex but not bidi) {
   use GlyphLayout.
} else if (bidi) {
   use java.text.Bidi.reorderVisually to get visual glyph order, then use
same implementation as non-bidi non-complex layout
} else {
   ...
}

Very minimal tests show it working correctly, and performance is 8-10 times
faster (on par with non-bidi text).
Do you think this solution makes sense? Can you see any obvious pitfalls?
If it seems OK I'll try some more tests and then work it into something
clean enough to submit as a patch suggestion.


On Wed, Jan 4, 2017 at 7:48 PM, Itai <itai...@gmail.com> wrote:

> Thanks for replying.
> I think I understand what you're saying about the cache. As for complexity
> - I'm mostly working with text which is only in Hebrew, which isn't complex
> as far as I understand the definition (no glyph "fusing" as in Arabic or
> Farsi). I can work with minor performance drops, but when the same window
> takes more than 10 times to show if it has Hebrew labels is a lot more than
> minor - and this is exclusive to JavaFX, so it's not like this problem is
> unsolvable.
>
> Perhaps the caching is indeed not the correct solution, but maybe there
> can be a way to simplify the layout in non-complex BiDi cases? Or optimize
> PangoGlyphLayout.layout?
>
> Thank you again for replying, I really hope this issue can see some
> improvement.
>
> On Wed, Jan 4, 2017 at 7:26 PM, Philip Race <philip.r...@oracle.com>
> wrote:
>
>> The cache is a heuristic optimisation and whether it helps depends on how
>> well that cache is used.
>> It is a time-space trade-off and I'd expect it to show up as helping more
>> in micro-benchmarks or
>> text-intensive benchmarks which use the same text broken in the same way.
>> Complex text layout is inherently slower and if you are doing a lot of it
>> .. it will be slow .. and
>> unless it is repeated a cache won't help.
>> During start-up I'd *expect* that there isn't a lot of re-use going on.
>>
>> You would need to profile how often  the same text (and attributes) are
>> passed through this code.
>> If you could provide us a test case we could examine it too.
>>
>> If it were a real use case, then we'd move on to examine the feasibility
>> of caching ...
>>
>> -phil.
>>
>>
>>
>> On 1/4/17, 9:19 AM, Itai wrote:
>>
>>> Recently JDK-8129582 [1] started really affecting me, with startup speed
>>> and overall responsiveness becoming really bad.
>>>
>>> Digging into it, I have found most time is wasted in
>>> com.sun.javafx.text.GlyphLayout.layout (as represented by
>>> PangoGlyphLayout
>>> on my Linux machine), which in turn is called
>>> by com.sun.javafx.text.PrismTextLayout.shape, which has:
>>>
>>>  if (run.isComplex()) {
>>>  /* Use GlyphLayout to shape complex text */
>>>  layout.layout(run, font, strike, chars);
>>>  } else {
>>>  ...
>>>  if (layoutCache == null) {
>>>   ...
>>>   } else {
>>>...
>>>   }
>>>  }
>>>
>>> which to my very naive reading seems as if while non-complex (with all
>>> BiDi
>>> text considered complex) glyph runs are cached, complex runs are never
>>> cached, which forces re-calculation every time.
>>>
>>> I'm trying to read and understand this part better, but could it be
>>> possible that this is the issue? How feasible would it be to have a
>>> layout
>>> cache for complex runs, or at least non-complex BiDi runs?
>>>
>>> Thanks,
>>> Itai.
>>>
>>> [1]:  https://bugs.openjdk.java.net/browse/JDK-8129582
>>>
>>
>

Re: Question/discussion about JDK-8129582

[Itai]

Thanks for replying.
I think I understand what you're saying about the cache. As for complexity
- I'm mostly working with text which is only in Hebrew, which isn't complex
as far as I understand the definition (no glyph "fusing" as in Arabic or
Farsi). I can work with minor performance drops, but when the same window
takes more than 10 times to show if it has Hebrew labels is a lot more than
minor - and this is exclusive to JavaFX, so it's not like this problem is
unsolvable.

Perhaps the caching is indeed not the correct solution, but maybe there can
be a way to simplify the layout in non-complex BiDi cases? Or optimize
PangoGlyphLayout.layout?

Thank you again for replying, I really hope this issue can see some
improvement.

On Wed, Jan 4, 2017 at 7:26 PM, Philip Race <philip.r...@oracle.com> wrote:

> The cache is a heuristic optimisation and whether it helps depends on how
> well that cache is used.
> It is a time-space trade-off and I'd expect it to show up as helping more
> in micro-benchmarks or
> text-intensive benchmarks which use the same text broken in the same way.
> Complex text layout is inherently slower and if you are doing a lot of it
> .. it will be slow .. and
> unless it is repeated a cache won't help.
> During start-up I'd *expect* that there isn't a lot of re-use going on.
>
> You would need to profile how often  the same text (and attributes) are
> passed through this code.
> If you could provide us a test case we could examine it too.
>
> If it were a real use case, then we'd move on to examine the feasibility
> of caching ...
>
> -phil.
>
>
>
> On 1/4/17, 9:19 AM, Itai wrote:
>
>> Recently JDK-8129582 [1] started really affecting me, with startup speed
>> and overall responsiveness becoming really bad.
>>
>> Digging into it, I have found most time is wasted in
>> com.sun.javafx.text.GlyphLayout.layout (as represented by
>> PangoGlyphLayout
>> on my Linux machine), which in turn is called
>> by com.sun.javafx.text.PrismTextLayout.shape, which has:
>>
>>  if (run.isComplex()) {
>>  /* Use GlyphLayout to shape complex text */
>>  layout.layout(run, font, strike, chars);
>>  } else {
>>  ...
>>  if (layoutCache == null) {
>>   ...
>>   } else {
>>...
>>   }
>>  }
>>
>> which to my very naive reading seems as if while non-complex (with all
>> BiDi
>> text considered complex) glyph runs are cached, complex runs are never
>> cached, which forces re-calculation every time.
>>
>> I'm trying to read and understand this part better, but could it be
>> possible that this is the issue? How feasible would it be to have a layout
>> cache for complex runs, or at least non-complex BiDi runs?
>>
>> Thanks,
>> Itai.
>>
>> [1]:  https://bugs.openjdk.java.net/browse/JDK-8129582
>>
>

Question/discussion about JDK-8129582

[Itai]

Recently JDK-8129582 [1] started really affecting me, with startup speed
and overall responsiveness becoming really bad.

Digging into it, I have found most time is wasted in
com.sun.javafx.text.GlyphLayout.layout (as represented by PangoGlyphLayout
on my Linux machine), which in turn is called
by com.sun.javafx.text.PrismTextLayout.shape, which has:

if (run.isComplex()) {
/* Use GlyphLayout to shape complex text */
layout.layout(run, font, strike, chars);
} else {
...
if (layoutCache == null) {
 ...
 } else {
  ...
 }
}

which to my very naive reading seems as if while non-complex (with all BiDi
text considered complex) glyph runs are cached, complex runs are never
cached, which forces re-calculation every time.

I'm trying to read and understand this part better, but could it be
possible that this is the issue? How feasible would it be to have a layout
cache for complex runs, or at least non-complex BiDi runs?

Thanks,
Itai.

[1]:  https://bugs.openjdk.java.net/browse/JDK-8129582

Proposed fix for JDK-8170972

[Itai]

It seems to me the source of the problem is line 466 in
com.sun.javafx.util.Utils:

   //TODO - testing for an instance of Stage seems wrong but works
for menus
if (scene.getWindow() instanceof Stage) {
layoutX = layoutX + parentBounds.getWidth() - anchorWidth;
} else {
layoutX = layoutX - parentBounds.getWidth() - anchorWidth;
}

As Popup is a Window but not a Stage, the proposed fix is to simply change
the condition to:

if (scene.getWindow() instanceof Window)

Obviously tests need to be run to see this doesn't break anything else, but
I'm not sure how to do so. As I can't post this to the JDK bug tracking
system I'm sending this here, so I'll appreciate it is someone with access
can post it there.
If it does pass all tests, and considering it's a pretty simple change, I'd
greatly appreciate if it could find its way into the next 8 update, as it
is currently blocking a feature in a project I'm working on.

Note: I'm not sure if I have used the most up-to-date dev version for the
patch file. Also, the test itself may be redundant, as getWindow() should
always return Window, shouldn't it?

Regards,
Itai.
--- Utils.java	2016-12-09 16:10:01.660349512 +0200
+++ Utils-new.java	2016-12-09 15:47:52.157662974 +0200
@@ -466,7 +466,7 @@
 
 if (orientation == NodeOrientation.RIGHT_TO_LEFT && hpos == HPos.CENTER) {
 //TODO - testing for an instance of Stage seems wrong but works for menus
-if (scene.getWindow() instanceof Stage) {
+if (scene.getWindow() instanceof Window) {
 layoutX = layoutX + parentBounds.getWidth() - anchorWidth;
 } else {
 layoutX = layoutX - parentBounds.getWidth() - anchorWidth;

PopupWindow.AnchorLocation inconsistent with other location properties in RTL mode

[Itai]

It seems the meaning of AnchorLocation is opposite to all other
position/location parameters in JavaFX when using RTL orientation: in
javafx.geometry.Pos, javafx.geometry.HPos LEFT always means "start", so in
RTL orientation it aligns nodes to the right (i.e. start of read order).

In AnchorLocation however, LEFT and RIGHT have absolute meanings,
regardless of node orientation. The comment in [1] says this is how it
should work, but considering this is opposite to how other parts of JavaFX
operate and that in RTL orientation the default behavior should be
anchoring to the right, I think it may be a problem.

At the very least, perhaps clarify in the documentation of AnchorLocation
that its meaning differs from Pos etc.?

Thanks,
Itai.

[1]
https://bugs.openjdk.java.net/browse/JDK-8125934?focusedCommentId=13767580=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13767580

Re: Memory leaks on Linux with hardware renderer

[Itai]

I'm sorry to see the issue could still not be reproduced on any OpenJFX
team members.

Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had the same
issue:
https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/
.
However, they have managed to profile it (VisualVM has a bug making it
nearly impossible to CPU profile JavaFX programs), and found out a lot of
time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`.

Taking this lead, I have found this:
http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/

Sadly I don't know enough about OpenGL to understand most of it, but it
seems to me like it's the same issue, so possibly it's not a Java issue at
all. However, maybe it can be avoided? In this linked post it is mentioned
that the leak only happens when having two windows, but in JavaFX this
always happens, so maybe there is a redundant call to `makeCurrent`?

Hope this helps to find the source of the problem, and if it's indeed
outside of Java/JavaFX scope - report it to the relevant project.

On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> Thanks. I added this to the bug report for https://bugs.openjdk.java.net/
> browse/JDK-8161911
>
> -- Kevin
>
>
>
> Rahman USTA wrote:
>
> Hello Kevin;
>
> One of our user reported "Must be a memory leak somewhere" in AsciidocFX
> project. It seems a similar issue.
>
> You can see the issue here https://github.com/
> asciidocfx/AsciidocFX/issues/227
>
> Thanks.
>
> 2016-07-21 2:38 GMT+03:00 Kevin Rushforth <kevin.rushfo...@oracle.com>:
>
>> I'll add a comment to that effect (although our incident triage team is
>> good about spotting such duplicates).
>>
>> -- Kevin
>>
>>
>> Itai wrote:
>>
>>> Thank you. Having gotten no reply, and seeing the bug report was closed
>>> and with not means of commenting in the bug report system, I have since
>>> (about an hour ago) filed a more detailed report (JI-9042009). I believe
>>> they could be safely merged, but the second one does contain some more
>>> info.
>>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
>>>
>>> JI-9041860 has now been transferred to the JDK project as:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8161911
>>>
>>> Our support engineer was not able to reproduce the problem, so
>>> closed it as such. Based on the additional information you
>>> provided, I have reopened the bug and will ask someone on our team
>>> with a physical Linux setup to try to reproduce it.
>>>
>>> To answer your question, we are not aware of any such leaks.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Itai wrote:
>>>
>>> I'm experiencing multiple memory leaks with JavaFX on Linux,
>>> to the point
>>> where I'm not sure which bug to report, as it seems like a
>>> systematic
>>> issue.
>>>
>>> The memory leak seems to be completely absent when using the
>>> software
>>> renderer (-Dprism.order=sw), and does not seem to happen on
>>> Windows
>>> (presumably not on Mac either, although I have no Mac to test
>>> it).
>>>
>>> Test cases include:
>>>
>>> 1. Use ProgressIndicator with progress set to Indeterminate -
>>> with default
>>> (HW) renderer memory consumption quickly rises, climbing to
>>> 8GB and more if
>>> not killed. With software renderer memory usage is reasonable.
>>> 2. Using Scene Builder - after a few minutes with Scene
>>> Builder it quickly
>>> gobbles up all system memory - again, problem seems to go away
>>> if using
>>> software renderer. This test is less repeatable, as some
>>> actions seem more
>>> detrimental than others.
>>> 3. Using Transitions on nodes (See attached code "Demo.java".
>>> I have filed
>>> a bug report about this issue, JI-9041860). Running with
>>> default renderer
>>> the simple program reaches 3GB within 30 seconds, and memory
>>> continues to
>>> climb. On software renderer memory consumption remains <100MB
>>> for a minute
>&

Re: Memory leaks on Linux with hardware renderer

[Itai]

Thank you. Having gotten no reply, and seeing the bug report was closed and
with not means of commenting in the bug report system, I have since (about
an hour ago) filed a more detailed report (JI-9042009). I believe they
could be safely merged, but the second one does contain some more info.

On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> JI-9041860 has now been transferred to the JDK project as:
>
> https://bugs.openjdk.java.net/browse/JDK-8161911
>
> Our support engineer was not able to reproduce the problem, so closed it
> as such. Based on the additional information you provided, I have reopened
> the bug and will ask someone on our team with a physical Linux setup to try
> to reproduce it.
>
> To answer your question, we are not aware of any such leaks.
>
> -- Kevin
>
>
>
> Itai wrote:
>
>> I'm experiencing multiple memory leaks with JavaFX on Linux, to the point
>> where I'm not sure which bug to report, as it seems like a systematic
>> issue.
>>
>> The memory leak seems to be completely absent when using the software
>> renderer (-Dprism.order=sw), and does not seem to happen on Windows
>> (presumably not on Mac either, although I have no Mac to test it).
>>
>> Test cases include:
>>
>> 1. Use ProgressIndicator with progress set to Indeterminate - with default
>> (HW) renderer memory consumption quickly rises, climbing to 8GB and more
>> if
>> not killed. With software renderer memory usage is reasonable.
>> 2. Using Scene Builder - after a few minutes with Scene Builder it quickly
>> gobbles up all system memory - again, problem seems to go away if using
>> software renderer. This test is less repeatable, as some actions seem more
>> detrimental than others.
>> 3. Using Transitions on nodes (See attached code "Demo.java". I have filed
>> a bug report about this issue, JI-9041860). Running with default renderer
>> the simple program reaches 3GB within 30 seconds, and memory continues to
>> climb. On software renderer memory consumption remains <100MB for a minute
>> and more.
>>
>> As I said, I am no longer sure it is prudent to report specific bugs, as
>> this seems to be some low-level problem. I just want to know if this is a
>> known issue and if there is any way to get around it (besides using the
>> software pipe, which obviously has it's own disadvantages).
>>
>>
>> For reference, I'm using Debian (testing, updated today), kernel version
>> 4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms driver),
>> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical on Oracle
>> version).
>>
>> If there is any other information needed please let me know. If this is a
>> known issue I apologize, but I have tried searching and didn't find any
>> reports of such behavior.
>>
>> Thank you.
>>
>>
>

Memory leaks on Linux with hardware renderer

[Itai]

I'm experiencing multiple memory leaks with JavaFX on Linux, to the point
where I'm not sure which bug to report, as it seems like a systematic
issue.

The memory leak seems to be completely absent when using the software
renderer (-Dprism.order=sw), and does not seem to happen on Windows
(presumably not on Mac either, although I have no Mac to test it).

Test cases include:

1. Use ProgressIndicator with progress set to Indeterminate - with default
(HW) renderer memory consumption quickly rises, climbing to 8GB and more if
not killed. With software renderer memory usage is reasonable.
2. Using Scene Builder - after a few minutes with Scene Builder it quickly
gobbles up all system memory - again, problem seems to go away if using
software renderer. This test is less repeatable, as some actions seem more
detrimental than others.
3. Using Transitions on nodes (See attached code "Demo.java". I have filed
a bug report about this issue, JI-9041860). Running with default renderer
the simple program reaches 3GB within 30 seconds, and memory continues to
climb. On software renderer memory consumption remains <100MB for a minute
and more.

As I said, I am no longer sure it is prudent to report specific bugs, as
this seems to be some low-level problem. I just want to know if this is a
known issue and if there is any way to get around it (besides using the
software pipe, which obviously has it's own disadvantages).


For reference, I'm using Debian (testing, updated today), kernel version
4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms driver),
OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical on Oracle
version).

If there is any other information needed please let me know. If this is a
known issue I apologize, but I have tried searching and didn't find any
reports of such behavior.

Thank you.