-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebPathField Performance #698
Comments
Yes, unfortunately the current Path elements creation and update simply needs an overhaul:
I was planning to update And sorry for a late response, I missed the notification for this issue. |
Since a file chooser dialog (either created with Is there a way to force a non-WebLAF file chooser dialog to be used while the rest of the application uses WebLAF? I've temporarily replaced my path field use with text fields as well, but I can't avoid the file chooser dialogs unfortunately. |
I'm afraid it's not that simple to switch I've looked into current The problem here is that there is no good way (as far as I am aware) to avoid "poking" the network drives while trying to retrieve drives list on the old Java IO API - it is synchronous (done via In NIO there is a Unfortunately I can't use NIO yet because project is still supporting JDK 6u30+. I also don't think I can do much about synchronous roots loading because the current file tree and path field implementations do not support asynchronous roots loading and it would require far too many changes in many parts of those components to allow that. Tree does support asynchronous loading of any of the children, but that doesn't help much as that doesn't change the initial file chooser load time. I only see a couple of things that can be done to optimize file chooser load time at the current stage of the project:
These might potentially help bringing file chooser load time more in line with the one from other L&Fs. I'll have some time to look into that on these weekends, but I can't promise anything as this might involve quite a lot of changes across multiple components, not just the file chooser. But at the very least I can probably optimize path field and maybe add some caching for the roots loading as a temporary "dirty" performance fix. |
That's understandable given the Java 6 support need. I was able to work around it a little bit with a dirty hack for now too. Before installing WebLAF I create a singleton instance of a I wonder if it might be useful if WebLAF allowed a custom |
This is a very good idea, although I'm not sure if But there could be an alternative custom API made specifically for the chooser that has everything it needs with default implementation using old IO and potential to make a custom NIO one if you're using newer Java version. Maybe even not just for the chooser, but any file-related component in WebLaF. The main issue - it still requires substantial changes for all involved components, but it is definitely something that could work really well even in the current project stage. I'll see what can be done in reasonable time. |
I've looked into potential improvements these weekends - unfortunately all changes that can be done and that I've mentioned are pretty significant. I've started with path field rework as it is potentially the biggest "offender" right now and finished approximately half of it. I'll push those changes into main repo once completed and a snapshot version will be available (most probably at the end of next weekends). Once path field is revamped - I will be able to replace the old chooser panel with new one based on a unified model acting as data source for all the separate elements. Not yet sure if the tree will need some major updates or not, will see that when I'll get to it. |
Along the topic of the decorator / alternate roots supplier option, perhaps public class WebPathField extends WebPanel
{
// ... omitted things not relevant to this sugested
Supplier<File[]> fileRootSupplier = null;
// This function would be used where applicable in the class instead of calling FileUtils.getDiskRoots directly. Additionally, this allows the function to be overridden in a subclass. It could be assigned in a constructor or possibly changed with a set function too?
protected File[] getDiskRoots()
{
return (fileRootSupplier == null) ? FileUtils.getDiskRoots() : fileRootSupplier.get());
}
} |
It shouldn't be necessary (root supplier) when I did some more work on the I'm not yet sure whether this will be some kind of unified model between file chooser, path field and maybe some other file system -related components (similar to |
I noticed that when resizing a frame that contains a WebPathField, the
updatePath
method gets called quite a lot more than seems necessary. I dug a little, and it seems as though the resize listener for the text field part of the WebPathField does the following check:The
isShowing()
method always returns false since the pathField does not have a component peer set it seems. I can reproduce this with the following simple test (assuming running in the event dispatch thread):updatePath
can sometimes be a bottleneck, when file filters and disk/network I/O are taken into account. Would it be better to have that listener check that the WebPathField component itself is showing rather than the text field child component?The text was updated successfully, but these errors were encountered: