Hi Igor,
> Minimal changes are always good idea.
> However, we usually do not add new methods unless we actually use them.
> Not sure what's the best approach in this case.
Maybe we should give you the FontManager work first (it's not finished
yet, I have to test and fix on Windows first - this i
Il giorno mer, 15/10/2008 alle 01.43 +0400, Igor Nekrestyanov ha
scritto:
> Minimal changes are always good idea.
> However, we usually do not add new methods unless we actually use them.
> Not sure what's the best approach in this case.
>
> -igor
Hi Igor!
I agree, but these methods will serve a
Minimal changes are always good idea.
However, we usually do not add new methods unless we actually use them.
Not sure what's the best approach in this case.
-igor
Roman Kennke wrote:
Am i understanding this correctly and this adds new TrueType constructor
that is not used in the OpenJDK itself
> Am i understanding this correctly and this adds new TrueType constructor
> that is not used in the OpenJDK itself?
For now, yes. (I'm using this in my own FontManager implementation in
the JamaicaVM, to load fonts from ROM instead of files. But this
requires the FontManager refactoring in Cacio
Am i understanding this correctly and this adds new TrueType constructor
that is not used in the OpenJDK itself?
-igor
Roman Kennke wrote:
Hi there,
What do you think about this patch (see webrev link below)? Can we get
this into jdk7? It is very useful for me and I wouldn't like to maintain
Hi there,
What do you think about this patch (see webrev link below)? Can we get
this into jdk7? It is very useful for me and I wouldn't like to maintain
it myself...
Cheers, Roman
> http://kennke.org/~roman/truetypefrombuffer/webrev/
--
http://kennke.org/blog/
signature.asc
Description: Die
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
- 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
Hi Phil,
> - I think its probably peformance neutral - at least as can be
>detected in the SE JDK.
Yeah, that's what I found too. If anything, it becomes very little
faster, but that can also be normal jitter during testing.
> - It probably does increase perceived footprint although
>res
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 p
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 OpenJDK.
> It is required that fonts are present as files, and that all fonts are
> loaded via a File
Hi there,
I'm back from holiday now, and I think Phil is too. I'd like to have
another look at this proposal now, it is quite important for me. Any
other opinions from you, especially Phil?
Cheers, Roman
Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke:
> Hi there,
>
> I have a sma
Am Donnerstag, den 14.08.2008, 14:00 +0400 schrieb Igor Nekrestyanov:
> >> This is weird.
> >> I suggest to print out font names and find what is different. Perhaps
> >> we
> >> do have bug somethere in 7.
> >> -Dsun.java2d.debugfonts=true may also provide some details on files
> >> being opened.
This is weird.
I suggest to print out font names and find what is different. Perhaps
we
do have bug somethere in 7.
-Dsun.java2d.debugfonts=true may also provide some details on files
being opened.
I checked an older version that I have lying around here (from just
before Phil's font wo
Hi there,
> > One interesting note here: Everytime this program is run, it shows a
> > different number of fonts (around 285-302 fonts). On an OpenJDK6
> system
> > it constantly shows 360 fonts.
> >
> This is weird.
> I suggest to print out font names and find what is different. Perhaps
> we
Hi Igor,
> >> Quick tests are: run Font2DTest on system that has some really large
> >> ttf/ttc files.
> >>
> >> Write simple test that iterates through all available fonts and draw
> >> one
> >> or all glyphs to bufferedimage.
> >>
> >
> > I wrote a simple test program that gets an array o
Quick tests are: run Font2DTest on system that has some really large
ttf/ttc files.
Write simple test that iterates through all available fonts and draw
one
or all glyphs to bufferedimage.
I wrote a simple test program that gets an array of all fonts and gets
the baseline for all 0-0xf
... Here comes the promised stacktrace and example app.
Exception in thread "main" java.lang.NullPointerException
at sun.font.TrueTypeGlyphMapper.(TrueTypeGlyphMapper.java:62)
at sun.font.TrueTypeFont.getMapper(TrueTypeFont.java:1232)
at sun.font.FileFontStrike.(FileFontS
Hi Igor,
> Anyway, i promise i'll look into this in more detail as i get some
> spare
> time (that is really rare these days :()
Thanks alot.
> >> From the top of the head i'd sugegst to check impact of such change
> on
> >> performance and perceived
> >> footprint scanning large set of large
Hi,
Yep, Phil is the one who designed font management code.
I can't wait for Phil to come back and have a look at our redesign of
the FontManager related code :-) (Maybe it's not so bad that I am in
holiday then .. ;-) ). But this one here is not so much about
FontManager but more about th
Hi,
> Yep, Phil is the one who designed font management code.
I can't wait for Phil to come back and have a look at our redesign of
the FontManager related code :-) (Maybe it's not so bad that I am in
holiday then .. ;-) ). But this one here is not so much about
FontManager but more about the low
Yep, Phil is the one who designed font management code.
I remember there were some important reasons why callback-based approach
was introduced
but can not recall them right now.
From the top of the head i'd sugegst to check impact of such change on
performance and perceived
footprint scannin
Hi Roman,
just to let you know, the main font person (Phil)
is out on vacation until 26th I believe so you probably
won't get an answer before that..
Thanks,
Dmitri
Roman Kennke wrote:
Hi there,
I have a small problem with current implementation of fonts in OpenJDK.
It is requi
Hello again,
Maybe some code helps to illustrate what I want to do. Today I
implemented the most low-level pieces of it, i.e. changing TrueTypeFont
and Type1Font and the corresponding native code to read from
ByteBuffers. This works pretty well, and it turns out that the code gets
much simpler (lo
Hi there,
I have a small problem with current implementation of fonts in OpenJDK.
It is required that fonts are present as files, and that all fonts are
loaded via a FileChannel, not InputStream, because FreeType doesn't
support loading from a sequential-only stream. From my perspective as
embedde
25 matches
Mail list logo
