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: | [Auto Comment] Selection changes in member list is very slow | ||
---|---|---|---|
Product: | java | Reporter: | Jesse Glick <jglick> |
Component: | Javadoc | Assignee: | issues@java <issues> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | pnejedly |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jesse Glick
2001-05-04 12:08:36 UTC
Target milestone -> 3.3 I've tried it using Utilities.mergeImages() and it is a lot faster now. What still bothers me is that mergeImages operate on images (two images as input, one as output) and I need to work with Icons (two ImageIcons as input, any Icon as output). I was using new ImageIcon( mergeImages( ico1.getImage(), ico2.getImage, 18, 0 ) ) and I don't like the new ImageIcon part, espacially when I looked at the ImageIcon( Image ) constructor (It checks the image with ImageTracker if it is already loaded). Couldn't there be something like this that would do caching at Icons level? OK, rewritten to use one ImageIcon instance, using setImage on it and relying on caching by IconManager. Also changed all the static ImageIcons to be only Images and loaded through Utilities.loadImage instead of ImageIcon(url) Maybe the images could be nonstatic to let them go if not used for longer time and IconManager caches them. But it's about 30KB, is it worth the effort? Resolved for 3.3.x or earlier, no new info since then -> closing. Resolved for 3.3.x or earlier, no new info since then -> closing. |