On Mon, 15 Mar 2021 10:25:50 GMT, Dmitry Batrak wrote:
> This is the implementation used by JetBrains Runtime for the last 4 years,
> after some cleanup, and with one problem,
> found while preparing the pull request, fixed.
> Even though typical scenarios for a UI application shoul
On Wed, 7 Apr 2021 02:56:37 GMT, Sergey Bylokhov wrote:
>> Dmitry Batrak has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - 8263583: Emoji rendering on macOS
>>
>>extended test case to cove
ual rendering of the glyph image, it's done by the
> straightforward glDrawPixels call in OpenGL renderer,
> and by re-using existing Blit primitive in off-screen renderers.
>
> **Testing**
>
> There's no good way to test the new functionality automatically, but I&#x
On Thu, 6 May 2021 19:40:16 GMT, Phil Race wrote:
>> Dmitry Batrak has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8263583: Emoji rendering on macOS
>>
>> add 'static' modifier to
On Fri, 19 Mar 2021 13:48:12 GMT, Dmitry Batrak wrote:
>> This is the implementation used by JetBrains Runtime for the last 4 years,
>> after some cleanup, and with one problem,
>> found while preparing the pull request, fixed.
>> Even though typical scenarios for a
On Thu, 18 Mar 2021 10:02:11 GMT, Sergey Bylokhov wrote:
>> @mrserb I don't know how to check automatically that glyph painting works
>> correctly. Could you please suggest a way to do it? In JetBrains Runtime we
>> have a test that checks that rendered emoji glyph matches one of stored
>> 'go
ual rendering of the glyph image, it's done by the
> straightforward glDrawPixels call in OpenGL renderer,
> and by re-using existing Blit primitive in off-screen renderers.
>
> **Testing**
>
> There's no good way to test the new functionality automatically, but I&#x
On Tue, 16 Mar 2021 19:46:16 GMT, Sergey Bylokhov wrote:
>>> If it is a complete "General" loop which supports all possible combination
>>> of incoming src/comp/dst/transform/etc I suggest to confirm that in the
>>> test.
>>
>> @mrserb This code is currently only used by GlyphListLoopPipe-base
On Tue, 16 Mar 2021 05:10:05 GMT, Dmitry Batrak wrote:
>> Initial testing it looks OK with OpenGL but it renders as garbage with the
>> metal pipeline.
>> I'd guess metal isn't expecting 4bpp and the stride is wrong.
>> I see updates in OGLTextRenderer so s
On Mon, 15 Mar 2021 23:47:16 GMT, Phil Race wrote:
> Initial testing it looks OK with OpenGL but it renders as garbage with the
> metal pipeline.
> I'd guess metal isn't expecting 4bpp and the stride is wrong.
> I see updates in OGLTextRenderer so something similar likely needed for metal.
> Sin
This is the implementation used by JetBrains Runtime for the last 4 years,
after some cleanup, and with one problem,
found while preparing the pull request, fixed.
Even though typical scenarios for a UI application should be covered, it's not
a complete solution. In particular, emoji-s
still won'
fixed,
mentioning that JDK-8236996 'mostly' fixes it? Should I remove myself from
the assignee field? Or should I just leave things as they are,
assuming that if someone will want to work on it, the issue will be
reassigned then?
Best regards,
Dmitry Batrak
On Mon, Jan 27, 2020 at 8:45 PM Phi
Thanks!
Now that that change has two +1's, would anyone be able to push it?
Best regards,
Dmitry Batrak
On Tue, Jan 21, 2020 at 8:05 AM Sergey Bylokhov
wrote:
> Looks fine.
> Thank you for contribution!
>
> On 1/20/20 12:14 am, Dmitry Batrak wrote:
> > > Ok approved
> Ok approved. Seems it is making a few things better if not ideal, but
nothing worse.
Thanks!
Anyone else volunteering to review?
Best regards,
Dmitry Batrak
On Tue, Jan 14, 2020 at 8:58 PM Phil Race wrote:
> Ok approved. Seems it is making a few things better if not ideal, but
>
ctor gv =
FONT.createGlyphVector(g.getFontRenderContext(),
new int[]{glyphCode});
g.drawGlyphVector(gv, 0, 0);
}
long endTime = System.currentTimeMillis();
g.dispose();
System.out.println(endTime - startTime);
}
}
-
ssues for about 3
months in testing and for about 1 month in production.
Best regards,
Dmitry Batrak
That's what I did locally - copied the file. I was surprised by the
representation of that operation in webrev. I hope this will be applied in
the same way during committing.
Best regards,
Dmitry Batrak
On Tue, Nov 26, 2019 at 11:45 PM Phil Race wrote:
> This looks good to me, so long
Please find the link to the updated webrev below. A test was added, which
verifies the change.
http://cr.openjdk.java.net/~dbatrak/8210058/webrev.01/
Best regards,
Dmitry Batrak
On Fri, Nov 22, 2019 at 11:48 AM Prasanta Sadhukhan <
prasanta.sadhuk...@oracle.com> wrote:
> Only th
t's source
code, or it can be loaded by a relative reference?
Best regards,
Dmitry Batrak
On Mon, Nov 18, 2019 at 1:29 PM Jayathirth Rao
wrote:
> Hi Dmitry,
>
> Thanks for the patch.
> I can sponsor this.
>
> I went through the change and it looks okay.
> But I have a
Hello,
Still trying.
Any volunteers to sponsor/review?
Best regards,
Dmitry Batrak
On Tue, Nov 5, 2019 at 11:27 AM Dmitry Batrak
wrote:
> Hello,
>
> Let me repeat the request.
> Any volunteers to sponsor/review?
>
> Best regards,
> Dmitry Batrak
>
> -
Hello,
Let me repeat the request.
Any volunteers to sponsor/review?
Best regards,
Dmitry Batrak
-- Forwarded message -
From: Dmitry Batrak
Date: Thu, Aug 29, 2019 at 1:58 PM
Subject: [PATCH] 8210058: Algorithmic Italic font leans opposite angle in
Printing
To: 2d-dev <2d-
ttps://bugs.openjdk.java.net/browse/JDK-8210058
Webrev: http://cr.openjdk.java.net/~dbatrak/8210058/webrev.00/
Best regards,
Dmitry Batrak
rocess
>> for OpenJDK to set "truetype:interpreter-version=35" as the default when
>> compiling Freetype.
>>
>>
>> I have read freetype notes on this and it isn't clear whether we want to
>> go against what it does by default.
>> And in any case, Oracle JDK switched from T2K to freetype in 11 so there
>> can be differences due to that too.
>>
>> It may be that Windows is the only platform on which this reversion is a
>> good idea.
>> And in any case, on Linux + Solaris (not sure about other Unix-like
>> distros) OpenJDK
>> currently uses the system freetype so a JDK build change for freetype
>> wouldn't help.
>>
>>
> After reading a little more, I would suggest keeping the latest Freetype
> but compiling it using truetype:interpreter-version=35 to fix the kerning
> issues.
>
> Regards,
> Peter.
>
>
Best regards,
Dmitry Batrak
Thanks!
Hopefully someone can push (sponsor) it now.
Best regards,
Dmitry Batrak
On Mon, Apr 8, 2019 at 10:16 PM Sergey Bylokhov
wrote:
> +1
>
> On 01/04/2019 02:12, Alexey Ushakov wrote:
> > Looks good for me.
> >
> > Best Regards,
> > Alexey
> >
>
A second reviewer is still required.
Best regards,
Dmitry Batrak.
On Mon, Apr 1, 2019 at 10:44 AM Dmitry Batrak
wrote:
> > Sorry for the delay. I've now finished verifying this and it is a +1
> from me.
> Thanks!
>
> Anyone else, please? A second reviewer is required.
&
>
> -phil.
>
> On 3/12/19, 1:32 AM, Dmitry Batrak wrote:
>
> > This looks good to me, if I understand correctly that we now create
> > the face on first use and cache it fin Java or as long as the Font2D is
> > alive.
> > And the JNIEnv is always found on
> T
of your performance test
significantly, but it's still about two times slower as compared to
1.8.0_202 results on my machine.
Best regards,
Dmitry Batrak
On Fri, Mar 8, 2019 at 10:54 PM Eirik Bakke wrote:
> A random Java developer here passing by... great to see work on HarfBuzz
> perf
enjdk.java.net/~dbatrak/8220231/webrev.01-2/
Part 3 (scaler pointer passing removal):
http://cr.openjdk.java.net/~dbatrak/8220231/webrev.01-3/
Best regards,
Dmitry Batrak
On Fri, Mar 8, 2019 at 3:21 AM Philip Race wrote:
> This looks good to me, if I understand correctly that we now create
undant
with this fix.
Issue: https://bugs.openjdk.java.net/browse/JDK-8220231
Webrev: http://cr.openjdk.java.net/~dbatrak/8220231/webrev.00/
Best regards,
Dmitry Batrak
Thanks! I received a response from o...@openjdk.java.net.
On Thu, Dec 14, 2017 at 6:26 PM, Philip Race wrote:
> Perhaps o...@openjdk.java.net for things like this but I'll forward this
> onto some folks who may be able to help.
>
> -phil.
>
> On 12/14/17, 12:21
I'm entering my password
correctly, because if I try a definitely wrong password I get a specific
notification about it.
Sometimes it works, but it can take tens of attempts to make it work.
--
Best regards,
Dmitry Batrak
> Seems like you must have backported the HB code to JDK 8u ?
Yes, we did.
> However a similar end result is the goal ...
Let me know if I can help this process in any way.
Best regards,
Dmitry Batrak
On Fri, Aug 18, 2017 at 9:21 PM, Phil Race wrote:
> Hi,
>
> If you read
the formal procedure
(raising the ticket, submitting RFRs, etc). So, please let me know
if you're interested, and whether you have any comments or suggestions. In
any case, I'll require someone sponsoring this change,
as I don't have a Committer status.
Best regards,
Dmitry Batrak
On
s char-to-glyph mapping.
Best regards,
Dmitry Batrak
ed in OpenJDK builds (e.g.
Ethiopic and Dingbats) for the Menlo-Italic case. Don't know whether that
can be considered critical. Other non-hidden fonts can probably be added to
cover those ranges as well, if needed.
Best regards,
Dmitry Batrak
On Thu, Feb 16, 2017 at 8:33 AM, Prasanta
or us). If even this is considered risky
for JDK 9, then probably adding
.NotoSansUniversal with or instead of .GeezaProInterface as a hardcoded
component makes sense.
Best regards,
Dmitry Batrak
On Fri, Feb 10, 2017 at 8:19 PM, Phil Race wrote:
> I think that so long as we are using JRS
Could anyone else review this please?
Best regards,
Dmitry Batrak
On Wed, Feb 8, 2017 at 3:34 AM, Philip Race wrote:
> The point being the fonts end up being registered by the canonical path
> and that then is the basis for comparison used when we come back here ?
> I think this w
he cascade list, that
is
built currently, can probably be used to perform font fallback in all cases.
Best regards,
Dmitry Batrak
> Hi All,
>
> Please review a fix for an issue which causes arabic character "alef" to
> be not rendered in osx for menlo font in italic style.
which I'm ready to
propose a fix myself.
Best regards,
Dmitry Batrak
ecifics of the font being used (Menlo), but I couldn't think of
another way to create an automated test for this issue.
Best regards,
Dmitry Batrak
sting since April 2016, and in production since August
2016, I'm not aware of any issues caused by it.
We also do run JDK regression tests (jtreg) on our codebase - no
regressions there either.
Best regards,
Dmitry Batrak
On Wed, Feb 8, 2017 at 3:34 AM, Philip Race wrote:
> The point bei
ng and updating webrevs on
cr.openjdk.java.net.
A month ago I've sent a request to Mark Reinhold, jdk9 project lead, as
described at http://openjdk.java.net/projects/, but didn't receive any
response.
Best regards,
Dmitry Batrak
egressions.
Best regards,
Dmitry Batrak
ing
'width'
methods just become much less useful in Java 9, taking into account
spreading
of hidpi monitors.
Best regards,
Dmitry Batrak
On Fri, Dec 23, 2016 at 9:52 PM, Phil Race wrote:
>
>
> On 12/20/2016 02:11 AM, Dmitry Batrak wrote:
>
> Missing floating-point-precisio
nd maybe to Graphics2D) makes sense? Maybe it's planned already as part of
HiDPI-related activity? Should I raise an RFE via bugs.java.com for this?
Thanks,
Dmitry Batrak
by users, found in IDEs
testing or in JDK testing (AWT/Swing OpenJDK 8 jtreg tests).
Best regards,
Dmitry Batrak
On Wed, Nov 9, 2016 at 11:55 PM, Phil Race wrote:
> 29 import java.awt.*;
>
> We avoid wild card imports - even in tests.
>
> Can you provide a pointer to any Apple d
ng,
already present there,
could work.
Webrev for the fix is available at
http://cr.openjdk.java.net/~avu/JDK-8169202/webrev.02/
(kindly posted by my colleague, having access to cr.openjdk.java.net).
Best regards,
Dmitry Batrak
Added an automated version of the test to the webrev -
http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.01/
Best regards,
Dmitry Batrak
On Tue, Nov 1, 2016 at 5:40 PM, Sergey Bylokhov
wrote:
> Looks fine to me, but the jtreg test will be helpful.
>
> On 27.10.16 11:56, Dmitry Bat
webrev, if
that makes sense.
Best regards,
Dmitry Batrak
On Thu, Oct 27, 2016 at 2:17 AM, Philip Race wrote:
> Hi,
>
> I can file a bug on this if I can't find one.
> If you can email me the test it will help even if it is not checked in.
>
> -phil.
>
> On 10/26/16,
openjdk.java.net).
To my knowledge, there's no ticket in OpenJDK issue tracker for the
proposed enhancement.
I can submit it via http://bugs.java.com/, if that's an obstacle.
Best regards,
Dmitry Batrak
ve up on it
and move to other patches.
Currently we (at JetBrains) also have other fixes, that we'd like to
propose for inclusion in OpenJDK.
Best regards,
Dmitry Batrak
g the issue.
Webrev for the fix is available at
http://cr.openjdk.java.net/~avu/DmitryBatrak/JDK-8152680
(kindly posted by my colleague, having access to cr.openjdk.java.net).
Best regards,
Dmitry Batrak
iff in the email.
>
> Or Alexey could just push it as his own :-)
>
> -phil.
>
> On 04/07/2016 05:26 AM, Dmitry Batrak wrote:
>
>> Hello,
>>
>> I'd like to propose a fix for JDK-8146035. I am not a committer,
>> so I hope someone can sponsor this fix.
DC before GetTextMetrics call.
Here's webrev link - http://adm-12504.intellij.net/
I didn't create a test case, as it would require a specific font file
(I couldn't reproduce the issue for fonts bundled with Windows).
Best regards,
Dmitry Batrak
54 matches
Mail list logo
