[Bug awt/20630] GTK 2.8 peer Image and Graphics API reorganization
--- Comment #6 from sven at physto dot se 2006-05-17 00:56 --- I should update my previous comment: DataBuffers created by the user, i.e. the DataBuffer implementations in the public API do wrap true java arrays. However, when creating a BufferedImage on the JDK the corresponding DataBuffer is not one of the public implementations. And that most likely wraps a native bitmap. This seems like a good idea, and it's what I'm currently advocating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630
[Bug awt/16005] GridBagLayout resizes components incorrectly when weigthy value is set
--- Comment #2 from sven at physto dot se 2006-04-30 02:56 --- Is this fixed now? I can't quite see what the problem is with the test program? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16005
[Bug awt/16741] Toolkit.loadSystemColor unimplemented
--- Comment #2 from sven at physto dot se 2005-10-28 21:27 --- Can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16741
[Bug awt/20630] Image APIs should use BufferedImage exclusively
--- Additional Comments From sven at physto dot se 2005-08-04 05:04 --- (In reply to comment #2) Apparently I was wrong; DataBuffer does indeed wrap a true Java array. E.g. With the JDK, if a DataBuffer is constructed from a java array, changes in that array will be reflected in the DataBuffer. Same goes for the array returned by Databuffer.getData(). So this appears to be a bit of a conundrum. Perhaps DataBuffer could represent a *pinned* java array, with the databuffer constructor pinning the array from the native side and the destructor unpinning it? Is that legal? This won't help if the array pointer returned by JNI is a copy though. Problematic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630
[Bug AWT/19838] Repaint-Loop due to setBackground()
--- Additional Comments From sven at physto dot se 2005-06-02 16:46 --- Just commited a simple fix for this to Classpath CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/21882] New: Wrong Frame size if a frame has been created previously
See the demo. If a frame is created and thrown away, a second frame will have the wrong size. -- Summary: Wrong Frame size if a frame has been created previously Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: sven at physto dot se CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21882
[Bug AWT/21882] Wrong Frame size if a frame has been created previously
--- Additional Comments From sven at physto dot se 2005-06-02 17:28 --- Created an attachment (id=9016) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9016action=view) Testcase. Execute with an argument on the command line to trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21882
[Bug AWT/20630] Image APIs should use BufferedImage exclusively
--- Additional Comments From sven at physto dot se 2005-06-01 08:06 --- Ok, in light of my reworking of GtkImage, I should add some thoughts here: - GtkImagePainter is gone. GtkImage now does its own drawing, and wraps a GdkPixbuf. - ImageObserver use is pretty much elimated for GtkImage use now, although it should be reintroduced for animated gif support. This can probably be done nicely within the GtkImage class without involving other stuff. - GtkImage should probably be kept to a small extent even in the future, if only for internal Component usage. (I'm thinking about animated-gif support for ImageIcon buttons for instance) - Component and Toolkit.createImage can create two kinds of images, either from a file (essentially immutable), and drawable (createImage(int, int)). The latter should definitely become a BufferedImage with Graphics2D. (as BufferedImage is drawable and its getGraphics() method should return a Graphics2D object) The former should probably be implemented on top of ImageIO in the future. Although the question remains if that'll make things a bit too complicated for animated gifs? - the Graphics peer now supports drawing BufferedImages (although slowly) through the ImageProducer/Consumer interfaces. This should give us a chance to get BufferedImage working at least to some extent. Sketching out a BufferedImage strategy: - The goal is to draw BufferedImages and be able to draw *to* BufferedImages fast. That means no copying or converting pixel data on these operations. If we have to choose one, it should be the latter. Copying image data after every drawing operation would be costly indeed. - User-defined ColorModels are allowed. So the former goal can never be realized fully. Realistically, we should aim for the predefined BufferedImage types. - In other words, we need to differentiate our BufferedImage drawing code for the predefined types, and others. - Storing the image data in Javaland memory space will make data copying necessary, since it can be relocated by the VM. BufferedImage memory must be natively allocated then. - This makes me belive that wrapping these native memory buffers is what java.awt.image.DataBuffer is for. So our current implementation wrapping java arrays is wrong. - Currently, Cairo only seems to support RGB-24 and RGBA-32 color models. We really need it to support all predefined BufferedImage types. (or face copying and converting pixel data on every draw operation) - The easiest starting point for implementing all this should therefore be BufferedImage.TYPE_4BYTE_ABGR. - I still have no good idea how we should handle drawing to a BufferedImage with a user-defined color model and pixel storage. Although I'm not sure this is an important case either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630
[Bug AWT/17351] java.awt.color.ICC_Profile unimplemented
--- Additional Comments From sven at physto dot se 2004-11-10 22:11 --- Merged over from classpath now. Great! -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17351
[Bug AWT/18312] Component.createImage() doesn't clear bitmap
--- Additional Comments From sven at physto dot se 2004-11-10 22:12 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18312
[Bug AWT/16825] Bad results for QuadCurve2D.solveQuadratic
--- Additional Comments From sven at physto dot se 2004-11-09 23:22 --- This isn't a Awt or libgcj bug itself, but rather an effect of the extended-mode of FPU being the default leading to inconsistent results with 64-bit doubles. A suggestion for a 'fix' is to set the FPU to 64-bit double rounding for Java programs, since Java does not have a 'long double' type. This would both stricter and give more consistent results with other platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16825
[Bug AWT/18312] New: Component.createImage() doesn't clear bitmap
An image created with Component.createImage() is supposed to be filled with the default component background gray. Currently, it simply mallocs the pixmap data without initializing it, which is also a mild security flaw. Suggested fix is to do a fillRect() after creating the graphics context in GtkComponentPeer.java. An (faster) alternative would be to do a memset in the c method Java_gnu_java_awt_peer_gtk_GdkGraphics_initState__II. -- Summary: Component.createImage() doesn't clear bitmap Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: sven at physto dot se CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18312
[Bug AWT/18312] Component.createImage() doesn't clear bitmap
--- Additional Comments From sven at physto dot se 2004-11-05 19:52 --- Created an attachment (id=7481) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7481action=view) Suggested patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18312
[Bug AWT/17351] java.awt.color.ICC_Profile unimplemented
--- Additional Comments From sven at physto dot se 2004-10-29 17:57 --- Ok.. my initial implementation is done. The built-in Photo YCC color space is not implemented yet. Some more work will be needed to bring it up to 1.5.0 later, too. Please merge it over from classpath. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17351
