Closed ghost closed 9 years ago
Thanks for reporting. I have occasionally observed similar defects at least since 0.4.x, so it is unlikely a regression introduced in 0.5. Also, it seems to me that the frequency of encountering this problem increased between JDK 8 and 8u20. It might be a bug in JavaFX's TextFlow itself, or in the way TextFlow
is used in RichTextFX. I haven't yet been able to identify the cause, but I will work on it.
I just started noticing this issue as well. Just update to 8u25. I'm seeing the artifacts show up when I select a region of text.
I know the JavaFX team has been working on text rendering (saw it talked about in a JavaOne 2013 talk on Parley's - 31 min in).
I think I can add some more detail to the bug. It's happening on text that is outside the viewport and is scrolled into view. It also occurs when I paste in new text into the area. This leads me to think that there is an issue with text pixels not being updated fast enough, or something like that.
@jrguenther I cannot confirm that this is fixed in Java 8 Update 25. Text rendering issues still appear on my machine (Windows 7 x64).
@jntrb I think Jeff meant that he started noticing the issue after he updated to 8u25. It is certainly no resolved. I think there is a bug in TextFlow layout, maybe there is some exception that is silently ignored, but I haven't been able to reproduce it using just the JDK, so it must also have to do with how TextFlow is used in RichTextFX.
Any update? I'm trying to develop a window using this program and it looks absolutely horrid considering half the text is plagued with this.
It's also not an issue with the TextFlow layout, its a bug with your ParagraphBox system that I'm not familiar enough with the system to identify. When scrolling, appending newlines, or anything to change the xy of a ParagraphBox it duplicates the box, leaving the old one behind which is what causes the text to render on top of each other. Thats what I've noticed at least.
Hi @Arhowk, I haven't had much time lately to invest in RichTextFX, but this is high on my to-do list.
Thanks for trying to determine the cause of the problem, but duplicating the box would not result in disappearing text, as seen in @melkhaldi's GIF above.
@TomasMikula I would like to add to this ticket that I am experiencing the same bug in JDK8u25, I originally posted this as issue #105 but i did not realize the issue had already been posted so my apologies.
Additionally I would like to add that I have seen something also similar with the WebEngine built in HTML component with JavaFX. It's kind of similar to the notorious Blue Hell + Trails in older Grand Theft Auto games, which is sort of a meme for the background isn't being cleared. When I encountered this issue in RTFX I automatically thought of the same issue I had with the WebEngine component.
Thanks for sharing your experience. Have you reported the problem with WebView to the JavaFX team? Have they resolved it?
@TomasMikula I went and did a little more testing, I think what I spoke of above was just to do with clipping. But for an about window I am using a simple WebEngine with basic HTML to format my about Window text, it's just the copyright and version number. But I now notice whenever I select text the text near the selection jumps around by a few pixels and the selection also seems to become bold as a result of composite or something, similar to the bugs I am seeing with RTFX. It's real easy to reproduce if you just create a WebEngine and set some random HTML in it and test the selection on it, if you have good eyes. I have not reported this to the JavaFX team but I believe now this projects issues may be deeper rooted in the JDK.
I actually perused the internet and after a while finally managed to find someone who has experienced something similar to me with the WebView. http://stackoverflow.com/questions/20324570/javafx-webview-letter-spacing-bug
I hope I am not being irrelevant here but I just think that it may be related to some underlying issue with the framework and might give you some insight. Hope this helps!
Just to give you guys a heads up, I have done a major refactoring of Flowless (not pushed to github yet) which so far seems to avoid this rendering problem. I still need to do some work to match the former efficiency in terms of cell (i.e. line) creations and layouts. That's why it's not public yet, but the outlook seems good.
That said, I haven't found the real cause of this problem. It's just the way the new Flowless works with cells seems to avoid the problem.
In the old Flowless, whenever a line changed, it was laid out and positioned right away, not waiting for the layout pass. That way, it was easier to only update what was necessary.
In the new version, all changes request and wait for the layout pass (which is how things are usually done everywhere in JavaFX). There may (possibly) be more changes before the layout takes place (multiple edits and size changes), so it is more difficult in the layout pass to figure out what needs to be done and do no more than what is necessary. I need to optimize that some more and then publish.
Either way, one should never get artifacts like those encountered in this issue from TextFlow, no matter what you do with it, at least not without getting an exception. So I still think there is a bug somewhere in TextFlow, or an exception being silenced, that I haven't uncovered, and thus this could bite us again in the future.
Dear Tomas,
thank you. Can I get that Pre-Release from somewhere already so I can try it with my code?
Hi Thomas, I published an updated 1.0.0-SNAPSHOT to the Sonatype snapshot repository, which depends on flowless-0.4-SNAPSHOT, which in turn depends on reactfx-2.0-SNAPSHOT. Make sure to get all these dependencies right and I will be glad if you try it.
Something seems to depend on undofx,easybind and wellbehavedfx. After I added all those dependencies, I get
java.lang.NoSuchMethodError: org.reactfx.value.Val.combine(Ljavafx/beans/value/ObservableValue;Ljavafx/beans/value/ObservableValue;Ljava/util/function/BiFunction;)Lorg/reactfx/value/Val;
at org.fxmisc.flowless.SizeTracker.<init>(SizeTracker.java:41)
at org.fxmisc.flowless.VirtualFlowContent.<init>(VirtualFlowContent.java:61)
at org.fxmisc.flowless.VirtualFlow.<init>(VirtualFlow.java:43)
at org.fxmisc.flowless.VirtualFlow.createVertical(VirtualFlow.java:30)
at org.fxmisc.richtext.skin.StyledTextAreaVisual.<init>(StyledTextAreaVisual.java:141)
at org.fxmisc.richtext.StyledTextArea.lambda$createDefaultSkin$12(StyledTextArea.java:724)
at org.fxmisc.richtext.StyledTextArea$$Lambda$192/1676993645.apply(Unknown Source)
at org.fxmisc.wellbehaved.skin.Skins$1.<init>(Skins.java:60)
at org.fxmisc.wellbehaved.skin.Skins.createSimpleSkin(Skins.java:59)
at org.fxmisc.richtext.StyledTextArea.createDefaultSkin(StyledTextArea.java:722)
at javafx.scene.control.Control.impl_processCSS(Unknown Source)
I possibly didn't upload the latest ReactFX snapshot before. Now it is there. Make sure to get a fresh copy of reactfx-2.0-SNAPSHOT.
@TomasMikula Hey I wanted to weigh in again, I think you may correct that it is an underlying issue in JavaFX somewhere, but I am not sure since it sounds like your new class follows the other controls conventions more as you said and it alleviates the artifacts. However I want to show you the previous screenshot sized up with nearest neighbor filtering. If I had time I could test but I think some of the characters are getting rendered and then the selection color is getting rendered after them, do you know if that is at all possible? I could prove it for sure if I could set the background color to red and then we would know by what color the artifacts are, but I don't have time right now to build RFX
If someone could test with the background color as red or bright green, etc, and upload a screencap of the artifacts that would be really helpful. I feel this by extension is also related to antialiasing, it's antialiasing by interpolating with the background color, so disabling AA may also stop the artifacts theoretically.
Looking at the artifacts again, you are probably right and we are dealing with two different issues here, one of them related to selection and the other independent of the selection.
Hi Tomas, seems that the problem of jntrb (NoSuchMethodError) is not really fixed. I'm just referencing richtextfx 1.0.0-SNAPSHOT in my POM and all dependencies are pulled also as SNAPSHOTs, beside reactFx. It's pulling 1.4.1. The solution is to declare reactFx 2.0-SNAPSHOT in POM. But there are some printlns() for debugging purposes in. Let me know if you need more information to get rid of it.
And thanks for your great work with your FX libraries. =)
The POM for richtextfx correctly declares the 2.0-SNAPSHOT of reactfx, as you can see. So the 1.4.1 must be pulled in by another dependency, like undofx. So please just make sure your classpath contains reactfx-2.0-SNAPSHOT (and no other reactfx version before it) and you should be fine.
I am aware of the debugging outputs. I just published whatever I currently had on my machine. This will not be in the release. The printlns show that quite a lot of cell creations and layouts is being done right now, which needs to be optimized somewhat.
I am happy to announce that version 0.6 is now available, which avoids this issue, at least the one with distorted and/or disappearing text. I haven't done anything specific to resolve the selection artifacts, so I presume they may still appear. In that case, please report again.
Hi Tomas, check the GIF below. I noticed a rendering issue with the latest release. This is using the demo-sample. The below happens as I resize the text area and make text selections.