On Fri, 13 May 2022 05:34:08 GMT, Tomator wrote:
> When I used BlueJ, I found a problem with Chinese display.
> /javafx.graphics/com/sun/javafx/font/CompositeGlyphMapper.java#getGlyphCode
> may return a negative number when no font library is specified in Linux,and
> this could cause
On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>> good test coverage.
>>
>> This
On Tue, 22 Mar 2022 07:46:40 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>> good test coverage.
>>
>> This
On Mon, 21 Mar 2022 08:59:34 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>> good test coverage.
>>
>> This
On Sat, 12 Mar 2022 04:57:37 GMT, Michael Strauß wrote:
> `Observable{List/Set/Map}Wrapper.retainAll/removeAll` can be optimized for
> some edge cases.
>
> 1. `removeAll(c)`:
> This is a no-op if 'c' is empty.
> For `ObservableListWrapper`, returning early skips an object allocation. For
>
On Thu, 17 Mar 2022 21:10:14 GMT, Marius Hanl wrote:
> This simple PR optimizes the observable `ArrayList` creation by using the
> ArrayList constructor/array size so that the underlying array will be
> initialized at the correct size which will speed up the creation as the array
> does not
On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote:
> Issue: The end point of line in drawLinesForText , add thickness to the
> endPoint.y(). In this case origin which is start point and the end point
> would not be same, and line would be drawn not straight.
> Solution: Do not add thickness
On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote:
> Issue: The end point of line in drawLinesForText , add thickness to the
> endPoint.y(). In this case origin which is start point and the end point
> would not be same, and line would be drawn not straight.
> Solution: Do not add thickness
On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote:
> Issue: The end point of line in drawLinesForText , add thickness to the
> endPoint.y(). In this case origin which is start point and the end point
> would not be same, and line would be drawn not straight.
> Solution: Do not add thickness
On Mon, 7 Feb 2022 10:24:01 GMT, Jose Pereda wrote:
>> This PR adds a predicate to TableView and TreeTableView selection models
>> order to remove rows from the selection only when there are no selected
>> cells in that given row, when cell selection is enabled.
>>
>> Two tests have been
On Sat, 8 Jan 2022 17:30:55 GMT, Michael Strauß wrote:
>> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype
>> specified for images encoded in data URIs. This should be improved as
>> follows:
>>
>> 1. If the specified image subtype is not supported, an exception will
On Fri, 7 Jan 2022 19:36:45 GMT, Jose Pereda wrote:
> This PR adds a predicate to TableView and TreeTableView selection models
> order to remove rows from the selection only when there are no selected cells
> in that given row, when cell selection is enabled.
>
> Two tests have been added as
On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote:
> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC.
> - Added support for elementary AAC streams without any container for audio
> only streams.
> - Added "aacparse" plugin from GStreamer. Required on Linux, since
On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote:
> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC.
> - Added support for elementary AAC streams without any container for audio
> only streams.
> - Added "aacparse" plugin from GStreamer. Required on Linux, since
On Wed, 2 Feb 2022 07:34:55 GMT, Ambarish Rapte wrote:
> Update JavaFX WebKit to GTK WebKit 2.34 (613.1).
>
> Verified the updated version build, tests run and sanity testing.
> This does not cause any issues except a unit test failure
> `IrresponsiveScriptTest`.
> It is recorded and ignored
On Tue, 21 Dec 2021 15:35:32 GMT, Kevin Rushforth wrote:
>> Good point. All the test cases that I could think of were already present in
>> `MultipleSelectionModelImplTest`. Nevertheless, test cases for different
>> `set()` methods can definitely be added. I will work on it.
>
> What about the
On Fri, 26 Nov 2021 19:44:14 GMT, Abhinay Agarwal wrote:
>> tests/manual/controls/SelectTableViewTest.java line 19:
>>
>>> 17: // final int ROW_COUNT = 80_000;
>>> 18: // final int ROW_COUNT = 50_000;
>>> 19: // final int ROW_COUNT = 8_000;
>>
>> The number is meaningful because
On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote:
> This work improves the performance of `MultipleSelectionModel` over large
> data sets by caching some values and avoiding unnecessary calls to
> `SelectedIndicesList#size`. It further improves the performance by reducing
> the number
On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote:
> This work improves the performance of `MultipleSelectionModel` over large
> data sets by caching some values and avoiding unnecessary calls to
> `SelectedIndicesList#size`. It further improves the performance by reducing
> the number
On Mon, 22 Nov 2021 16:25:22 GMT, Michael Strauß wrote:
>> I could move `int max = size();` outside the loop
>
> But why? The initialization block of a `for` statement is exactly where you'd
> put loop-scoped variables.
This change significantly improves performance because the BitSet's size
On Mon, 24 Feb 2020 07:39:43 GMT, yosbits
wrote:
> If there are many columns, the current TableView will stall scrolling.
> Resolving this performance issue requires column virtualization.
> Virtualization mode is enabled when the row height is fixed by the following
If there are many columns, the current TableView will stall scrolling.
Resolving this performance issue requires column virtualization. Virtualization
mode is enabled when the row height is fixed by the following method.
`tableView.setFixedCellSize(height)`
This proposal includes a fix because
On Mon, 14 Sep 2020 10:03:59 GMT, Ajit Ghaisas wrote:
> Can you please provide an automated test along with your fix?
Automated performance testing should be distinguished from regular testing
tasks, as it extends the build time.
Is there a task name for that in gradle?
Also, didn't you
On Wed, 26 Feb 2020 07:37:06 GMT, yosbits
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8197991
>
> The performance of the selectAll and selectRange methods of the
> MultiSelectionModel class has been greatly improved.
>
> This greatly improves the response when select
https://bugs.openjdk.java.net/browse/JDK-8197991
The performance of the selectAll and selectRange methods of the
MultiSelectionModel class has been greatly improved.
This greatly improves the response when selecting multiple items in ListView
and TableView.
However, in TreeView /
On Thu, 1 Apr 2021 23:50:12 GMT, Marius Hanl
wrote:
>> Because it is such a small correction
>> Problem from me I feel that it is not easy to register, but I will try to
>> register.
>>
>> It has passed two existing tests for compatibility:
>>
>> * gradle base:test
>> * gradle
On Thu, 10 Sep 2020 13:41:00 GMT, Kevin Rushforth wrote:
>> I have found that fixing this rudimentary problematic code alleviates your
>> problem.
>>
>> **This fix will reduce CPU usage by about 1/3 without your changes.**
>> **This fix improves performance in many widespread use cases.**
>>
On Wed, 9 Sep 2020 06:53:11 GMT, dannygonzalez
wrote:
>> @dannygonzalez Per [this
>> message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html)
>> on the openjfx-dev mailing list, I have filed a new JBS issue for this PR
>> to use. Please change the title to:
>>
On Wed, 26 Aug 2020 15:40:57 GMT, Jose Pereda wrote:
>> I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM
>> and look at the hotspots in the JavaFX thread, you can see that about 45% of
>> the time in the JavaFX thread is spent in removeListener calls.
>>
>> Note: In
On Wed, 15 Apr 2020 07:11:27 GMT, dannygonzalez
wrote:
>> @dannygonzalez You mentioned "There are multiple change listeners on a Node
>> for example, so you can imagine with the number of nodes in a TableView this
>> is going to be a problem if the unregistering is slow.".
>>
>> Your changes
On Mon, 2 Mar 2020 11:47:03 GMT, Nir Lisker wrote:
>>>
>>>
>>> I think that a starting point would be to decide on a spec for the listener
>>> notification order: is it specified by their registration order, or that is
>>> it unspecified, in which case we can take advantage of this for
On Wed, 26 Feb 2020 10:07:02 GMT, Jeanette Winzenburg
wrote:
>> I think that a starting point would be to decide on a spec for the listener
>> notification order: is it specified by their registration order, or that is
>> it unspecified, in which case we can take advantage of this for better
On Tue, 18 Feb 2020 09:02:36 GMT, dannygonzalez
wrote:
>> @dannygonzalez the reason for the `jcheck` failure is that you have commits
>> with two different email addresses in your branch. At this point, it's
>> probably best to squash the commits into a single commit with `git rebase -i
>>
On Tue, 29 Dec 2020 09:50:42 GMT, Jose Pereda wrote:
>> I commented.
>
> I've run SelectListView and SelectTableView tests and both run fine. As for
> the SelectTableView test, with 700_000 rows, when there is no selection,
> pressing SelectToEnd takes around 3.1 seconds, as expected. However,
On Fri, 9 Oct 2020 22:59:37 GMT, Kevin Rushforth wrote:
>> @kevinrushforth
>>
>> To show an improvement in time efficiency, the
>> We need to fix the other high-priority hotspots first. I have determined
>> that the current proposed change in the
>> Run-Length approach needs a lot of time to
On Fri, 9 Oct 2020 16:51:05 GMT, yosbits
wrote:
>> I understand that this will improve the performance of this method in some
>> cases (but not all as you correctly point
>> out), but what I really meant by my questions was: When does this matter to
>> an applicati
On Fri, 9 Oct 2020 13:37:57 GMT, Kevin Rushforth wrote:
>> The performance improvements of the first change were self-evident, but
>> I agree that the current changes need to be explained.
>>
>> BitSet Features
>> * When using BitSet, memory usage (N/8) is wasted in the case of removing
>> the
On Fri, 9 Oct 2020 01:06:54 GMT, Kevin Rushforth wrote:
>> It seems that many people are interested, so I pushed the change.
>> I don't understand how to proceed with the review on Github correctly, so if
>> I have anything to do, please comment.
>>
>> java
>> for(int
On Wed, 7 Oct 2020 18:34:23 GMT, yosbits
wrote:
>> I plan to push changes that remain compatible, respecting the judgment of
>> the project leader, but I would like to point
>> out the following:
>> There seems to be a problem with the repr
that does not use BitSet, it is
> possible to reduce the CPU load in a wide range
> of use cases.
> The test is done with the following command.
>
> * gradle base: test
> * gradle controls: test
yosbits has updated the pull request incrementally with one additional c
On Wed, 7 Oct 2020 14:24:36 GMT, yosbits
wrote:
>> Hopefully not looking in the wrong version but:
>> (1) When dealing with BitSets previously, maybe this was by design butI
>> didn’t see any usage of BitSet’s
>> “clear()” to remove items from the BitSet. Although
On Wed, 7 Oct 2020 12:11:12 GMT, Eric Bresie
wrote:
>>>
>>>
>>> I'm preparing a change that won't break compatibility, so stay tuned.
>>> The test seems to need to be added.
>>
>> sounds good :) Note, that I'm working on
>> [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040)
On Wed, 7 Oct 2020 11:30:16 GMT, Jeanette Winzenburg
wrote:
>>>
>>>
>>> did anyone look into Java-Collection-Frameworks (ArrayList and friends or
>>> Eclipse-Collections) how they handle this
>>> situation effeciently?
>>
>> not me - but good idea, provided they support modifications to the
On Tue, 6 Oct 2020 16:36:44 GMT, Kevin Rushforth wrote:
>> yosbits has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR.
>
> As mentioned
On Fri, 2 Oct 2020 16:29:56 GMT, Kevin Rushforth wrote:
>> The fix looks good to me. I left a few comments on the test, but it looks
>> like a great start.
>
> One meta-comment:
>
>> @yososs yososs force-pushed the
>>
On Thu, 1 Oct 2020 11:23:03 GMT, Jeanette Winzenburg
wrote:
>> I understand that some people want support for the **new features** of Skin
>> Swiching.
>
>>
>>
>> I understand that some people want support for the **new features** of Skin
>> Swiching.
>
> Assuming that you are joking ;)
On Fri, 25 Sep 2020 19:01:35 GMT, Jeanette Winzenburg
wrote:
>> @kleopatra
>> It's a very good point, but the original source code seems to have a memory
>> leak problem due to an incomplete
>> implementation of dispose (). Checking with the profile tool, it looks like
>> you need a cleanup
On Wed, 23 Sep 2020 15:41:43 GMT, yosbits
wrote:
> * https://bugs.openjdk.java.net/browse/JDK-8090110
> * https://bugs.openjdk.java.net/browse/JDK-8089418
>
> TextArea slows down as the number of characters increases. This problem can
> be greatly improved by setting the clip o
* https://bugs.openjdk.java.net/browse/JDK-8090110
* https://bugs.openjdk.java.net/browse/JDK-8089418
TextArea slows down as the number of characters increases. This problem can be
greatly improved by setting the clip of
the display area. It also improves performance when increasing the font
On Fri, 25 Sep 2020 11:19:39 GMT, Jeanette Winzenburg
wrote:
>> @kevinrushforth
>> I don't know how to avoid the jcheck error, but what can I do?
>> yosbits is Naohiro Yoshimoto.
>
> beware: all listeners that are manually added by the skin (as opposed to
> thos
On Tue, 22 Sep 2020 09:04:15 GMT, yosbits
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8197991
>>
>> The performance of the selectAll and selectRange methods of the
>> MultiSelectionModel class has been greatly improved.
>>
>> This greatly improves
On Mon, 14 Sep 2020 09:50:05 GMT, Ajit Ghaisas wrote:
>> yosbits has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR.
>
> modules/javaf
() - t));
> }
> private void selectToLast(TableView tableView) {
> long t = System.currentTimeMillis();
>
> tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(),
> tableView.getItems().size()); System.out
On Mon, 14 Sep 2020 09:53:25 GMT, Ajit Ghaisas wrote:
>> yosbits has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views
>> will show differences compared to the previous content of the PR. The pull
>> request
() - t));
> }
> private void selectToLast(TableView tableView) {
> long t = System.currentTimeMillis();
>
> tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(),
> tableView.getItems().size()); System.o
that does not use BitSet, it is
> possible to reduce the CPU load in a wide range
> of use cases.
> The test is done with the following command.
>
> * gradle base: test
> * gradle controls: test
yosbits has refreshed the contents of this pull request, and previous commits
that does not use BitSet, it is
> possible to reduce the CPU load in a wide range
> of use cases.
> The test is done with the following command.
>
> * gradle base: test
> * gradle controls: test
yosbits has updated the pull request incrementally with one additional c
that does not use BitSet, it is
> possible to reduce the CPU load in a wide range
> of use cases.
> The test is done with the following command.
>
> * gradle base: test
> * gradle controls: test
yosbits has updated the pull request incrementally with one additional c
On Mon, 21 Sep 2020 11:19:30 GMT, yosbits
wrote:
>> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java
>> line 191:
>>
>>> 189: if (this.isEmpty() || c.isEmpty()) {
>>> 190: return false;
>>
On Mon, 21 Sep 2020 11:59:55 GMT, Jeanette Winzenburg
wrote:
>> I can't answer(, but my intuition is a pattern of lack of skill).
>> Officially, I don't know because the history is interrupted.
>
> digging a bit: the BitSet was introduced with
> https://bugs.openjdk.java.net/browse/JDK-8093144
On Mon, 21 Sep 2020 10:45:49 GMT, Jeanette Winzenburg
wrote:
>> Since the purpose of this issue is performance tuning,
>> Rewriting with removeIf has a different purpose.
>> This is the same as the original code.
>>
>> The iteration order is reversed because index movement does not occur
On Mon, 21 Sep 2020 10:40:37 GMT, Jeanette Winzenburg
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8253086
>>
>> ObservableListWrapper.java
>> * public boolean removeAll(Collection c)
>> * public boolean retainAll(Collection c)
>>
>> These two methods use BitSet, but it doesn't make
On Sat, 19 Sep 2020 01:09:10 GMT, Nir Lisker wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8253086
>>
>> ObservableListWrapper.java
>> * public boolean removeAll(Collection c)
>> * public boolean retainAll(Collection c)
>>
>> These two methods use BitSet, but it doesn't make sense.
>> By
On Mon, 14 Sep 2020 10:03:59 GMT, Ajit Ghaisas wrote:
>> Any progress with having this merged?
>
> This is a very good attempt to improve selection performance. I have few
> review comments.
> I ran the manual test that you have provided. It does show the improvement.
> Can you please provide
https://bugs.openjdk.java.net/browse/JDK-8253086
ObservableListWrapper.java
* public boolean removeAll(Collection c)
* public boolean retainAll(Collection c)
These two methods use BitSet, but it doesn't make sense.
By rewriting to the equivalent behavior that does not use BitSet, it is
On Thu, 10 Sep 2020 13:41:00 GMT, Kevin Rushforth wrote:
>> I have found that fixing this rudimentary problematic code alleviates your
>> problem.
>>
>> **This fix will reduce CPU usage by about 1/3 without your changes.**
>> **This fix improves performance in many widespread use cases.**
>>
On Wed, 9 Sep 2020 06:53:11 GMT, dannygonzalez
wrote:
>> @dannygonzalez Per [this
>> message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html)
>> on
>> the openjfx-dev mailing list, I have filed a new JBS issue for this PR to
>> use. Please change the title to:
On Wed, 9 Sep 2020 02:46:37 GMT, yosbits
wrote:
>> @yososs Per [this
>> message](https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-September/027534.html)
>> on the
>> openjfx-dev mailing list, I have closed
>> [JDK-8185886](https://bugs.openj
On Tue, 8 Sep 2020 20:19:13 GMT, Kevin Rushforth wrote:
>> Column virtualization causes shortness of breath when scrolling a large
>> stroke horizontally.
>> This does not happen when stroking on the scrollbar. Looks like a potential
>> problem with VirtualFlow.
>>
>> If you are worried about
On Wed, 2 Sep 2020 10:46:48 GMT, Jeanette Winzenburg
wrote:
>> When the startup time is measured by eye, the impression changes depending
>> on the individual difference.
>> The effect of runLater affects your experience.
>>
>> However, I succeeded in further improving performance by
nal TreeItem parent) {
>
> final TreeItem[] childNodes = new TreeItem[20];
> for (int i = 0; i < childNodes.length; i++) {
> childNodes[i] = new TreeItem<>("N" + i);
> }
> final TreeIt
On Tue, 1 Sep 2020 14:12:15 GMT, Jeanette Winzenburg
wrote:
>> Since there was a problem that the cell was not updated when the window was
>> maximized, I added a fix to
>> TreeTableViewSkin.java.
>> Added test code (BigTreeTableViewTest) for TreeTableView to the first post.
>>
>> @kleopatra
On Sun, 30 Aug 2020 13:20:49 GMT, Jeanette Winzenburg
wrote:
>> 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
private void prepareTimeline(final Scene scene) {
> new AnimationTimer() {
> @Override
> public void handle(final long now) {
> final double fps =
> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS();
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 probl
On Wed, 26 Aug 2020 15:40:57 GMT, Jose Pereda wrote:
>> I have attached a code sample. If you use OpenJFX 16-ea+1 and run visual VM
>> and look at the hotspots in the JavaFX
>> thread, you can see that about 45% of the time in the JavaFX thread is spent
>> in removeListener calls.
>> Note: In
On Fri, 3 Apr 2020 03:55:37 GMT, yosbits
wrote:
>> Hi,
>> I couldn't find you listed at
>> https://www.oracle.com/technetwork/community/oca-486395.html . Please send
>> me an e-mail
>> at dalibor.to...@oracle.com with information about your OCA, so that I c
cene scene) {
> new AnimationTimer() {
> @Override public void handle(long now) {
> double fps =
> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene).getInstantFPS();
> ((Stage)scene.getWindow()).setTitle("FP
On Wed, 15 Apr 2020 07:11:27 GMT, dannygonzalez
wrote:
>> @dannygonzalez You mentioned "There are multiple change listeners on a Node
>> for example, so you can imagine with the
>> number of nodes in a TableView this is going to be a problem if the
>> unregistering is slow.".
>> Your changes
If there are many columns, the current TableView will stall scrolling.
Resolving this performance issue requires column
virtualization. Virtualization mode is enabled when the row height is fixed by
the following method.
`tableView.setFixedCellSize(height)`
This proposal includes a fix because
On Thu, 2 Apr 2020 17:38:00 GMT, Dalibor Topic wrote:
>> The title of your PR should match the title of the JBS issue. Moreover, #108
>> already tackles this issue with a
>> different approach and 2 PRs on the same issue can't be intetgrated. Since
>> I'm not familiar with this code, I can't
On Mon, 24 Feb 2020 07:39:43 GMT, yosbits
wrote:
> If there are many columns, the current TableView will stall scrolling.
> Resolving this performance issue requires column
> virtualization. Virtualization mode is enabled when the row height is fixed
> by the foll
https://bugs.openjdk.java.net/browse/JDK-8197991
The performance of the selectAll and selectRange methods of the
MultiSelectionModel class has been greatly improved.
This greatly improves the response when selecting multiple items in ListView
and TableView.
However, in TreeView /
On Mon, 2 Mar 2020 11:47:03 GMT, Nir Lisker wrote:
>>>
>>>
>>> I think that a starting point would be to decide on a spec for the listener
>>> notification order: is it specified by
>>> their registration order, or that is it unspecified, in which case we can
>>> take advantage of this for
On Wed, 26 Feb 2020 10:07:02 GMT, Jeanette Winzenburg
wrote:
>> Hmm .. personally, I would consider changing such a basic (and probably
>> highly optimized) implementation used all over the framework is a very high
>> risk change that at the worst outcome would detoriate internal and external
On Tue, 18 Feb 2020 09:02:36 GMT, dannygonzalez
wrote:
>> @dannygonzalez the reason for the `jcheck` failure is that you have commits
>> with two different email addresses in your branch. At this point, it's
>> probably best to squash the commits into a single commit with `git rebase -i
>>
86 matches
Mail list logo
