[OpenJDK 2D-Dev] Thoughts about font implementation
roman.kennke at aicas.com
Mon Sep 22 19:46:11 UTC 2008
Ok, here we have an improved version of the idea, that let's the
standard code path (using FileChannel etc) in and the default, and adds
a code path that uses direct byte buffers. I'm only adding this to
TrueTypeFont for now, should be good as a first prototype, and Type1
should be easy to add, as this uses direct buffers anyway.
I tested the alternative code path by putting some additional code in
the (old) constructor that makes a direct buffer out of the font file
and use that instead of using the channel. Works fine for me.
What else is needed to make this patch go into OpenJDK tree?
Am Donnerstag, den 18.09.2008, 14:26 -0700 schrieb Phil Race:
> I haven't really had time to review this in the depth it merits
> My high-level thoughts
> - Yes, its definitely makes the code simpler
> - I think its probably peformance neutral - at least as can be
> detected in the SE JDK.
> - It probably does increase perceived footprint although
> results will probably vary by platform and
> we'd need to see if people will accept that. I did what
> I hope is a reasonably fair comparison of the two approaches,
> reading all font files on my XP system takes mem usage up to 160Mb
> with the new approach, vs 37Mb with the existing approach.
> That's not a test doing rendering, just treating them as files and
> reading them all in and discarding the actual file data,
> although the mmapp'ed direct bytes are kept around as they would be
> in the actual JDK implementation.
> - There are some cases that need additional work here
> * T2K also, like any rasteriser will need to randomly access the
> so has similar code.
> * The new init() methods don't seem to use all their args.
> In particular the T1 font doesn't do anything with the buffer it
> just read
> * Want to make sure that this works well for the Font.createFont()
> The the only way the BB resources can be freed is via GC. So we
> have no timely
> way to release these resources,
> And on windows, you can't "delete" a file that's mmapped, so you
> to be able to know when GC has allowed NIO to free its map with
> before you can delete the file, otherwise we'd leave temp files
> on disk,
> which is something we've tried had to clean up.
> - Not thought about this much, but even if the above doesn't work out
> all the SE cases, there's probably no fundamental obstacle to
> a DBB path which can be optionally used.
> Roman Kennke wrote:
> > So, no more opinions on this proposed change?
> > /Roman
> > Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke:
> >> Hi there,
> >> I have a small problem with current implementation of fonts in
> >> It is required that fonts are present as files, and that all fonts
> >> loaded via a FileChannel, not InputStream, because FreeType doesn't
> >> support loading from a sequential-only stream. From my perspective
> >> embedded VM developer this is not very practical. Ideally I'd like
> to be
> >> able to embed fonts in the classpath (with the Jamaica VM you can
> >> a complete image of an application+VM+resources and don't need
> >> else on the target machine, sometimes not even a filesystem). I
> can't do
> >> that using the current approach in OpenJDK. I have some ideas how
> >> change it, and I think there are also some advantages for the more
> >> general OpenJDK community. Here's my plan which I'd like to
> >> - Change TrueTypeFont and all related classes (these are a lot) to
> >> from a (direct) ByteBuffer, instead of a file channel. FreeType can
> >> fonts directly from a memory buffer, this would make a lot of code
> >> easier (i.e. freetypeScaler.c wouldn't need these callbacks).
> >> - At a slightly higher level, don't pass FileChannels to
> TrueTypeFont to
> >> read from, but instead map the file, and pass the resulting buffer.
> >> not sure about all the OS level details, but I think it is possible
> >> the OS does some interesting optimizations here. For example, if
> the OS
> >> already has the font file open (for the desktop), this can be
> >> and should be faster than reading into a new buffer.
> >> - File.createFont(InputStream) could be changed to read from the
> >> into a memory buffer, instead of a temporary file.
> >> For me personally, this means that I could access the app+VM
> >> image directly using a (direct) ByteBuffer and pass that to read
> >> from the classpath, thus solving my problem.
> >> What do you think about this rough outline? Maybe you have other
> >> how to solve my problem? Would such a change have a chance to be
> >> accepted into OpenJDK mainline? (I'd try hard to avoid having to
> >> maintain a fork of the code.)
> >> Kind regards, Roman
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt
More information about the 2d-dev