> > We usually don't have fontconfig on AIX and it would be nice if AWT
> > would still work even without fontconfig. There are also other ancient
> > operating systems without fontconfig like for example HP UX which are
> > not currently supported by OpenJDK but by commercial licensees of the
> >
ul only if fontconfig failed, or is incomplete. So we
> >> could
> >> 529 * remove this code completely and the consequences should be
> >> rare
> >> 530 * and non-fatal. If this happens, then the calling Java code
> >> can
> &g
Am Donnerstag, den 05.02.2015 um 19:52 +0300 schrieb Sergey Bylokhov:
> Hello, Roman, Phil.
> The fix looks fine except an absent documentation in new class and
> InternalError + 80 chars per line.
I added a class comment. I added a small msg to the internal error
explaining why it happens (what
Am Donnerstag, den 19.02.2015 um 15:25 +0100 schrieb dalibor topic:
>
> On 19.02.2015 13:50, Mario Torre wrote:
>
> > The code is part of an OpenJDK project, though, it's already the
> > existing Java rasterizer.
>
> It's not part of an OpenJDK Project - Project with an upper case 'P'.
> See ht
Am Mittwoch, den 18.02.2015 um 16:06 -0800 schrieb Phil Race:
> There have been brief internal exchanges every now and again for some
> substantial period
> of time (18 months at least) as to whether we should consolidate the
> various JDK client groups
> in openjdk. The client groups are conside
> > http://mail.openjdk.java.net/pipermail/awt-dev/2015-January/008819.html
> >
> > I got no reply, so I'm sending it here, maybe it's a better fit? ;-)
>
> font related discussions should go to 2d-dev.
> The change looks OK. But test it as much as
> you can. The previous re-factoring in JDK7
> ha
I already sent that patch to awt-dev for review, a while ago:
http://mail.openjdk.java.net/pipermail/awt-dev/2015-January/008819.html
I got no reply, so I'm sending it here, maybe it's a better fit? ;-)
Hello,
I am currently working on a port of AWT/Java2D to DirectFB (using
Caciocavallo [1] a
Hi Damon,
> Is anyone reading this list who is in a position to tell me if I'm even
> wrong? B^>
>From reading the snippets you posted here:
http://mail.openjdk.java.net/pipermail/2d-dev/2012-May/002496.html
I think you are right, RGBA and beyond is not possible using the
jpeglib.h that is in
Hi all,
Thanks Mario for bringing this up.
First of all let me explain what is Cacio and why we think it's useful.
In essence, it is an (somewhat) abstract implementation of AWT peers. It
implements all the AWT widgets by using Swing for painting and
event/logic processing. This reduces the burde
Ah and of course... maybe you should try to avoid using internal APIs to
begin with. What exactly are you trying to do with this?
Regards, Roman
Am Donnerstag, den 01.12.2011, 15:30 + schrieb Martijn Verburg:
> Thanks, that helps a bunch!
>
> On 1 December 2011 15:21, Roman Kenn
Hi Martijn,
we refactored the FontManager internal API, it's now:
FontManagerFactory.getInstance().getNewComposite() (or whatever other
FontManager static method it was before). There are a few methods that
have been moved to other classes, but this one is still available in the
FontManager inter
> Btw, on the other mailing lists they are also discussing about the warnings
> day, so I guess I'm not so early ;)
Congratulations, it's probably the first time in your life that you're
early ;-) Seriously, maybe this comes from the fact that today started 9
hours earlier in central Europe than
Hi Artem,
> > While working a bit on cacio, we just found some new nice addition to the
> > Toolkit code, like this one:
> >
> > public boolean areExtraMouseButtonsEnabled() throws HeadlessException {
> > GraphicsEnvironment.checkHeadless();
> >
> > return Toolkit.getDefaul
Hi Denis,
> The version in the webrev is the fastest yet, and it uses
> a class similar to the ScanlineIterator for the sorting
> (but now it iterates through pixel rows, not scanlines).
> Unfortunately this means that there still are two levels
> of intermediate storage (edges and crossings, ana
IIRC, libfontconfig is also fairly standalone and portable, so when it's
not there, it shouldn't be too hard to compile it.
A while ago I contemplated and started to implement fontconfig in pure
Java, which is not rocket science either, but then lost interest or time
or both.
Cheers, Roman
Am D
Hi Herve,
> I hope it is the correct list for this kind of problem. If not, don't
> bother to read the rest of the message ;)
Seems perfect.
> I am using OpenGL acceleration in a "soft real-time" Java program by
> using JOGL, drawing in an external OpenGL context (coming from a
> master C app w
Hi Mario,
> > What I'd like to have is a small test case that demonstrates exactly
> > this so I can follow the chain.
> I've uploaded a small test case, where only one font is tested, my
> original test case let you select the font from a combo box list with
> all the font installed, but becaus
Hi Phil,
> - Swing understands that there's no guarantee that all the pixels fit
>in the reported height of the line. I don't think you want to space
>out the text so much that you guarantee no glyph overlap.
No, that's not really the point. Swing assumes wrongly that all pixels
*do* fit
Hi Mario,
> > > ly = (jfloat) ROUND(FT26Dot6ToFloat(
> > > scalerInfo->face->size->metrics.height +
> > > bmodifier) + ay - dy);
> > >
> >
> > And here is the proposed webrev:
> >
> > http://cr.openjdk.java.net/~neugens/100134/webrev.02/
> >
> > As noted, this doesn
Hello,
> I want to hack into the sources of font rendering of openjdk, and I'm
> a bit confused now. So help me please understand how it works. Links
> are appreciated too.
>
> I read that freetype is used for fonts scaling, but after debugging it
> looks like freetype is used only to get font me
e.
>
> -Joe
>
> > Roman, please commit this to openjdk6
> > (or I can do it for you, if you prefer).
> >
> > Martin
> >
> > On Wed, Mar 3, 2010 at 12:33, Igor Nekrestyanov
> > wrote:
> >
> >> Fix is ok with me.
> >>
>
Phil, is it possible that these rounding effects are different in T2K
vs. FT? In this case, the rounding should probably be done in the font
backends altogether. However, I doubt I fully understand what exactly is
going on here. My understanding is that we need to round at least up to
the next full
> > The current fontconfig property files in OpenJDK:
> >
> > jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties
> > jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties
> >
> > are outdated. They pertain to Fedora Core 6 (released October 24
This is the fix for the deadlock problem in
SunGraphicsEnvironment/FontManager backported to OpenJDK6. It is
slightly different from the OpenJDK7 version due to the restructured
font manager, but the basic idea is the same: instead of sync'ing on 2
different lock objects (with the potential of ente
Changeset: 840601ac5ab7
Author:rkennke
Date: 2010-03-03 15:50 +0100
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/840601ac5ab7
6892485: Deadlock in SunGraphicsEnvironment / FontManager
Summary: Synchronize on correct monitor in SunFontManager.
Reviewed-by: igor, prr
! src/share/c
485/webrev.01/
I need at least another review (not sure if Igor needs to say 'go'
again?).
Thanks, Roman
Am Donnerstag, den 25.02.2010, 11:21 -0800 schrieb Igor Nekrestyanov:
> i am ok with this fix.
>
> -igor
>
> On 2/25/10 7:19 AM, Roman Kennke wrote:
> > Hi the
Hi there,
this patch fixes the deadlock in FontManager for OpenJDK7 that has been
reported repeatedly on this list. I have a testcase here (attached),
which I could prepare for jtreg, but it is not totally reliable and
depends on the system configuration (which and how many fonts
installed), not s
Changeset: 58d014485a29
Author:rkennke
Date: 2010-02-07 11:07 +0100
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/58d014485a29
6904882: java.awt.Font.createFont() causes AccessControlException if executed
with "-Djava.security.manager"
Summary: Perform FontUtilities initializatio
Am Mittwoch, den 03.02.2010, 11:55 -0800 schrieb Phil Race:
> looks fine.
Good! Needs another reviewer? Igor maybe, or Dmitri?
Thanks, Roman
>
> -phil
>
> On 2/3/2010 11:35 AM, Roman Kennke wrote:
> > I moved the FontPrivilege test into open. I did one small change
open that or add a new one but opening
> it would be best.
>
> -phil.
>
>
>
> Roman Kennke wrote:
> > This patches fixes bug #6904882. As suggested by Phil it puts the whole
> > static initializer in a privileged block, grouping the existing 4
> > smaller blocks into
Changeset: cedd0cdd5b9a
Author:rkennke
Date: 2010-02-03 10:02 +0100
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/cedd0cdd5b9a
6896335: GraphicsEnvironment.getDefaultScreenDevice() throws
UnsatisfiedLinkError in headless mode
Summary: Use local ge variable instead of localEnv fie
etter for various reasons.
>
> -phil.
>
> Roman Kennke wrote:
> > This is a relatively simple fix for 6896335. When I did the change to
> > GraphicsEnvironment initialization, I missed this small line that's only
> > executed in headless mode, leading to weir
Changeset: 7e8c77ae401a
Author:rkennke
Date: 2010-02-02 16:38 +0100
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/7e8c77ae401a
6888734: PIT: regression test fails when java.security.manager is enabled
Summary: Load FontManager instance in privileged block to avoid
AccessControlEx
> Looks ok to me except the copyright on the test should probably be 2010 now =)
Arg! I knew it!
http://cr.openjdk.java.net/~rkennke/6888734/webrev.04/
Now don't tell me I have to put 'Oracle' in there! ;-)
/Roman
>
>Dmitri
>
> Roman Kennke wrote:
> >
http://cr.openjdk.java.net/~rkennke/6888734/webrev.03/
Is this ok now to push?
Thanks, Roman
>
> Rest looks good to me.
>
> -igor
>
> On 12/7/09 12:12 PM, Roman Kennke wrote:
> > Hi Phil,
> >
> > Am Montag, den 30.11.2009, 13:37 -0800 schrieb Phil Race:
> >
>
Hi Phil,
Am Montag, den 30.11.2009, 13:37 -0800 schrieb Phil Race:
> Roman Kennke wrote:
> > I added the (previously closed) testcase, keeping it in the same
> > relative directory location:
> >
> > http://cr.openjdk.java.net/~rkennke/6888734/webrev.01/
> >
> &
closed just because no one got round to moving it to open.
> At least I don't see any reason it can't be opened up.
> Now would be a good time and it can be included with this
> changeset.
> Don't forget to tag it with this additional bug ID.
>
> -phil.
>
> Roman
I will add/open-existing regression test for that, just like I'll do for
the other fixes I sent today.
/Roman
Am Montag, den 30.11.2009, 20:52 +0100 schrieb Roman Kennke:
> This is a relatively simple fix for 6896335. When I did the change to
> GraphicsEnvironment initialization, I
This is a relatively simple fix for 6896335. When I did the change to
GraphicsEnvironment initialization, I missed this small line that's only
executed in headless mode, leading to weird exceptions...
http://cr.openjdk.java.net/~rkennke/6896335/webrev.00/
Ok to commit?
/Roman
Hi Phil,
> The fix looks fine to me.
Good. :-)
> One thing. The test is
> in closed just because no one got round to moving it to open.
> At least I don't see any reason it can't be opened up.
> Now would be a good time and it can be included with this
> changeset.
I'll do that.
> Don't forge
This patches fixes bug #6904882. As suggested by Phil it puts the whole
static initializer in a privileged block, grouping the existing 4
smaller blocks into one, and importantly including the offending
File.exists() call. This requires to make the static fields non-final.
http://cr.openjdk.java.n
Hi again,
is this ok for committing?
Thanks, Roman
Am Donnerstag, den 15.10.2009, 15:22 +0200 schrieb Roman Kennke:
> Hi there,
>
> Here's a fix for Bug#6888734. One regression test was failing with an
> AccessControlException in new FontManager code. We need to move
>
Looks ok to me too, but I don't think I have a say.. ;-)
/Roman
Hi there,
Here's a fix for Bug#6888734. One regression test was failing with an
AccessControlException in new FontManager code. We need to move
Class.forName() and newInstance() call into the privileged block. Webrev
here:
http://cr.openjdk.java.net/~rkennke/6888734/webrev.00/
Good? Comments?
/
Hi Christoph,
I have filed bug #6889147, it should appear shortly on bugs.sun.com.
This seems to be another problem in the Pisces renderer. It seems to be
valid both for OpenJDK6 and 7. I try to have a look as soon as I find
time.
Thanks, Roman
Am Dienstag, den 06.10.2009, 12:31 +0200 schrieb
Hi Christoph,
> When using setStroke, the pixel is displaced by one position
> I guess that it is a numeric rounding error in 2d.
Do you see that problem in OpenJDK6 or7 or both?
I will file a bug report ASAP and work on fixing the problem.
Thanks, Roman
Changeset: ccc36189f2a7
Author:rkennke
Date: 2009-10-05 23:12 +0200
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ccc36189f2a7
6887494: NPE in pisces Renderer
Summary: Only recreate crossings array, if there actually exists one before.
Reviewed-by: flar, tdv
! src/share/classes/s
Hi Jim,
I think you are right. I think the idea is to keep the array around to
avoid massive load on the GC. And if the array needs to be grown (i.e.
very rarely), it gets shrinked back to default size. So I would go with:
> Shouldn't it be "if (array != null && array.length > DEFAULT)"?
The u
Hi Dmitri,
>a comment about the test: would the bug reproduce if you just rendered
> into a
> BufferedImage? If so, no need for creating a frame and such.
Oh yes. Stupid me :-)
>Regarding the fix, it looks ok - but there are other places in the code
> where
> the 'crossings' is acces
Hi guys,
This patch here fixes the NPE in Pisces renderer as reported in:
https://bugs.openjdk.java.net/show_bug.cgi?id=100053
The webrev is here:
http://cr.openjdk.java.net/~rkennke/100053/webrev.00/
It basically adds nullchecks in the offending code. As far as I can see
this should be suffic
Hi Phil,
> > 6th round of the FontManager refactoring.
>
> Can I assume you changed nothing except what you call out here ?
Yep.
> In which case I'm fine except for one thing :
>
> >> WPathGraphics.java
> >>
> >> I see you moved the definition of textLayoutIsCompatible in here.
> >> Whilst its
Hi there,
6th round of the FontManager refactoring.
> you aren't using these import in sun.font.FontManager :
>30 import java.util.Locale;
>31 import java.util.TreeMap;
>32
>33 import javax.swing.plaf.FontUIResource;
>
> There may be other such cases but its easy to see in this m
Hi Mario,
> I implemented the method based approach. What I did was to introduce an
> interface that all loops implements, this interface consist of a single
> method that returns a boolean.
>
> I made the implementation final everywhere to try to limit the impact of
> it, although I'm not sur
Hi Mario,
Would you mind if I divide the patch in 2 or 3 slots?
Actually this is a great idea! After completing each slot, you could
check with J2DBench if performance is actually affected or not.
I'll try to give you something already today, hopefully.
Yay! I'm still waiting ;-)
Cheers
anges
needed then...
/Roman
-kto
Roman Kennke wrote:
Hi,
first of all, I think this is a LCMS problem, so we should think about
how to fix this _upstream_, otherwise we end up maintaining a patched
version of lcms *shudder*.
Then I don't think it's a good idea to depend on
Hi,
first of all, I think this is a LCMS problem, so we should think about
how to fix this _upstream_, otherwise we end up maintaining a patched
version of lcms *shudder*.
Then I don't think it's a good idea to depend on such 'internal'
defines. One OS defines or not _LITTLE_ENDIAN, others (
clean
and nice and not make any assumptions. Right?
/ Roman
Mario Torre wrote:
Il giorno gio, 18/06/2009 alle 16.01 -0400, Roman Kennke ha scritto:
Hi Jim,
If only one instance of the loops is used during the lifetime of a
Surface, then we can easily keep this instance there instead of the
Hi Jim,
If only one instance of the loops is used during the lifetime of a
Surface, then we can easily keep this instance there instead of the
SG2D, validating would not initialize any new objects, but only put
stuff together that is already present in the SurfaceData anyway. Or did
I get som
Finally I got back (with some post JavaOne pushing from Phil) to merging
the newest stuff into my FontManager tree and here is the 5th revision
of the FontManager refactoring patch:
http://cr.openjdk.java.net/~rkennke/fontmanager/webrev.05/webrev/
I think I implemented all suggestions from previo
Hi everybody,
I go back to my previous comment that perhaps what we need is for
invalidatePipe to set the loops to null and then fix all the places
where we were relying on "old loops" by setting them intentionally in
the corresponding validate sequences...
I am completely in favour of that
Hi there,
first of all, let me say that - especially in the light of this thread,
I support Mario's change (removal of this one line from the constructor)
for the following reasons:
- It should not be necessary as you say, this field should always be
initialized before use by validatePipe().
lla to track this:
https://bugs.openjdk.java.net/show_bug.cgi?id=100052
I also found a very old bug in Sun's DB:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385680
Would be nice to see this go into OpenJDK7.
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://ken
there a strong reason to load the GE from the bootclassloader, or
could we apply the attached patch instead?
/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
Thanks, Roman
>
> Jennifer
>
> Roman Kennke wrote:
> > Hi,
> >
> > Is it possible to get an update on these patches or did the whole Java2D
> > team just disappear? ;-) Should I enter the patches into Bugzilla or
> > should I simply wait? What's
Hi Dmitri,
> > I think my mental model regarding the GD/GC/DisplayMode API is a bit
> > messed up, or the API is a bit messed up.
>
>It's the API that's a bit messed up.
Phew. ;-)
>Basically, GD represents a real graphics device - like a video board on
> windows, and screen on X11 (w/o
Hi,
I think my mental model regarding the GD/GC/DisplayMode API is a bit
messed up, or the API is a bit messed up.
So far I was always assuming that the GCs (as returned by
GD.getGraphicsConfigurations()) represent all the possible settings
(resolution, color model, etc) that the GD can use. BUT,
m
> into Bugzilla, so they don't get lost? Are they already in the process
> of beeing integrated?
>
> /Roman
>
> Am Dienstag, den 03.03.2009, 16:17 +0100 schrieb Roman Kennke:
> > Hi there,
> >
> > > 4. StrokeShapeTest: createStrokedShape() behaves differentl
I'm not sure if it couldn't be used to do nasty things as well when
sneaking in manipulated GC objects. Maybe this should be made so that it
returns a copy of the real array instead?
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interwork
Yeah right, I just answered this myself after I wrote it. At least for
XPixmaps this makes sense. Could be optimized for Shm and DGA I suppose,
but that would complicate stuff (even more), unless the implementation
gets split up in XPixmapSurfaceData, ShmSurfaceData and DGASurfaceData
or so.
/Roma
#x27;t a
lock on the surface do the same job? I'm thinking when you have
animations on several surfaces in parallel (like in the Java2Demo), it
might be more efficient to have a finer grained lock. Or are there other
pitfalls attached here?
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software E
Hi,
so what happens now with this patch and the others? Should I enter them
into Bugzilla, so they don't get lost? Are they already in the process
of beeing integrated?
/Roman
Am Dienstag, den 03.03.2009, 16:17 +0100 schrieb Roman Kennke:
> Hi there,
>
> > 4
t submitting each of those tests as a bug report into
> bugs.sun.com
> is the right thing to do at the moment.
Ok. The announcement also says 'contributions from those developers
without push permissions'. This is interesting, as it excludes people
like me, who have push access,
any chance, have any of the them already fixed?
>
> Thanks,
> Hiroshi
>
>
--
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 * Te
will surely take some time. In the meantime,
should we push the proposed fix as an interim solution?
/Roman
>
> ...jim
>
> Roman Kennke wrote:
> > Hi there,
> >
> >> 4. StrokeShapeTest: createStrokedShape() behaves differently.
> >
&g
the shape became finite again.
> This happens somewhere in the src/share/classes/sun/java2d/pipe classes...
Ah cool. In this case we can implement it quite easily as in the
attached patch. Seems the output is 1:1 the same as with the non-free
JDK6.
/Roman
>
> ...j
tree and rollback what has already been
rendered (which doesn't seem easy either, because in the case of
strokeTo() this lies outside of the pisces renderer).
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems
Sorry, wrong patch. Here it comes.
/Roman
Am Dienstag, den 03.03.2009, 16:17 +0100 schrieb Roman Kennke:
> Hi there,
>
> > 4. StrokeShapeTest: createStrokedShape() behaves differently.
>
> It turns out that there is an arithmetic overflow here. The pisces
> stroker doe
ur' is much large now, but if you deal
with very large numbers in your shapes, then you will get trouble again.
/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
causes are.
> By any chance, have any of the them already fixed?
>
> Thanks,
> Hiroshi
>
>
>
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid
int x1 = maxX + (rasterMinX >>
SUBPIXEL_LG_POSITIONS_X);
-cache.startRow(y, x0, x1);
+cache.startRow(y, x0, x1 + 1);
int srcIdx = minX;
// Perform run-length encoding
(END)
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke
uot; the problem.
Without having looked at the code, maybe this is a rounding problem? I
think the pisces code was written for fixed point and adopted to
floating point for OpenJDK.
> It sounds like it needs more investigation than that simple change...
Yeah. I will have a look as this also bot
webrev:
http://kennke.org/~roman/fontmanager4/webrev/
And the zipped version:
http://kennke.org/~roman/fontmanager4.zip
Have fun!
/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
e toplevel to contain
> components having different GraphicsDevice's (and/or different
> GraphicsConfiguration's)?
Not sure, but in Xinerama-mode, when half of a window is on one screen
and the other half on the other, I guess there could be components
inside that have different G
ing that file exits, the file is "gone" -
> deleted.
>
> But on MS-Windows, if any process has the file open, then File.delete
> simply fails
> So in order to delete these files, they need to be first closed.
>
> Hopefully you can see this applies *only* to fonts cr
tatic {
> StrikeCache.unsafe.ensureClassInitialized(Font.class);
> }
I don't think that is needed. All the methods take a Font argument, so
any caller must:
- either already have a Font object, in which case the Font class is
already loaded - no problem here.
- pass n
class (as Dmitri says he noted on your blog)
> but I never did get around to making the change.
>
> So its fine in principle but I don't see any advantage to putting
> it into sun.misc.SharedSecrets and having the font implementation
> aware JavaFontAccess interface in sun.misc
Thanks Phil.
/Roman
Am Freitag, den 09.01.2009, 16:15 -0800 schrieb Phil Race:
>
> Roman Kennke wrote:
> > What's the status of this?
> >
>
> Its on my task list to review next week.
>
> -phil.
--
Dipl.-Inform. (FH) Roman Kennke, Software Enginee
What's the status of this?
/Roman
Am Mittwoch, den 10.12.2008, 15:13 +0100 schrieb Roman Kennke:
> Hi Phil,
>
> I finally got around to fix up the font manager stuff. Some comments
> from me inline.
>
> > > this is the big FontManager refactoring patch I already
Windows build still needs to be abstracted from
>23 // SunGraphicEnvironment
>24
> What does that mean?
Dunno. :-) I removed it.
>25 // please, don't reference sgEnv in any other code in this class
>26 // use getGraphicsEnvironment.
>27
o getRasInfo and continue (which calls XSync if needed).
>
> Should I expect problems with design?
> The STR pipelines could have used quite the same mechanism, why wasn't it
> done?
>
> Thanks, Clemens
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
a
there is no filesystem on some of my target
systems). If you don't mind, I'd like to keep it that way.
> Win32FontManager :
>22 // FIXME: Windows build still needs to be abstracted from
>23 // SunGraphicEnvironment
>24
> What does that mean?
Good questi
nform. (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ühre
is this a bug? Or just something that hasn't been
implemented/optimized yet, because it isn't needed on OpenJDKs primary
platforms? (Although, I would think, that at least for non-DGA surfaces
it would be a nice little optimization at least on X11).
/Roman
--
Dipl.-Inform. (FH) Roman K
sign one rasterizer that can meet all of our needs
> at some point, but we've never had the time to just focus on that goal...
>
> ...jim
>
> Roman Kennke wrote:
> > Dear 2d-devs,
> >
> > I want to implement a ShapeDrawPipe, and studying t
Dear 2d-devs,
I want to implement a ShapeDrawPipe, and studying the X11Renderer
implementation I see that there seem to be two different approaches. One
is the (C-only) ProcessPath thingy (ProcessPath.h and ProcessPath.c),
the other is the ShapeSpanIterator, which is available both as Java and
as
Hi,
> Wow, that's the large one. It will take some time for me to look through
> this
> and Phil is the right guy to review most of these changes anyway.
What is the status of the review?
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
will find a cleaner solution of this at some
point, but for now I think it's ok to use these constants. I removed
those comments and the deprecation. Find the updated webrev:
http://kennke.org/~roman/fontmanager/webrev/
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http
correctly. :-)
/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
v is matching current
> thread unless
> there are other code changes that break one of these assumptions.
I see. You are probably right. But: I found at least one call into
Freetype that does not setup the env correctly, that is in
getGlyphCodeNative(). I don't know if this is supposed
1 - 100 of 156 matches
Mail list logo
