Re: RFR: 8202990: javafx webview css filter property with display scaling
On Tue, 11 Aug 2020 16:18:37 GMT, Bhawesh Choudhary wrote: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due > to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before > drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying > state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply > state to fix the issue. The fix and test looks good. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/279
Re: RFR: 8251353: Many javafx scenegraph classes have implicit no-arg constructors [v5]
On Wed, 26 Aug 2020 15:46:46 GMT, Bhawesh Choudhary wrote: >> Added missing explicit no-arg constructors to classes in package >> javafx.scene, javafx.css and javafx.stage. > > Bhawesh Choudhary has updated the pull request incrementally with one > additional commit since the last revision: > > Updated comments as per JDK Convention Marked as reviewed by nlisker (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/283
Re: RFR: 8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing [v7]
On Wed, 26 Aug 2020 12:03:26 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Corrections in test > > looks good :) The fix looks good for an editable ComboBox. If the ComboBox is not editable, it will have the effect of making the HOME and END keys no-ops, which is a (possibly unwanted) change in behavior. I checked a couple native Windows apps and they have the behavior I would expect: the arrow keys, and the HOME / END keys navigate the text field for editable combo boxes. HOME and END go to the beginning or end of the list for non-editable combo boxes. While we could treat that as a follow-up issue, it would be worth thinking about whether we could limit the change to editable combo boxes. - PR: https://git.openjdk.java.net/jfx/pull/172
Re: RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes
On Thu, 27 Aug 2020 14:59:56 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.4 > https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html Looks good. Also, I tested on all three platforms. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/289
Re: RFR: 8236651: Simplify and update glass gtk backend
On Tue, 25 Aug 2020 14:12:14 GMT, Thiago Milczarek Sayao wrote: > I would starting hooking gtk event signals > (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the > "touch-event" to JavaFx events (probably need to add through JNI). Should be > simple. Contact me at thiago.sayao (gmail). Would it be safe you think to branch from your PR to have the updated gtk backend? It would be much easier to work with. - PR: https://git.openjdk.java.net/jfx/pull/77
RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes
Update to GTK WebKit 2.28.4 https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html - Commit messages: - 8252381: Cherry pick GTK WebKit 2.28.4 changes Changes: https://git.openjdk.java.net/jfx/pull/289/files Webrev: https://webrevs.openjdk.java.net/jfx/289/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252381 Stats: 174 lines in 21 files changed: 123 ins; 16 del; 35 mod Patch: https://git.openjdk.java.net/jfx/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/289/head:pull/289 PR: https://git.openjdk.java.net/jfx/pull/289
Re: Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView
I just want to quickly mention that option 3
(https://github.com/openjdk/jfx/pull/185) is no longer a WIP -- all
functionality is working all tests pass.
The PR creates a TreeShowingExpression class which encapsulates the tree
showing logic that was in Node class. This class is then only used by
ProgressIndicatorSkin and PopupWindow. This effectively means that
instead of registering a listener on Window and Scene for all nodes
they're only registered for those classes that need to know the showing
status of a Scene.
--John
On 27/08/2020 02:17, Kevin Rushforth wrote:
Sorry for the badly formatted html. Here it is again.
I see some progress being made on the {Tree}TableView performance issue.
To summarize where I think we are:
There are currently 2 different approaches under review:
1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base
to make removing listeners faster
2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView
to reduce the number of add / removes
In addition, the following is a WIP PR that the author thinks could be a
3rd approach:
3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph
to avoid install treeShowing listeners on Window and Scene for all nodes
Jose has proposed a 4th approach as a comment to PR #108, and as I
understand it, he will propose a PR shortly.
4. Don't clear the list of children in a VirtualFlow when the number of
items changes.
So the first thing that is needed is to evaluate the approaches and
decide which one to pursue.
Options 1 and 3 are more broad in their scope, option #2 is more
targeted (to TableView), but within that area is a larger change. Option
#3 would remove the (internal) treeShowing property as a generally
available concept and only use it for controls like ProgressIndicator
that really need it. Option #4 affects only controls that use
VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a
large change (presuming we can verify that no leak is introduced).
I note that these fixes are not mutually exclusive, but I do think we
need to settle on a primary approach and use that to fix this issue. If
there are still performance problems after that fix, we can consider one
(or more) of the others.
Comments?
-- Kevin
Re: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView [v2]
On Sat, 18 Apr 2020 17:40:30 GMT, yosbits wrote: >> My name is "Naohiro Yoshimoto" >> I have received an approved email on 2019-8-3. > > 19fabf2eafcb02b519d39a1b0a9dad5b9209db64 > > * Constructor creates multiple cell nodes, but the > Fixed a wasteful problem of creating all cells and deleting out-of-display > cells because the fixedCellSize attribute > was not initialized in the constructor.. > * Reduce the load on ExpressionHelper.removeListener by removing cells > outside of the display range from the back of the > scrolling operation. When setting the cell height to a fixed value with setFixedCellSize(), column virtualization can improve performance. As the next step, I think it is possible to try to enable column virtualization regardless of whether setFixedCellSize() is set or not. Before doing this step, the direct access validation of the internal structure of the test code needs to be changed via the public API. - PR: https://git.openjdk.java.net/jfx/pull/125
