[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
[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
[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
[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
[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
[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
[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
