[Bug awt/30106] JDK-1.0-style logical font names
--- Comment #3 from hendrich at informatik dot uni-hamburg dot de 2006-12-14 07:57 --- (In reply to comment #2) I disagree. TimesRoman etc are not logical font names, but 'physical' font names. (Logical names are Serif, SansSerif, Monospaced, Dialog, and DialogInput -- refer to the API docs for java.awt.Font for more details). Well, Sun has corrected their mistake by now. My point is that they _did_ use TimesRoman, Helvetica, and Courier as the logical fonts names in JDK 1.0. Admittedly, there was little difference between logical and physical font names back then. Unfortunately, I have no copy of the 1.0.2 API docs lying around anymore to prove that, but the test case shows that the JDKs still acknowledge the old names. So, the question is whether we want bug-compatibility with Sun in this case, or not. I vote for compatibility. Adding the extra outdated font name checks fixes the compatibility issue, and applications that use the new logical font names will not see any difference. these work with the JDK is not strict backwards-compatibility, but only caused by Sun bundling these fonts with JREs. I don't think that we should map these names internally, as it is not at all correct. If one requests TimesRoman, he would expect the font 'TimesRoman' be loaded. Excatly. An (outdated) application that requests TimesRoman or Courier expects to get those, but with current classpath its gets Dialog in both cases. I guess that this would even work with GNU Classpath if you happen to have the Microsoft TTF fonts installed and registered with fontconfig. There are packages for many distros that pull in these (non-free) fonts. I don't see how this could happen. The logical font name is not recognized, and Dialog is substituted, regardless of what fonts are installed. Am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30106 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/29865] New: wrong clip in JScrollpane repainting
One of the recent RepaintManager/repaint updates breaks JScrollPane in my image-viewer application [1]. See attached image for an example. A cvs checkout from 2006.11.06 worked fine, while checkouts from 2006.11.13 and 2006.11.16 both show the same problem. Note that JScrollPane seems to work fine with most standard clients like JTree. It also works fine with my ImageViewer whenever a full repaint is performed (like un-obscuring the scrollpane, changing the size, etc.). The bug only occurs after typing the cursor down key, which is handled twice: it tells Niffler to load and display the next image, but it is also intercepted by the JScrollPane which scrolls up one line-increment. As you can see, the new image is loaded and mostly painted, but one line-increment-part of the old image is blitted into it. This can be repeated for some fun. To reproduce the bug, you need images that are larger than the scrollpane size and to disable the zoom-to-fit option (menu- view-zoom fit after loading), in order to make the scrollbars appear. [1] tams-www.informatik.uni-hamburg.de/people/alumni/hendrich/niffler -- Summary: wrong clip in JScrollpane repainting Product: classpath Version: 0.93 Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: roman at kennke dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29865 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/29865] wrong clip in JScrollpane repainting
--- Comment #1 from hendrich at informatik dot uni-hamburg dot de 2006-11-16 08:37 --- Created an attachment (id=12629) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12629action=view) screenshot showing the repaint issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29865 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/29566] New: NPEs from JTree repainting
Hello Roman, here are two more NPEs resulting from JTree repainting. I got these while running a slide-show in Niffler under rather high system load (heap memory almost exhausted, nominal 30 msec pause between images, both tree and image canvas visible). Classpath cvs 2006.10.20 with jamvm on Linux x86. This might well be a result of the high system load with lots of garbage-collection. Still, it shouldn't happen, and might be worth checking: Exception during event dispatch: java.lang.NullPointerException at javax.swing.plaf.basic.BasicTreeUI.isLastChild(BasicTreeUI.java:1623) at javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1572) at javax.swing.plaf.metal.MetalTreeUI.paint(MetalTreeUI.java:248) at javax.swing.plaf.ComponentUI.update(ComponentUI.java:193) at javax.swing.JComponent.paintComponent(JComponent.java:2069) at javax.swing.JComponent.paint(JComponent.java:1834) at javax.swing.JViewport.paintSimple(JViewport.java:794) at javax.swing.JViewport.paintBackingStore(JViewport.java:850) at javax.swing.JViewport.paint(JViewport.java:495) at javax.swing.JComponent.paintChildren(JComponent.java:1969) at javax.swing.JComponent.paint(JComponent.java:1837) at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:2349) at javax.swing.JComponent.paintImmediately2(JComponent.java:2266) at javax.swing.JComponent.paintImmediately(JComponent.java:2105) at javax.swing.JComponent.paintImmediately(JComponent.java:2131) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:594) at javax.swing.RepaintManager$RepaintWorker.run(RepaintManager.java:170) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:200) at javax.swing.RepaintManager$RepaintWorkerEvent.dispatch(RepaintManager.java:114) at java.awt.EventQueue.dispatchEvent(EventQueue.java:609) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) Exception during event dispatch: java.lang.NullPointerException at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:2332) at javax.swing.JComponent.paint(JComponent.java:1794) at javax.swing.tree.DefaultTreeCellRenderer.paint(DefaultTreeCellRenderer.java:532) at javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:189) at javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:219) at javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:237) at javax.swing.plaf.basic.BasicTreeUI.paintRow(BasicTreeUI.java:3892) at javax.swing.plaf.basic.BasicTreeUI.paint(BasicTreeUI.java:1603) at javax.swing.plaf.metal.MetalTreeUI.paint(MetalTreeUI.java:248) at javax.swing.plaf.ComponentUI.update(ComponentUI.java:193) at javax.swing.JComponent.paintComponent(JComponent.java:2069) at javax.swing.JComponent.paint(JComponent.java:1834) at javax.swing.JViewport.paintSimple(JViewport.java:794) at javax.swing.JViewport.paintBackingStore(JViewport.java:861) at javax.swing.JViewport.paint(JViewport.java:495) at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:2349) at javax.swing.JComponent.paintImmediately2(JComponent.java:2266) at javax.swing.JComponent.paintImmediately(JComponent.java:2105) at javax.swing.JComponent.paintImmediately(JComponent.java:2131) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:594) at javax.swing.RepaintManager$RepaintWorker.run(RepaintManager.java:170) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:200) at javax.swing.RepaintManager$RepaintWorkerEvent.dispatch(RepaintManager.java:114) at java.awt.EventQueue.dispatchEvent(EventQueue.java:609) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) -- Summary: NPEs from JTree repainting Product: classpath Version: 0.93 Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: roman at kennke dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29566 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/29420] OutOfMemory in image handling
--- Comment #6 from hendrich at informatik dot uni-hamburg dot de 2006-10-23 17:24 --- (In reply to comment #5) No, nothing since the 20'th. I'm assuming these images should not be in memory concurrently (slideshow loads one, then moves on to the next, and the original image *should* be freed) - so a memory leak somewhere? Yes. Either a leak or memory corruption, probably in the JNI/GTK parts. (A while ago, after I last reported similar OOME problems, Mark fixed several leaks in the GTK code. But I have no idea whether and where current cvs might trigger those anew.) The image viewer really only keeps one reference to the current image, and a temporary reference to the image it is next loading. I also had the thumbnails panel disabled for these tests; but the slideshow wait interval was so low that the JVM was continually loading new images. (When thumbnails generation and display is on, niffler also keeps a cache of the thumbnail images. But the thumbnails are really small, and the cache is cleared when memory runs low.) With cp cvs 2006.10.20, slideshows usually survive at least 200 images (jamvm with -Xmx300m), but the VM seems to get very unstable beyond that. Most often, the VM just crashes with a segfault, but here is one of the OOME stacktraces I got: java.lang.OutOfMemoryError at gnu.java.awt.peer.gtk.GtkImage.getPixels(Native Method) at gnu.java.awt.peer.gtk.CairoSurface.init(CairoSurface.java:181) at gnu.java.awt.peer.gtk.CairoSurface.getBufferedImage(CairoSurface.java:261) at gnu.java.awt.peer.gtk.GtkToolkit.createImage(GtkToolkit.java:255) at java.awt.Toolkit.createImage(Toolkit.java:661) at niffler.ImageUtils.loadImageViaToolkit(ImageUtils.java:253) at niffler.ImageUtils.loadImageViaToolkit(ImageUtils.java:211) at niffler.Niffler.loadImage(Niffler.java:1622) ... at niffler.SlideshowManager.run(SlideshowManager.java:82) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29420 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/28769] Regression:JTree and JTable mouse-wheel scrolling
--- Comment #15 from hendrich at informatik dot uni-hamburg dot de 2006-10-19 08:47 --- Could you please retest? Just tested current cvs (2006.10.19). Mouse-wheel scrolling seems to work on JTree now, at least in my test applications. Fixed! Note: I got a new (apparently harmless) NPE from repaint() today: java.lang.NullPointerException at javax.swing.JComponent.repaint(JComponent.java:2889) at javax.swing.plaf.basic.BasicTreeUI$FocusHandler.repaintLeadRow(BasicTreeUI .java:2338) at javax.swing.plaf.basic.BasicTreeUI$FocusHandler.focusGained(BasicTreeUI.ja va:2315) at java.awt.Component.processFocusEvent(Component.java:3740) at java.awt.Component.processEvent(Component.java:3661) at java.awt.Container.processEvent(Container.java:1027) at java.awt.Component.dispatchEventImpl(Component.java:5737) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Component.dispatchEvent(Component.java:2836) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:11 03) at java.awt.DefaultKeyboardFocusManager.handleFocusGained(DefaultKeyboardFocu sManager.java:274) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusMan ager.java:188) at java.awt.Component.dispatchEventImpl(Component.java:5724) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Window.dispatchEventImpl(Window.java:621) at java.awt.Component.dispatchEvent(Component.java:2836) at java.awt.EventQueue.dispatchEvent(EventQueue.java:618) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) -- hendrich at informatik dot uni-hamburg dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28769 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/29513] New: JTree.scrollPathToVisible/expandPath buglet
A corner case in JTree behaviour: One of my test applications does the following to ensure that the tree node selected by the user becomes visible: ... TreePath treepath = new TreePath( node.getPath() ); fileListTree.setSelectionPath( treepath ); fileListTree.scrollPathToVisible( treepath ); fileListTree.expandPath( treepath ); // FIXME: required? When the selected subtree has more leaf nodes than fit on screen, classpath (cvs 2006.10.19) scrolls the tree to show the path from root-node to selected subtree, but the currently selected leaf node might become invisible. The JDK scrolls the tree to always show the selected leaf node, which is better. Note that the above code might be questionable, because the call to expandPath() after scrollPathToVisible() is redundant. I probably added it to get an earlier version of classpath or the JDK (1.3.x?) to work... -- Summary: JTree.scrollPathToVisible/expandPath buglet Product: classpath Version: 0.93 Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: roman at kennke dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29513 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/28769] Regression:JTree and JTable mouse-wheel scrolling
--- Comment #9 from hendrich at informatik dot uni-hamburg dot de 2006-10-18 15:15 --- Hello Roman and Audrius, first of all, thanks for working on Swing in general, and my bugs in particular. Please don't quarrel about the bugs or the exact state of them. By now, I am pretty experienced in re-opening bugs when necessary - for example, right now :-) (In reply to comment #8) I have just tested the JTree scrolling with fresh CVS check. The scrolling in both components with mouse wheel works correctly. Scrolling both up and down is possible, and even the boundary adjustment works as required. The user likely tested with the outdated version. I am closing this as no longer unreproducible. Well, I just tested with a fresh cvs checkout again to make sure. This is on Linux x86 with jamvm and cacao, with my image viewer (Niffler) as the text application. Playing with a large tree with about 4000 nodes (max depth six levels) shows that expanding and collapsing nodes in the tree works. However, I also sometimes get NPEs [1] from repaint(), but the tree looks ok. Basic mouse-wheel scrolling does indeed work now, both up and down, but scrolling down to the very bottom often resets the scrollbar thumb, and one can scroll down again... Doesn't happen when scrolling up. This doesn't happen always. My initial theory is that it happens when I use mouse-scrolling after expanding a new subtree, while it gets fixed when I click or drag the scrollbar. Is this an effect of the JTree layout cache? If so, please feel free to close the bug again :-) (If you bother to test this with my image viewer, please make sure to keep the mouse in motion... Otherwise, the HideCursorManager might trigger and hide the mouse cursor on the image canvas, which wrongly also hides the cursor in the JTree. I report this as a new bug.) [1] NPE from repaint: java.lang.NullPointerException at javax.swing.JComponent.repaint(JComponent.java:2889) at javax.swing.JTree$TreeSelectionRedirector.valueChanged(JTree.java:1287) at javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(DefaultTreeSelectionModel.java:769) at javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(DefaultTreeSelectionModel.java:1163) at javax.swing.tree.DefaultTreeSelectionModel.setSelectionPaths(DefaultTreeSelectionModel.java:461) at javax.swing.tree.DefaultTreeSelectionModel.setSelectionPath(DefaultTreeSelectionModel.java:338) at javax.swing.JTree.setSelectionPath(JTree.java:2211) at javax.swing.plaf.basic.BasicTreeUI.selectPathForEvent(BasicTreeUI.java:2095) at javax.swing.plaf.basic.BasicTreeUI$MouseHandler.handleEvent(BasicTreeUI.java:2543) at javax.swing.plaf.basic.BasicTreeUI$MouseHandler.mousePressed(BasicTreeUI.java:2469) at java.awt.Component.processMouseEvent(Component.java:3808) at java.awt.Component.processEvent(Component.java:3670) at java.awt.Container.processEvent(Container.java:1027) at java.awt.Component.dispatchEventImpl(Component.java:5737) at java.awt.Container.dispatchEventImpl(Container.java:1922) at java.awt.Component.dispatchEvent(Component.java:2836) at java.awt.LightweightDispatcher.redispatch(LightweightDispatcher.java:325) at java.awt.LightweightDispatcher.handleMouseEvent(LightweightDispatcher.java:151) at java.awt.LightweightDispatcher.dispatchEvent(LightweightDispatcher.java:115) at java.awt.Container.dispatchEventImpl(Container.java:1911) at java.awt.Window.dispatchEventImpl(Window.java:607) at java.awt.Component.dispatchEvent(Component.java:2836) at java.awt.EventQueue.dispatchEvent(EventQueue.java:618) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) -- hendrich at informatik dot uni-hamburg dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28769 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/29500] New: setCursor modifies wrong JComponent
My image viewer [1] uses a background thread to hide the cursor on the main image canvas after some seconds of inactivity. This is done by a call to setCursor() with a custom transparent cursor. Testing with classpath cvs 2006.08.18 shows that hiding the cursor and restoring the original cursor basically works. However, the call to ImageCanvas.setCursor() also changes (hides) the cursor of different parts of the GUI, namely the navigation tree and thumbnails preview panels, and even the main menus. A mouse-exit event on a component seems to reset the cursor in most cases. However, entering the main image canvas re-enables the MouseHideManager, and the cursor gets hidden again on whatever component it is positioned on. Might be a problem with JSplitPane, JComponent, or even Component (AWT), but I don't have a small testcase yet. [1] http://tams-www.informatik.uni-hamburg.de/people/alumni/hendrich/niffler/ -- Summary: setCursor modifies wrong JComponent Product: classpath Version: 0.93 Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: roman at kennke dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29500 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Torturing image ops and Swing
Hello all,
anyone interested in torturing our Swing, awt.image and javax.image operations
a bit? Long text with a question buried at the end. Sorry, but I had
to get this
off my soul; feeling much better already :-)
I have just uploaded a new, completely re-written version of my image
viewer to
http://tams-www.informatik.uni-hamburg.de/personal/hendrich/niffler/index.html
Unlike the previous version with its deeply-nested popup-menu, the new version
uses a more traditional user-interface. It also adds image histogram,
EXIF support,
and basic image editing based on get/setRGB, get/setRaster, ConvolveOp, and
ShortLookupOp (ByteLookupOp would be faster, but is broken on the JDK/Linux).
Download niffler-exif.jar (or the sources and build it yourself; you
will need the
metadata-extractor library from www.drewnoakes.com for building the
exif stuff).
jamvm -Xmx300m -Xms100m niffler.Niffler
1. Select menu File Open image directory... and select a directory with
some images. This is the first challenge, because JFileChooser is still
about as user-unfriendly as possible. (I somewhat fear that many first-time
classpath users might give up after trying to use JFileChooser. This is
unfortunate, because the rest of Swing works pretty well these days.)
2. By default, Niffler also includes subdirectories in its search.
Don't select
your home directory or this can take a long time (about one minute with
jamvm+cvs in my home directory, with 93.000+ files. For some reason,
cacao 0.96 crashes after listing about 15.000 files. Smaller
directories work.)
3. Loading small to medium-sized images works fine. Navigation works fine
(type 'space' or 'n' for next image, 'p' for previous image, or
use the menu).
Zooming works fine ('f' for zoom-fit, 'g' for original-size,
etc.). Mouse dragging
works fine. The navigation tree, thumbnails preview, and histogram all work
as they should (a little slow, perhaps, but jamvm is an
interpreter, after all).
Nitpicking: the splitpane dividers look bad.
4a. Loading typical digicam images with 4+ Mpixels is somewhat slower,
but still
almost acceptable. jamvm needs about 5 seconds for a 3000x2000 JPEG for
image loading, plus about 7 seconds for calculating the histogram
(when enabled).
JDK 1.5 needs about 1.5 seconds for loading plus 0.3 secs for the
histogram.
4b. Cacao calculates the histogram much faster (almost as fast as the
JDK), but
unfortunately it leaks memory and crashes after loading a few
4+Mpixel images
(with -Xmx300m and top reporting about 320M RSS actually used.)
It seems that cacao 0.96 never garbage-collects image data?
4c. I didn't test with gcj yet, neither did I try jcvm.
---
For the following, use smaller images (800x600 or so) to avoid frustration.
5. Select Tools Sharpen Laplace 3x3. Simple convolution filter implemented
with ConvolveOp and applied to a BufferedImage TYPE_INT_RGB.
java.lang.ArrayIndexOutOfBoundsException: 3
at java.awt.image.ColorModel.getComponentSize(ColorModel.java:200)
at java.awt.image.ColorModel.coerceData(ColorModel.java:641)
at java.awt.image.DirectColorModel.coerceData(DirectColorModel.java:405)
at java.awt.image.BufferedImage.coerceData(BufferedImage.java:288)
at java.awt.image.ConvolveOp.filter(ConvolveOp.java:126)
This worked a week ago, but very slowly. Try the Tools Edges Mexican
Hat 13x13 filter, if you don't believe me. The JDK seems to include some
optimizations for such (separable?) kernels.
OK, lets try something else:
6. Select Tools Negative Image. Obvious implementation based on
LookupOp. Works. Performance is ok (1 sec for 800x600). The result is
a BufferedImage.TYPE_INT_RGB.
BUT repainting suddenly takes 3 seconds for each paintComponent,
and the application is pretty much dead. For comparison, a repaint of the
BufferedImage before the filtering took about 10 msec.
For 3000x2000 images, each repaint takes 40 seconds on my system.
Any ideas about what I am doing wrong here are HIGHLY appreciated.
Load a new image. Repainting time is back to the millisecond range.
7. Perhaps LookupOp and ConvolveOp are bad? Select Tools Rotate
image left (or right). Implemented 'by hand' via getRGB and setRGB.
Much slower than LookupOp, about 4 seconds on my system at 800x600.
But again, repainting suddenly takes many seconds.
8. What about ImageIO instead of java.awt.Toolkit? Just select
Edit Load images via ImageIO.
Loading a 800x600 JPEG takes about 200 msecs with Toolkit, and about
7 seconds with Toolkit. Loading a 3000x2000 JPEG takes 200+ seconds.
The imageio GIF reader is much faster (4 seconds at 3000x2000), but now
the conversion to BufferedImage.TYPE_INT_RGB takes 90+ seconds...
Images returned by the PNG reader render as transparent.
9. Select Help Commands... A simple JTextArea in a JScrollPanel
Re: Torturing image ops and Swing
Hello Sven, thanks for your detailed answers to my questions! New Niffler version uploaded and available right now (niffler-exif.jar and niffler-src.zip). Right. BufferedImages created with Component.createImage(int, int) are backed by a Cairo surface. Ones created directly by BufferedImage are not. Again, this is one of these things that needs to be fixed, basically so that all BufferedImages can have some native backing buffer.) Hmmm... ok. I added a special classpath workaround to Niffler that checks for java.vendor and calls ImageUtils.getCairoBackedImage( bufferedImage) before rendering when GNU something is detected. This adds another image conversion (BufferedImage drawn into an Image created by Component.createImage()), but makes the editing operations useable with jamvm. Good. 7. Perhaps LookupOp and ConvolveOp are bad? Select Tools Rotate image left (or right). Implemented 'by hand' via getRGB and setRGB. Much slower than LookupOp, about 4 seconds on my system at 800x600. They can probably be faster, but I don't think they're the main problem if the times you're measuring also include the repaint time. Nope; the times I quoted were the raw processing times, as reported by System.currentTimeMillis() before and after the operation. Repainting times are extra... Loading a 800x600 JPEG takes about 200 msecs with Toolkit, and about 7 seconds with Toolkit. Loading a 3000x2000 JPEG takes 200+ seconds. Too slow. Yep. Please excuse my typo there; the 7 and 200+ seconds are for jamvm and classpath loading a 800x600 or 3000x2000 JPEG via the imageio JPEG plugin. You can try the 10+ MPixel images from the Brussels' mort subite for yourself... The imageio GIF reader is much faster (4 seconds at 3000x2000), but now the conversion to BufferedImage.TYPE_INT_RGB takes 90+ seconds... Really? That sounds too fast, almost. How do you mean conversion? Running it through a filter, or just drawing the image returned by IIO onto the the aforementioned BufferedImagE? You consider, 4+90 seconds too fast for 3000x2000? Wait for next years' digicams and cellphone cams :-) But yes; I use the same code-path for images loaded by AWT or IIO; the ImageUtils.getBufferedImage() method creates a BufferedImage.TYPE_INT_RGB and draws the input image into that (unless the input image already is RGB). Otherwise, I would need a PixelGrabber to get at the pixels for the histogram. Images returned by the PNG reader render as transparent. 9. Select Help Commands... A simple JTextArea in a JScrollPanel, but with about 700 lines of text. Try scrolling. Painfully slow. The vertical scrollbar only scrolls down on click event (but dragging works). I'll have to check this out. drawString is fairly slow nowadays. However, drawGlyphVector (and by extension TextLayout.draw) are quite snappy, comparable to the JDK in speed. We might need to tune Swing here. Should I submit another bug for this? Once upon a time, this used to be PR24152... I guess we need some technique to include performance-related tests in Mauve for regular regression testing. Unfortunately, I don't know how to do this, because both raw system speed and user picky-ness seem to differ greatly between different systems... Perhaps even better you could use VolatileImage (== an X pixmap). These objects are slower to draw onto, but render to the screen as fast as they possibly could, really. (Assuming X is doing a good job) So if your intention is to draw-onto-bitmap-once, display-bitmap-many, then it should make things many many times faster. OK. I last tried VolatimeImage when JDK 1.4 came out, and it didn't seem like a great idea to me back then... Perhaps it's time to give VolatileImage another chance, now... Thanks, Norman
[Bug awt/28369] BufferedImage.getRGB returns bad pixel data
--- Comment #7 from hendrich at informatik dot uni-hamburg dot de 2006-07-14 09:55 --- Subject: Re: BufferedImage.getRGB returns bad pixel data Ok, fixed now. Confirmed (cvs 2006.70.14). Just FYI: We've got a pure-java GIF decoder for IIO now which is pretty fast. (by which I mean over an order of magnitude faster than the GdkPixubufDecoder one) Try it out! Yeah, I have looked at this already (because I would need a pnm/ppm provider, and I wanted to see how much work this might be. Or could we just import the freehep pnm stuff?). BTW: javax/image/package.html still claims imageio to be based on ImageMagick, and it took me some time to figure out that gdk-pixbuf is used now... But I use my image viewer mostly for JPEGs, and the ImageIO JPEG provider takes 10+ seconds for 500x700 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28369 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
gconf needs ORBit?!
Hello all, another build surprise, and another stupid question. Sorry. Obviously, classpath cvs now depends on gconf, which depends on something called ORBit that I have never heard of, and that I don't have. Well, building with --disable-gconf-peer now. (Another undocumented switch, but I am getting better at grepping configure scripts.) Unfortunately, Google returns thousands of unrelated links for ORBit and only unuseable links for the search ORBit-2.0. So, where do I find this? Do I really want it? (for linux x86) Best, Norman (BTW, the gconf home page is no help either, it still links to 1.2.x instead of 2.14.x ...)
[Bug awt/27947] Graphics2D buglet with rotated text
--- Comment #3 from hendrich at informatik dot uni-hamburg dot de
2006-06-19 10:03 ---
(In reply to comment #2)
How does it rotate the text? I'm not seeing any problems when using
Graphics2D.rotate().
Could you run jfig3.jar and confirm that creating rotated texts works for
you? This would probably indicate a problem with my freetype or my fonts.
http://tams-www.informatik.uni-hamburg.de/applets/jfig/archive/jfig3.jar
1. java -jar jfig3.jar
2. Load the attached .fig file (fonttest.jar) - this segfaults for me.
1. java -jar jfig3.jar
2. Click the T (text mode) button on the left
3. Select one of the fonts via the font button on the bottom.
(Helvetica and Courier work on my system, Times does not).
4. Click the rotation angle button a few times (rightmost button on the
bottom attributes control panel) to select a non-zero rotation angle.
5. Click the left mouse button anywhere on the drawing canvas to place the
text object.
6. Type some text (including digits and special chars etc) and verify that
it is rotated.
The relevant code looks like this, where createCompoundTransform calls
preconcatenate:
...
AffineTransform tmpTrafo =
FigTools2D.createCompoundTransform( origTrafo, trafo );
tmpTrafo.translate( basePoint.x,
basePoint.y );
tmpTrafo.rotate( -attribs.fig_angle );
tmpTrafo.translate( left, 0 );
g2D.setTransform( tmpTrafo );
if (s.length() 0) {
g2D.setColor( attribs.lineColor );
g2D.setFont( font );
g2D.drawString( s, 0, 0 );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27947
___
Bug-classpath mailing list
Bug-classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/27947] Graphics2D buglet with rotated text
--- Comment #4 from hendrich at informatik dot uni-hamburg dot de 2006-06-19 10:05 --- Created an attachment (id=11696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11696action=view) figure file with rotated text objects -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27947 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: gconf needs ORBit?!
Hello Roman, thanks for your quick reply. Orbit is usually installed as part of Gnome. Of which gconf is the configuration management. So if you have gconf you usually also have Gnome and with it you'll have Orbit. OK. So far, I only have those parts of gnome required to building classpath. So much for my priorities :-) classpath configure now requires gconf = 2.11.2: ./configure --with-jikes --disable-plugin --prefix=/opt/classpath [...] checking for gconf-2.0 = 2.11.2... Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gconf-2.0' found while building gconf 2.11.92 fails with ./configure No package 'ORBit-2.0' found configure: error: Package requirements (gmodule-2.0 = 2.7.0 gobject-2.0 = 2.7.0 ORBit-2.0 = 2.4.0) were not met. and building a fresh gconf 2.14.0 fails with: ./configure checking for DEPENDENT... Requested 'glib-2.0 2.9.0' but version of GLib is 2.8.6 configure: error: Package requirements (glib-2.0 2.9.0 gmodule-2.0 = 2.7.0 gobject-2.0 = 2.7.0 ORBit-2.0 = 2.4.0) were not met: I don't use GNOME. Seems like --disable-gconf-peer is the way to go. What are the gconf peers supposed to do anyway? Thanks, Norman
[Bug swing/28061] New: JTree issues and regressions
At the moment, the state of JTree is much worse than some time ago... Run the free swing demo and select tree demo. 1. clicking on the switches does nothing. It should expand/collapse the corresponding subtree. 2. double-clicking an intermediate node correctly expands its subtree, but double-clicking again does not collapse the subtree. As a result of 1. and 2., we can never collapse a subtree again. 3. clicking the text label a node correctly selects that node, but double- clicking the label of an node does nothing. The reference implementation expands/collapses the subtree of an intermediate node (and users will expect this). 4. The JTree ignores the cursor-key navigation: cursor-up and -down should move one node up and down, cursor-right and cursor-left on an intermediate node should expand/collapse the subtree. This was working sometime ago. 5. doesn't look that nice (switches just ugly, a little too much spacing). 6. scrollPathToVisible( treepath ) does not work. I also attach the first version of a class, whose more polished version might make it into the free swing demo later on... JTree on the left, with lots of nodes in it (repainting slow because of the JTextArea). -- Summary: JTree issues and regressions Product: classpath Version: 0.92 Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: roman at kennke dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28061 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/28061] JTree issues and regressions
--- Comment #1 from hendrich at informatik dot uni-hamburg dot de 2006-06-16 14:50 --- Created an attachment (id=11680) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11680action=view) testcase A simple testcase that embeds JTree inside a JSplitPane, with quite a few nodes. Scrolling the tree works fine, but subtrees can only be expanded, never collapsed. Will add new event handling (node selection, scrollPathToVisible, etc.) later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28061 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/27917] Massive memory leak in Graphics2D image operations
--- Comment #9 from hendrich at informatik dot uni-hamburg dot de 2006-06-08 12:25 --- (In reply to comment #8) This seems to be a deadlock happening when the HideCursorManager sets the cursor at some inconvenient time. I haven't debugged it fully yet. Good catch! This sounds very possible. When I tried gdb on this, I just got lots of waiting threads, but didn't notice any of the cursor hiding stuff. It probably deserves its own bug report. Is there an easy way to disable the HideCursorManager? Not yet... (it is probably easiest to uncomment all setCursor calls in Niffler.java). I hope that get/setCursor is considered a thread-safe AWT operation. Using SwingUtilities.invokeLater would probably not help, or would it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27917 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/27929] New: RoundRect2D buglet
Another corner-case bug: the rendering of rounded rectangles is broken when the corner radius gets large (i.e. larger than the width/height of the rectangle itself). The JDK falls back to a kind of ellipse in those cases. See attached screenshots for a few examples rendered with cacao+classpath and JDK 1.4.2. -- Summary: RoundRect2D buglet Product: classpath Version: 0.92 Status: UNCONFIRMED Severity: minor Priority: P3 Component: awt AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27929 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/27917] New: Massive memory leak in Graphics2D image operations
My image viewer application shows a massive memory leak when running on jamvm with classpath cvs (2006.06.06) - about 10..30 MBytes of memory per medium-sized image. Goto http://tams-www.informatik.uni-hamburg.de/personal/hendrich/niffler/ and download niffler.jar and optionally the sources. Run the jar and specify the name of a directory with lots of images in it: jamvm -jar niffler.jar /home/hendrich/images/ The app should start up now (note that it also might just crash immediately after the first repaint; jamvm just hangs) and displays the first image. Move the mouse over the image, activate the popup menu and deselect popup thumbnails enable thumbnails, because creating the thumbnails may take a long time. Open the popup menu and select popup slideshow start slideshow (linear) or type F9. Optionally, type i or select popup slideshow half interval to reduce the delay between images. Observe memory consumption... I have no simple testcase yet, because some image operations seem to happen asynchronously. I suspect that the loaded images are never garbage-collected. (It also might be the scaled image drawImage(x y w h x y w h), but this seems to work in my circuit simulator.) -- Summary: Massive memory leak in Graphics2D image operations Product: classpath Version: 0.92 Status: UNCONFIRMED Severity: normal Priority: P3 Component: awt AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27917 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Build failure: mozilla-plugin
Hello Tom, Try --disable-plugin. oops... ok, works. Thanks. Guess I should have grep'ed for plugin instead of mozilla in ChangeLog*. Perhaps a better error message is in order? - Norman
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #22 from hendrich at informatik dot uni-hamburg dot de 2006-03-10 10:17 --- Subject: Re: Graphics.fillRect extremely slow Please disregard the numbers in Comments 18 and 19. Because of a bug in GNU Classpath's build machinery (PR 26623), I was testing the same patch both times. Here are the actual results for GCJ: one bug report almost always triggers the next ;-) I think these results are pretty conclusive. yep. Thanks for fixing this; applications using lots of drawing should run much faster now. - oneslime.net hardly flickers at all but feels sluggish. - oneslime.net flickers badly but is fast and playable - oneslime.net is unplayably choppy Do you have the source code for oneslime? I tried to look at the source code, but failed to find a download. If you don't have the source code, I am not sure that oneslime is the best reference application for gcj/classpath - except for its historical value of being the first applet/game ever running with classpath, of course. I have received (mild) flak on gcj/classpath lists for using non-open-source apps as tests myself... Using javap on the class files shows that there is a paint() method, but no update() method. The flickering indicates that oneslime doesn't use its own double-buffering. Therefore, the lack of update() is a strong indication of a broken design - prone to flicker. Perhaps we can find another reference app for testing and benchmarking animations? - Norman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #11 from hendrich at informatik dot uni-hamburg dot de 2006-03-07 13:15 --- Created an attachment (id=10981) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10981action=view) testcase with animation based on AWT The AWT variant of my previous Swing-based GameOfLife testcase. (Both the JDK and JamVM+classpath show extreme flickering, as no double-buffering is used.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #12 from hendrich at informatik dot uni-hamburg dot de 2006-03-07 13:27 --- As an experiment, I rewrote the Swing-based animation to a pure AWT-based animation (without double-buffering). I tried running with the JDK and jamvm+classpath (with and without the gdk_flush()). Observations: * the animation shows horrible flickering with the JDK and with classpath: all fillRect() calls are done directly on on-screen buffers. (Obviously, I forgot that double-buffering had to be done manually in the AWT...) * with the gdk_flush() calls after each fillRect(), jamvm+classpath runs even slower than the Swing version. One can literally watch jamvm painting individual rectangles. (The Swing RepaintManager seems to do a good job to coalesce repaints). * jamvm+classpath does NOT call update() but only paint(). This seems wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #6 from hendrich at informatik dot uni-hamburg dot de 2006-03-06 08:51 --- Created an attachment (id=10974) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10974action=view) improved testcase with frames/second counter -- hendrich at informatik dot uni-hamburg dot de changed: What|Removed |Added Attachment #10925|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26594] AWT repaint fails to call update() for Lightweights
--- Comment #1 from hendrich at informatik dot uni-hamburg dot de 2006-03-07 13:48 --- Created an attachment (id=10982) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10982action=view) testcase to demonstrate the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26594 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #13 from hendrich at informatik dot uni-hamburg dot de 2006-03-07 13:53 --- Created an attachment (id=10983) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10983action=view) improved AWT-based testcase An improved version of the testcase submitted a few minutes ago. I finally remembered how flicker-free AWT-based animations were supposed to work via update() and paint(). Unfortunately, this uncovered another buglet, #26594... -- hendrich at informatik dot uni-hamburg dot de changed: What|Removed |Added Attachment #10981|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #5 from hendrich at informatik dot uni-hamburg dot de 2006-03-06 08:49 --- Subject: Re: Graphics.fillRect extremely slow Hello Tom, Can you try commenting out the call to gdk_flush() in Java_gnu_java_awt_peer_gtk_GdkGraphics_fillRect? Done. The animation runs mucher faster without the gdk_flush calls. On my system with classpath cvs 20060228 and jamvm, the difference is about 3 repaints/second (with gdk_flush) vs 12 repaints/second (without gdk_flush). I did not test with gcj again, because I did a make clean in my gcc build directory, and I do not want to wait for another bootstrap. Sorry. Repainting seems smooth and correct without the gdk_flush() calls, but it would be difficult to spot bugs in my GameOfLife/FillRect demos anyway. Note that I have changed the demo slightly to include an actual frames/second count. This is necessary, because classpath currently drops or coalesces a lot of repaints. So... I guess we should take out all the gdk_flush() calls from the several drawXXX and fillXXX methods in GdkGraphics.c, and just use one single gdk_flush() (if at all) just before repainting a component? - Norman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: ANN: image viewer
Hello Christian, I tested it with CACAO and it works, but it's not blazingly fast :-) Thanks. I had some hope that a JIT compiler would help a bit, but apparently not... still, at least on my system, image loading under JDK 1.5.0 is almost twice as fast as JDK 1.4.2, and JDK 1.6 beta is a little faster again. I guess Classpath will evolve as well. And there is a problem when cairo is enabled: [...] Anything i should debug? This is PR24211, submitted (almost) four months ago. There are also PR24116, PR24099, PR24349, and a few others to be fixed before Graphics2D becomes useable. That is why I asked about the state of the Java2D rewrite... - Norman ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
ANN: image viewer
Hello all, a while ago Mark persuaded me to re-release my simple image viewer application as open source, especially as several parts of it already accompanied my Swing-related bug reports... I finally found the time to clean-up the sources a bit, and I also added thumbnails support. This is not a Gimp, not even a Picasa, but I still like it to view my images because the mouse-dragging lets me scroll quickly to areas of interest in the magnified images: http://tams-www.informatik.uni-hamburg.de/personal/hendrich/niffler The application expects the image directory name as its first argument; without explicit parameter (e.g. when using webstart) the viewer will search your home directory for images. Depending on the number of files lying around there, this can take some time... If necessary, just use the popup-menu and select another image directory. jamvm -Xmx256m -jar niffler.jar /home/hendrich/images/ I only tested with classpath-0.20 under jamvm (and different JDKs). It kind of works, but scrolling is still a little too slow for a good user experience. Thumbnails support is very experimental, so please report bugs. If anyone has time to test this with a faster VM (like cacao or gcj), please let me know the results. If anyone wants to add this to the 'free Swing apps' page, please do... - Norman BTW: any news about the big Java2D rewrite? --- Additional technical info for Swing fans and developers: As usual, the program GUI has the directory-tree (explorer) on the left, thumbnails on the top, and the image in the center (rather, bottom-right). Using two custom components (ImageCanvas and ThumbnailsPanel) and a JTree embedded in three JScrollPane's in two nested JSplitPane's, and a rather large nested JPopupMenu, the program tortures the free Swing pretty badly... it basically works, but there are still repainting bugs all over the place. Performance-wise, loading and displaying most JPEGs works fine when using the (default) loadImageViaAWT method. Image drawing seems a bit slow, but still acceptable on the main image canvas. Scrolling is too slow to be fun. Expanding/collapsing subdirectories in the JTree often fails to notify the JScrollPane, so that the scrolling for the tree is broken. Note 1: my first version of ThumbnailsPanel would request an image drawing operation for every thumbnail without Graphics.clipRect test. This version ran 15000 times slower on classpath-0.20/jamvm than on JDK 1.5.0 on a directory with 800 thumbnails, probably because the JDK drawImage() method internally checks the clipRect and returns quickly if outside. The current version of ThumbnailsPanel.paintComponent() includes its own clipRect test, which has little effect on the JDK, but makes classpath useable. Note 2: thumbnail creation is pretty slow, because the source images is first loaded, rescaled, and then written. Unfortunately, ImageIO is unable to access the EXIF previews embedded in most JPEGs and TIFFs. Note 3: once the app is running, try switching to javax.imageio instead of the AWT image loading: popup-menu - options - load images via ImageIO. I predict you won't like the resulting performance... ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
[Bug swing/24651] JMenu layout problem with nested menus
--- Comment #33 from hendrich at informatik dot uni-hamburg dot de 2006-01-20 11:37 --- Subject: Re: JMenu layout problem with nested menus Sorry, I can't confirm that the menus are that slow. But you are right, this might be related to the underlying image beeing redrawn. Maybe I just don't have a big enough image to see such performance issues. Could you open a new bug for this performance issue and attach an image with which you see the slow behaviour? Please assign this new bug to me. I'll close this bug now. OK. I agree that image rendering is the probable cause of the performance problem... I recently added 'thumbnails' support to my image viewer application, and redrawing the ThumbnailsPanel is incredibly slow in Classpath - I measured a factor of 15000 slowdown when running under Classpath+Gtk compared to JDK 1.5.0 :-( I promised Mark to prepare a nice open-source licensed version of the code, and I will submit new bug reports when this is done (soon). - Norman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24651 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/24890] New: NPE in
-- Summary: NPE in Product: classpath Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24890 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/24890] NPE in PlainDocument.insertString
--- Comment #1 from hendrich at informatik dot uni-hamburg dot de 2005-11-16 12:32 --- to whom it may concern: I am getting the following NPE when running one of my test apps with classpath cvs head (2005.11.16) on jamvm 1.3.2 linux-x86: java.lang.NullPointerException at javax.swing.text.PlainDocument.insertString (PlainDocument.java:238) at javax.swing.text.AbstractDocument.replace (AbstractDocument.java:709) at javax.swing.text.JTextComponent.setText (JTextComponent.java:977) at hades.gui.JStatusPanel.setFilename (JStatusPanel.java:78) ... This calls JTextComponent.setText(null), which works fine on the JDKs... I guess we need an additional null check here. - Norman -- hendrich at informatik dot uni-hamburg dot de changed: What|Removed |Added Summary|NPE in |NPE in ||PlainDocument.insertString http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24890 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/24651] JMenu layout problem with nested menus
--- Comment #28 from hendrich at informatik dot uni-hamburg dot de 2005-11-10 17:06 --- Could you test this again Cvs update done. For this test, I did run imageviewer with the '-noflicker' option, which should disable the JTree updating and painting and the JTree-related problems. Showing the menu indeed seems a little bit faster, but I am pretty certain it is much slower than it was in classpath 0.18. Is there an easy way to trace what JComponents receive repainting requests (clip-regions included)? (Note: Image loading and scaled image drawing itself should be fast enough, and the image viewer was surprisingly useful with 0.18 under jamvm. For example, image resizing was almost instantaneous - minus the scrolling, which didn't work at all back then.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24651 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/24651] JMenu layout problem with nested menus
--- Comment #11 from hendrich at informatik dot uni-hamburg dot de 2005-11-07 16:22 --- Sorry Lillian, I am still not happy with JPopupMenu... The size of nested submenus seems not to grow anymore after your last fix, but now the initial layout of lightweight popups is broken. I got the same effect a few times when I first submitted PR24651, but now it seems reproducable. Note that if I activate the popup menu near the application boundary to enforce a heavyweight popup, the popup appears and the layout is ok afterwards!!! Try running the new testcase PR24651b with the JDK and jamvm+classpath. You should see a popup, but this seems to be empty right now. Last weeks test showed that the menu items were there, but (partially or totally) shifted out of the popup menu itself. -- hendrich at informatik dot uni-hamburg dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24651 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/24651] JMenu layout problem with nested menus
--- Comment #12 from hendrich at informatik dot uni-hamburg dot de 2005-11-07 16:23 --- Created an attachment (id=10164) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10164action=view) testcase to show empty popup -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24651 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/24651] JMenu layout problem with nested menus
--- Comment #5 from hendrich at informatik dot uni-hamburg dot de 2005-11-03 15:32 --- Created an attachment (id=10126) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10126action=view) testcase to demonstrate the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24651 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Mauve results
Hello Mark, hello David: Mark Wielaard wrote: All in all not too bad. I'll try and analyze (and hopefully fix the few non-free-swing regressions). I do worry a bit about the fact that JList doesn't seem to scroll anymore (see my previous email about the FreeSwingTestApps). There has been a lot of progress with FreeSwing, and I know our JLists worked much better then they do now. David Gilbert wrote: I'd be interested to know if anyone is actually using the JFileChooser in a real application at present. When I first tried it, it was only just usable. Last time I looked, I think the JList scrolling problem had rendered it useless. I would _like_ to use JFileChooser... but the JList problem simply makes this useless indeed atm. (For testing, just try to open the last file in a directory with more than a few dozen files). --- Over the weekend, I finally tried to track down and isolate the scrolling bugs that make my test application (JImageViewer) unuseable with current classpath cvs due to excessive flickering. I strongly suspected JScrollPane and friends, but several hours of testing revealed that JScrollPane with JViewport and Scrollable finally work more or less as they should - at least for my testcases. (There remains a clipRect issue, but different versions of the JDK disagree on that one, too.) The flickering turned out to be due to JTree requesting useless revalidates (with wrong sizes). I have not submitted a bug report for that yet because using JTree in a JScrollPane is completely broken anyway, and we already have a bug for it. Bug 24145 is claimed to be invalid, but should be revisited. IMO, Fixing the Scrollable behaviour of JList and Jtree would make a big step towards real-world-application-compatibility of Free Swing. - Norman ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
classpath+mauve
Hello David and Audrius, first of all, thanks for your answers to my mauve-setup question(s). I tried the MakeTestClassList program, which seems to work fine. However, after spending another few hours trying to get the whole testsuite running, my worst fears are confirmed... To summarize: * writing new testcases is easy * running individual testcases is easy (from the shell or eclipse) * running parts of the testsuite via an index file works. * BUT there is no easy way to run the whole testsuite. A developer first has to create a custom list of exclusion testcases, before running the remaining fraction of the testsuite... Despite David's nice program, command line parameters, and exclusion testcase lists, I did not manage to run the whole testsuite reliably against today's classpath CVS. After passing some tests, jamvm encounters a test that throws some unexpected exception, runs into a stack-overflow, or complains about an IllegalStateException in loadClass(). In all cases, gnu.testlet.runner.Mauve does not run to the end, and the user doesn't even get the summary of test results. This basically leads to the situation that a developer needs to run the testsuite, try to understand the last error, remove the problematic test question from the list of testcases, and re-run. I tried this from scratch without David's exclusion list, but stopped after the first 20 iterations of this (with no end in sight). I then proceeded to remove larger chunks of the tests, and finally got a test report - but this in turn means that many tests were never run at all. --- The current all-testcases-at-once model used by gnu.testlet.runner.Mauve is not robust enough to survive all tests, while the opposite strategy of running each test in a new VM via (Simple)TestHarness is extremely wasteful due to the VM initialization overhead. Perhaps we could switch to a two-level model, where an outer process watches the progress of the inner runner process, and restarts the inner process whenever this crashes or deadlocks? Also, a test that doesn't compile should be marked as FAIL instead of stopping the testsuite to run at all... - Norman PS: a matrix of today's mauve experiments: * mauve+jdk1.5.0 with 'make check': doesn't even compile * mauve+jdk1.4.2 with 'make check': works, but subset of tests only * mauve+jdk1.4.2 with 'ant': doesn't even compile * mauve+jdk1.5.0 with 'ant': doesn't even compile * mauve+classpath+jamvm+jikes: compiles, but crashes on lots of testcases ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath+mauve
Not true. I just use the batch_run utility to run them all. I know that Mark uses this too. When I first tried the script, every test would FAIL... looking at it again I see this is simply due to the hard-coded path to glibj.zip. After changing the path, the script works. Still, the script does incur a single compilation and a VM initialization per testcase, and runs MUCH slower than gnu.testlet.runner.Mauve. Thanks for the tip. Problem solved, testsuite running (crawling) now. - Norman ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
classpath+jamvm+mauve Howto?
Hello all, [I recently checked out Mauve CVS with the good intention of first running the testsuite, learning from the existing testcases, and then converting my own bug-report testcases into some nice Mauve regression tests.] Unfortunately, running Mauve under classpath+jamvm is less fun than I expected. Running the default make check: * works fine with JDK 1.4.2 (129 fails, 6341 tests total), * while JDK 1.5.0 dies with a compiler error: gnu/testlet/java/math/BigInteger/compareTo.java:79: compareTo(java.math.BigInteger) in java.math.BigInteger cannot be applied to (java.lang.Integer) a.compareTo(new Integer(1)); * and classpath with jamvm simply crashes, with make exiting with 'error 139' or jamvm dying with OutOfMemoryExceptions. So: (1) Can anyone please provide some feedback whether mauve+classpath+jamvm is supposed to work out-of-the-box? If it is not, we should somehow tweak mauve to make running the testsuite easier. It will be very hard to convince developers to run the mauve tests at all, if this requires a lot of extra effort. Given that many people seem to use jamvm for classpath hacking, I guess jamvm would also be useful as a 'reference VM' for mauve. (2) If anyone has a current list of unsupported tests and tweaks to get Mauve running with jamvm, please post them... A list of XFAILS would also be nice, because I have no idea whether some tests (like the korean? locale tests) are expected to pass or fail. I would also appreciate a short howto or command lines for the mauve configure and make check scripts, including magic options like initial and maximum memory sizes, etc. About Mauve: (please excuse me for asking this here, but I guess that many more people are subscribed to the classpath mailing list than the mauve-discuss list, and one question should not produce to much noise): (3) several of the GUI tests leave their windows lying around... is this intentional or just an oversight? (I did run the tests on my normal desktop X server, not the extra hidden test X server) (4) A google search tells me that make complains of 'error 139' when the C compiler aborts, but I don't know how this can happen in the context of Mauve... (5) Are the results linked from the classpath homepage really the best we can do? http://www.object-refinery.com/classpath/mauve/report/ (6) How do I enable all 32157 tests listed in the above report, when the default cvs checkout (see above) only runs 6341 tests with the JDK? - Norman ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Swing (more screenshots)
Hello all, a while ago I made myself some enemies complaining about the AWT/Swing support in gcj (http://gcc.gnu.org/ml/java/2005-05/msg00052.html). Back then, I was really frustrated about obscure compiler bugs in gcj being fixed within minutes, while even small test programs like many of the Swing-trail examples from the Java tutorial would crash... Since then, I swiched from testing gcj+classpath to jamvm+classpath. Overall, the progress with Swing is really astonishing, despite a few drawbacks due to added functionality (like the accessibility stuff, better plaf support, and the repainting refactoring). --- Perhaps submitting bug reports with testcases made all the difference? Some days during the last weeks, it really felt like I had three or four people working just for me: thanks Lillian, Roman, Tony, and Tom F. Naturally, thanks to all the other AWT and Swing hackers, too. I would submit a few bug reports in the morning from Hamburg, and fixes started to come in from all over the world the same day. That is quite different from my experience with bug reports at Javasoft, where nothing except the autoreply would ever happen... To honor all the good work, I created a few screenshots from my test applications, including some advanced Swing stuff. Lacking a website for this, I decided to submit another pro-forma bug report and attached the images. That way, a snapshot of the classpath Swing status as of 2005.10 will remain online: gcc.gnu.org/bugzilla/show_bug.cgi?id=24256 --- I would have liked to include some Graphics2D stuff, but unfortunately this doesn't work at the moment (actually worse than 2 months ago). I also cannot run many real-world applications, but the set of real show-stoppers in my own test applications is pretty short already. Sorted by relevance, my personal wishlist looks like this: (1) fix JScrollPane and JViewport (2) make JTextField and JTextArea more robust (3) implement the missing bits of Graphics2D (fix segfaults) (4) fix JFileChooser (and make it look pretty) As most 'complex' Swing components like JTable, JTree, JTextArea are usually embedded in a JScrollPane (or use one like JFileChooser), the JScrollPane issue is especially annoying. There are at least two open bugs, but nobody seems to be working on it. - Norman ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug awt/24211] New: Another Graphics2D segfault
With Graphics2D enabled, one of my test apps dies with the following segfault (classpath cvs head 2005.10.05, jamvm 1.3.2, linux-x86, GTK 2.4, cairo 0.5.1). I have no small testcase yet... does anybody know an open-source application that uses RenderingHints (BILINEAR and ANTIALIASING)? Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 147466 (LWP 16307)] cairo_pattern_set_filter (pattern=0x0, filter=CAIRO_FILTER_FAST) at cairo-pattern.c:489 489 if (pattern-status) (gdb) where #0 cairo_pattern_set_filter (pattern=0x0, filter=CAIRO_FILTER_FAST) at cairo-pattern.c:489 #1 0x4483628c in Java_gnu_java_awt_peer_gtk_GdkGraphics2D_cairoSurfaceSetFilter Unlocked (env=0x8061794, obj=0x4106d7f8, filter=1) at gnu_java_awt_peer_gtk_GdkGraphics2D.c:1965 #2 0x44836330 in Java_gnu_java_awt_peer_gtk_GdkGraphics2D_cairoSurfaceSetFilter (env=0x0, obj=0x0, filter=0) at gnu_java_awt_peer_gtk_GdkGraphics2D.c:1941 #3 0x0805d875 in callJNIMethod (env=0x8061794, class=0x0, sig=0x8070a10 (I)V, ret_type=0, ostack=0x83b0c60, f=0x44836300 U\211åSè|µÿÿ\201ÃK\002\002, args=2) at dll_md.c:64 #4 0x0804e931 in callJNIWrapper (class=0x0, mb=0x82301e4, ostack=0x0) at dll.c:325 #5 0x08051856 in executeJava () at interp.c:2236 #6 0x0804f557 in executeMethodVaList (ob=Variable ob is not available. ) at execute.c:66 #7 0x0804f5f9 in executeMethodArgs (ob=0x0, class=0x0, mb=0x0) at execute.c:38 #8 0x0805b251 in threadStart (arg=0x839a510) at thread.c:257 #9 0x4002dc60 in pthread_start_thread () from /lib/libpthread.so.0 #10 0x4002dcdf in pthread_start_thread_event () from /lib/libpthread.so.0 #11 0x4018eb77 in clone () from /lib/libc.so.6 -- Summary: Another Graphics2D segfault Product: classpath Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: awt AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hendrich at informatik dot uni-hamburg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24211 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/23558] JComboBox problems (including VM crash)
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-09-02 08:45 --- Subject: Re: JComboBox problems (including VM crash) Hello Thomas, [Bug swing/23558] I can't reproduce this with GNU Classpath HEAD and jamvm 1.3.2. Can you retry with JamVM 1.3.2? I'm assuming you're running on Linux x86? Yes, basically SuSE 8.2 with lots of updates (current GTK, cairo, gcc, auto-tools, etc). Admittedly, the JComboBox of current Classpath CVS HEAD under jamvm 1.3.2 survives a bit longer than two weeks ago. However, after twenty or so 'random' clicks iterations it still dies: java/xxx /opt/jamvm/bin/jamvm -mx64m PR23558 The program '.' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 36641 error_code 3 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) I just start the application, select an item from the drop-down list, open the drop-down list again, click one of the up/down arrows, click an item, repeat. I should probably write a Robot-based test for this... Unfortunately, I still have no classpath-compatible version of gdb, so no meaningful backtrace... Also, can you file a separate Swing bug about selecting the JComboBox's first item? yes. Probably on Monday, though. BTW: thanks for fixing the slow image loading. Running my testcase works like a charm now, but my real app now dies before even loading the first image. Somebody must have broken Swing: /tmp /opt/jamvm/bin/jamvm -mx64m niffler.JImageViewer ~/.niffler java.lang.NullPointerException at java.awt.Dimension.init (Dimension.java:105) at java.awt.Container.preferredSize (Container.java:664) at java.awt.Container.getPreferredSize (Container.java:642) at javax.swing.JComponent.getPreferredSize (JComponent.java:1047) at javax.swing.ScrollPaneLayout.preferredLayoutSize (ScrollPaneLayout.java:265) at java.awt.Container.preferredSize (Container.java:661) at java.awt.Container.getPreferredSize (Container.java:642) at javax.swing.JComponent.getPreferredSize (JComponent.java:1047) at java.awt.FlowLayout.layoutContainer (FlowLayout.java:183) at java.awt.Container.layout (Container.java:519) at javax.swing.JSplitPane.addImpl (JSplitPane.java:340) at java.awt.Container.add (Container.java:292) at javax.swing.JSplitPane.setLeftComponent (JSplitPane.java:698) at javax.swing.JSplitPane.init (JSplitPane.java:237) at niffler.JImageViewer.createGUI (JImageViewer.java:182) at niffler.JImageViewer.init (JImageViewer.java:114) at niffler.JImageViewer.main (JImageViewer.java:2491) - Norman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23558 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Qt-peers and AC_PROG_CXX
A dumb question about the classpath build infrastructure: Since the recent Qt-peers checkins, trying to build classpath CVS from scratch fails on my system (basically still a SuSE 8.2 with lots of updates): ... native/jni/qt-peer/Makefile.am: C++ source seen but `CXX' is undefined native/jni/qt-peer/Makefile.am: native/jni/qt-peer/Makefile.am: The usual way to define `CXX' is to add `AC_PROG _CXX' native/jni/qt-peer/Makefile.am: to `configure.ac' and run `autoconf' again. And indeed, if I uncomment the AC_PROG_CXX call in configure.ac, the build succeeds (actually, I moved AC_PROG_CXX to after AC_PROG_CPP). 1) Is there any deep reason why the AC_PROG_CXX test is commented out? 2a) If not, could somebody with write access please reinstate it? 2b) If yes, what magic auto* settings, shell settings, or auto* versions are required to pass the CXX tests? - Norman ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
