Re: HTML-Rendering engine written in Java?
Hi Clemens, XBrowser (http://xbrowser.sourceforge.net/) ist a Web Browser completely written in Java, so I guess it must contain a rendering engine. It is released under the SISSL licence. -Patrik - Original Message - From: "Clemens Eisserer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, September 13, 2003 9:55 PM Subject: HTML-Rendering engine written in Java? > Hi there! > > Does anybody know a useable html-rendering engine completly written > using Java and 100% free Software (e.g. GPL, LGPL)... > I want to port such a library from AWT/SWING to SWT. > > All libraries I found were proprietary, so they arent useful at all for > me :-( > > lg Clemens > > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath > > ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: HTML-Rendering engine written in Java?
Hi Patrik Reali ! XBrowser (http://xbrowser.sourceforge.net/) ist a Web Browser completely written in Java, so I guess it must contain a rendering engine. It is released under the SISSL licence. XBrowser is mostly based on SWING-Classes (also for rendeing / parsing) and is extremly slow, nearly unuseable :-( lg Clemens ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: HTML-Rendering engine written in Java?
> XBrowser is mostly based on SWING-Classes (also for rendeing / parsing) > and is extremly slow, nearly unuseable :-( > > lg Clemens Well, that means that with a port to SWT you could show just how much it speeds it up! -Avery ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: extended peers
Sascha Brawer <[EMAIL PROTECTED]> writes: > Brian Jones <[EMAIL PROTECTED]> wrote on Fri, 12 Sep 2003 08:58:29 -0400: > > >What parts of our code would rely upon having a ClasspathToolkit > >with the additional Font related stuff? > > The JavaDoc of the enclosed classes "ClasspathToolkit" and > "ClasspathFontPeer" explains the expected uses. > > Would those two classes be suitable for eventual inclusion into Classpath? > > Graydon, would this FontPeer be ok, or would you like to see things done > differently? In principle I like the direction, but I would make two changes to these interfaces: First, the font-related factory method on the toolkit should produce a ClasspathFontPeer, not a java.awt.Font. The factory method will be called *from* a java.awt.Font constructor in user code, thus has no opportunity to influence the identity of the Font object being constructed. Second, I think the ClasspathFontPeer should not be passed java.awt.Font objects as arguments to its methods. This practise implies an 'instanceof' operation, and (possibly failing) downcast on every operation, or at least some sort of hashtable lookup. Instead, I think the ClasspathFontPeer should hold state itself, or at least be the object identified with state (whether internal or external -- a singleton is still possible, just using static methods within a subclass keyed to the identity of the ClasspathFontPeer in question, not the Font). This approach is theoretically equivalent to yours, but saves the downcasting / hashing, and associated possibility of runtime failure. I figure a 1:1 relationship between Font and ClasspathFontPeer objects is likely anyways. Do you object to these suggestions? -graydon ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
[patch] fix to BufferedImage
Hi,
java.awt.image.BufferedImage has a small bug, where it assumes that
its sample model is a ComponentSampleModel when copying blocks of
pixels. This is not always true. The attached patch fixes this
problem.
ok to commit?
-graydon
2003-09-16 Graydon Hoare <[EMAIL PROTECTED]>
* java/awt/BufferedImage.java (setData): Support non-component
sample models.
(getData): Same.
--- java/awt/image/BufferedImage.java
+++ java/awt/image/BufferedImage.java
@@ -267,9 +267,17 @@
raster.createWritableChild(x, y, w, h, x, y,
null // same bands
);
-
-// Refer to ComponentDataBlitOp for optimized data blitting:
-ComponentDataBlitOp.INSTANCE.filter(src, dest);
+if (src.getSampleModel () instanceof ComponentSampleModel &&
+dest.getSampleModel () instanceof ComponentSampleModel)
+ // Refer to ComponentDataBlitOp for optimized data blitting:
+ ComponentDataBlitOp.INSTANCE.filter(src, dest);
+else
+ {
+// slower path
+int samples[] = null;
+samples = src.getPixels (x, y, w, h, samples);
+dest.setPixels (x, y, w, h, samples);
+ }
return dest;
}
@@ -540,9 +548,19 @@
raster.createWritableChild(x, y, w, h, x, y,
null // same bands
);
-
-// Refer to ComponentDataBlitOp for optimized data blitting:
-ComponentDataBlitOp.INSTANCE.filter(src, dest);
+
+if (src.getSampleModel () instanceof ComponentSampleModel &&
+dest.getSampleModel () instanceof ComponentSampleModel)
+
+ // Refer to ComponentDataBlitOp for optimized data blitting:
+ ComponentDataBlitOp.INSTANCE.filter(src, dest);
+else
+ {
+// slower path
+int samples[] = null;
+samples = src.getPixels (x, y, w, h, samples);
+dest.setPixels (x, y, w, h, samples);
+ }
}
public void setRGB(int x, int y, int argb)
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
