This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Splash progressbar have problems with high number of modules | ||
---|---|---|---|
Product: | platform | Reporter: | Petr Nejedly <pnejedly> |
Component: | Window System | Assignee: | Stanislav Aubrecht <saubrecht> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dsimonek, raccah, saubrecht |
Priority: | P4 | Keywords: | UI |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: |
Splash with bouble
Splash with logging |
Description
Petr Nejedly
2002-06-19 08:56:26 UTC
Created attachment 6313 [details]
Splash with bouble
The problem is that there is no way how to figure out the number of modules before they are actually loaded. In order to prevent displaying no progress before the modules are loaded, the progress bar increments itself by a single point until the number of modules is known. Of course, in case of 1000 modules it doesn't work properly. But I don't think we should make another hack for such edge-case. Or do you propose another solution? One possibility is to consider reading the module list as one operation. After that, you'll have exact number of modules for subsequent steps. The problem is that reading module list of 1000 modules takes 12s on my machine and progess bar will not move during that time. The other solution is to add an event passing a number of module files found (ModuleList:260 - there is a perflog tick, it is possible to replace it with regular event and pass the children.length with the event and convert it in NbEvents. But you'll still have to pass the number of modules later as it will be different from the number of files. On the other hand, I'll probably propose merging the module files to one for faster processing so it may be a nonissue later. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Please, reassign this issue to development team. reassigne to Marek, new owner of ui subcomponents Assigning to Tim -> P5 - who has 1000 modules? Tim: it was not problem of 1000 modules, only that I found it using 1000 modules. It would be visible even for, say, 200 modules, where NB has ~100. The problem was that there was a hardcoded magic constant representing number of modules. Anyway, the problem may already be gone thanks to the changes to the module system... If we need to hardcode a magic number, maybe best to put it in a brandable bundle and advise to pad the number if the app is likely to have additional modules installed by the user. But wait...wouldn't the line count of moduleCluster.properties + number of jars in userdir make a good estimate? Created attachment 16494 [details]
Splash with logging
Attached is a version of the splash screen with logging. Looking at the code for it, I can't figure out how you end up with something like the attached screen shot - the code is simply graphics.fillRect(x, y, w, h), and the only place x is assigned is on initialization. Just to be sure, I tried adding code to multiply various parameters by strange numbers. Could somebody who can reproduce the problem attach a log, preferably highlighting the point at which it starts to go wrong? Re-assigning Tim's issues to Dafe. Passing to Martin to distribute bugs evenly. Thanks Martine :-) I've just tried it with cca 450 simple generated modules and that bubbling didn't appear. It just stoped correctly at the end of the progress bar area with description texts regularly changing. But probably we should still enhance behaviour for such a number of modules since their number is still growing. So this is rather enhancment. There are hundreds of modules now and the problem was fixed a long ago. |