added awt-dev@
On 20.05.2014 21:31, Sergey Bylokhov wrote:
On 5/20/14 9:17 PM, Phil Race wrote:
On 5/20/2014 10:03 AM, Sergey Bylokhov wrote:
On 5/20/14 8:52 PM, Phil Race wrote:
So my first question here was. So what does D3D do ? We should just
copy that code.
D3D doesn't work as well
added awt-dev@
On 23.05.2014 22:34, Sergey Bylokhov wrote:
Hello,
Any volunteers to review the fix?
On 5/5/14 5:30 PM, Sergey Bylokhov wrote:
Hi, Jim.
On 01.05.2014 4:44, Jim Graham wrote:
Hi Sergey,
I think the bug is in the readObject routine. It sets the initial
size of the arrays based
against d3d?
Thanks,
Andrew
On 5/20/2014 9:31 PM, Sergey Bylokhov wrote:
On 5/20/14 9:17 PM, Phil Race wrote:
On 5/20/2014 10:03 AM, Sergey Bylokhov wrote:
On 5/20/14 8:52 PM, Phil Race wrote:
So my first question here was. So what does D3D do ? We should
just copy that code.
D3D doesn't work
Hello.
Please review the fix for jdk 9.
Description:
The fix 8041129 reuse LoadIntArgbPreTo1IntArgb macros, which adds an
additional dependency to libxawt from libawt - div8table.
But div8table is not listed in the appropriate mapfile, so the build was
failed on solaris.
Solution:
div8table
Hello.
Please review the fix for jdk 9, which is also targeted for jdk 8u20.
Description:
We have two codepaths to draw a raster to the opengl:
- via glDrawPixels
- via intermediate texture.
We empirically checked, what way is better, based on benchmarks. Became
obvious that on intel devices
On 11.06.2014 17:35, Andrew Brygin wrote:
Hi Sergey,
could you please clarify why you have eliminated OGLC_VENDOR_SUN?
We have only two bits to store the vendor information, since SUN is not
used I replace it by INTEL.
Thanks,
Andrew
On 6/11/2014 5:01 PM, Sergey Bylokhov wrote:
Hello
Hello, Denis.
Thanks for this research!
On 09.07.2014 15:13, Denis Fokin wrote:
The current version consist of three parts.
1. We are rendering glyphs in offscreen images using Quartz functions.
This does not work without kCGBitmapByteOrder32Host mask.
I assume LCD hint does not work? this
Hello,
Can somebody review the fix?
On 11.06.2014 17:43, Sergey Bylokhov wrote:
On 11.06.2014 17:35, Andrew Brygin wrote:
Hi Sergey,
could you please clarify why you have eliminated OGLC_VENDOR_SUN?
We have only two bits to store the vendor information, since SUN is
not used I replace
JDK 1.5
APIs then maybe Jim had to handle something similar and has an idea ?
-phil.
On 4/30/2014 4:13 AM, Andrew Brygin wrote:
Hello Sergey,
the change looks fine to me.
Thanks,
Andrew
On 4/30/2014 3:12 PM, Sergey Bylokhov wrote:
Hello.
Please review the small fix for jdk 9.
Makefile
/default.opt \
+# java -jar dist/J2DBench.jar -batch -loadopts options/default.opt \
-phil.
On 8/7/2014 9:23 AM, Sergey Bylokhov wrote:
Hello, Phil.
jdk 9 now supports -target 1.6+/-source 1.6+ options only. Looks
like we should use this minimum version too.
If you have no objections I'll prepare
notice that one of the changes (in CMMTests) is to a line with a typo
(Platfrom instead of Platform both in the code and in the comment on the
same line), but fixing the typo might affect a lot of other lines...?
...jim
On 8/12/14 8:32 AM, Sergey Bylokhov wrote
in
the comment there.
The word intended there is, I believe, Platform...
On 8/12/14 4:20 PM, Sergey Bylokhov wrote:
Hi, Jim.
Actually a Boolean was changed to a boolean, to skip autoboxing.
http://cr.openjdk.java.net/~serb/8042199/webrev.02/src/share/demo/java2d/J2DBench/src/j2dbench/tests
Hello,
Please review the fix for jdk 9.
The fix was contributed by pavel.ra...@oracle.com
Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
Webrev can be found at: http://cr.openjdk.java.net/~serb/8055326/webrev.00
--
Best regards, Sergey.
Hi, Andrew.
It seems to me that the same bug exists on other platforms as well.
Probably we can move this check to the upper level(in the same way as
d3d in case of InvalidPipeException?)?
On 22.08.2014 18:34, Andrew Brygin wrote:
Hello,
could you please review a fix for CR 8040617?
Bug:
://cr.openjdk.java.net/~bae/8040617/9/webrev.01/
Thanks,
Andrew
On 8/22/2014 6:47 PM, Sergey Bylokhov wrote:
Hi, Andrew.
It seems to me that the same bug exists on other platforms as well.
Probably we can move this check to the upper level(in the same way as
d3d in case of InvalidPipeException?)?
On 22.08.2014
Hi, Phil.
The fix looks good.
On 05.09.2014 1:48, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8056209
Proposed removing several files
./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
Hi, Andrew.
I am not an expert in this area, but probably the bug can be fixed in
the readHeader itself? Because currently it call
iis.skipBytes(bitmapOffset) at the end only for the first time.
On 03.09.2014 16:23, Andrew Brygin wrote:
Hello,
could you please review a fix for CR 8041465?
Hi, Alexander.
The fix looks good.
On 09.09.2014 18:38, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8057940
webrev: http://cr.openjdk.java.net/~alexsch/8057940/webrev.00
The fix reverts JDK-8049893 change which introduces
The fix looks fine to me too.
On 09.09.2014 22:18, Phil Race wrote:
Approved
-phil.
On 09/09/2014 11:11 AM, Volker Simonis wrote:
Hi,
I've updated my webrev to reflect the fix which has now been pushed to
LittleCMS mainline. It renames SNONE to SUNDEFINED :-
that, looks good.
Some fun new words in there. I particularly liked utilitized and unclude.
-phil.
On 8/21/2014 10:38 AM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk 9.
The fix was contributed by pavel.ra...@oracle.com
Bug: https://bugs.openjdk.java.net/browse/JDK-8055326
Webrev
Hi, Andrew.
The fix looks good then.
my preference is to leave the seek(bitmapStart) in the read() method
in order to reduce potential overhead because readHedaer() is called
very often.
On 9/8/2014 7:31 PM, Sergey Bylokhov wrote:
Hi, Andrew.
I am not an expert in this area
Hi, Clemens.
The fix looks fine to me.
On 03.08.2014 21:34, Clemens Eisserer wrote:
Hello,
Please review my changes for the first patch of a series to come to
cleanup the Xrender Java2D pipeline.
http://cr.openjdk.java.net/~ceisserer/8049757/webrev.00/
This patch removes support for the
Hello.
Please review the fix for jdk 9.
The new blit was implemented: OGLGeneralTransformedBlit, it adds a huge
boost in case of uncached/unmanaged images:
Bug: https://bugs.openjdk.java.net/browse/JDK-8029253
Webrev can be found at: http://cr.openjdk.java.net/~serb/8029253/webrev.04
Notes:
wrote:
Looks good. I don't have a PC handy right now to test myself but I'm
curious if the
tests has similar poor performance issues with D3D and whether adding
the
same would help there too ..
-phil.
On 10/6/14 10:29 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
The new
Hello.
Please review the fix for jdk 9.
The new blit was implemented: D3DGeneralTransformedBlit. Performance
difference is 30 seconds vs 25 ms in the test from
https://bugs.openjdk.java.net/browse/JDK-8029253
I cannot provide J2DBench results because it simply crash my video
Hi, Phil.
The fix looks good.
should be honoured to meet
DEFINE_SOLID_DRAWGLYPHLIST* expectations, i.e. how should I place bytes in
GlyphInfo.
May be it should be set somewhere in Java code.
Could anyone share this knowledge with me?
Thank you,
Denis.
On 09 Jul 2014, at 19:22, Sergey Bylokhov sergey.bylok
Hi, Phil.
The fix looks good.
On 14.10.2014 3:27, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8058969
http://cr.openjdk.java.net/~prr/8058969/
This is a missing doprivileged in code updated to support jigsaw
-phil.
--
Best regards, Sergey.
Comparison to basis:
Best result: 15509.09% of basis
Worst result: 97.27% of basis
Number of wins: 9
Number of ties: 0
Number of losses: 1
On 10.10.2014 14:53, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
The new blit
Hello.
Please review the fix for jdk 9.
In the OGLAnyCompositeBlit the clip for the primary destination is used
as the clip for the temporal buffer.
Bug: https://bugs.openjdk.java.net/browse/JDK-8061456
Webrev can be found at: http://cr.openjdk.java.net/~serb/8061456/webrev.03
--
Best
Hello.
Please review the fix for jdk 9.
Type of the temporary buffer in DrawImage.renderImageXform() is
incorrect. Note that we blit this buffer to the destination, using next
maskblit/blit:
line 463: maskblit = MaskBlit.getFromCache(SurfaceType.IntArgbPre,
Hi, Hendrik.
The fix looks good.
webrev: http://cr.openjdk.java.net/~serb/Hendrik/8057830/webrev
However, before we can accept fixes from you, you will need to have an
OCA signed. Please find more details here:
http://www.oracle.com/technetwork/community/oca-486395.html
On 22.09.2014 12:19,
be tweaked for slow machines for all tests at once.
...jim
On 10/27/14 8:57 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
Type of the temporary buffer in DrawImage.renderImageXform() is
incorrect. Note that we blit this buffer to the destination, using next
/28/2014 5:29 AM, Sergey Bylokhov wrote:
Hi, Jim.
Thanks for review!
On 27.10.2014 21:12, Jim Graham wrote:
In the test case you call new BufferedImage() with a Transparency
constant which is essentially a random number to determine the type
of BufferedImage since it is expecting its own values
Hi, Jim, Phil.
I just look at this code and have a related question. Why we cannot clip
source coordinates(using invers transform)? This:
- solve this issue
- speedup all our general loops, which are based on intermediate
buffers(including renderImageXform())
- we can return earlier if a
Hi, Hendrik.
You can find some process information here:
http://openjdk.java.net/projects/jdk8u/
http://openjdk.java.net/projects/jdk8u/approval-template.html
I will send an approval request for jdk8u for you, after I'll push this
change to jdk 9.
On 28.10.2014 12:02, Hendrik Schreiber wrote:
Hello.
Please review the fix for jdk 9.
Change description:
- Test groups were wrapped by JScrollPane
- Translucent volatile images now can be used as source and destination
- Additional source/destination were added(TYPE_4BYTE_**)
- Main window will be created on EDT at the center of the screen
. By default 20x20 and 250x250 are enabled only.
-phil
On 11/5/2014 11:17 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
Change description:
- Test groups were wrapped by JScrollPane
- Translucent volatile images now can be used as source and destination
- Additional source
Hi, Phil.
Looks fine .
On 07.11.2014 21:52, Phil Race wrote:
http://cr.openjdk.java.net/~prr/8039444/
Historically we enabled D3D only on Nvidia ATI hardware.
Intel chipsets are a large part of the market but we continually
encountered
rendering artifacts that apparently were driver or
Hello.
Please review the fix for jdk 9:
- If interaction of dstclip is empty we return immediately, without
creation of intermediate buffers
- Size of intermediate buffers now take into account the clip, this is
especially effective if the we have a big scale, which much bigger than
TransformHelper to the java level(atleast generation of edges array).
Additionally it will be simpler to check a performance improvement, because now
it is not so obvious comparing to the current percents improvement.
- james.gra...@oracle.com wrote:
On 11/10/14 12:03 PM, Sergey Bylokhov
Hi, Jim.
Please review an updated version of the fix:
http://cr.openjdk.java.net/~serb/8059942/webrev.16
The new method in Region class was added.
On 11.11.2014 5:43, Jim Graham wrote:
On 11/10/14 2:52 PM, Sergey Bylokhov wrote:
Hi, Jim.
To simply fill a span in the Region, I'll need
bounding box even with overflow occuring).
I do not clip edges intentionally, because I trust the output of
TransformHelper, which I assume should validate possible overflow. I'll update
a javadoc.
...jim
On 11/13/14 8:35 AM, Sergey Bylokhov wrote:
Hi, Jim.
Please review
.
- end bands.length was added to the loop for the reason of overall loop
performance(+15%).
- james.gra...@oracle.com wrote:
On 11/13/14 2:56 PM, Sergey Bylokhov wrote:
Hi, Jim
Please revert all iff = if changes in Region - those are not
typos.
ok
Hand-coding would require
- james.gra...@oracle.com wrote:
One thing to consider, though, is that this code is only used in some
rare cases - either that we don't have a direct native loop for the TH
native code to use directly, or that it is a custom composite.
or bicubic interpolation is used(in some cases
- james.gra...@oracle.com wrote:
By this code I mean the new code that constructs a clip region from
an
edges array. That only happens if the tests at 478 and 491 fail and
those have nothing to do with bicubic or BG operations.
BG operations get folded into INT_RGB earlier in the
Hi, Jim.
Please review an updated version of the fix:
http://cr.openjdk.java.net/~serb/8059942/webrev.18
I hope that all possible overflows/correctness/validity problems are
checked now.
On 15.11.2014 1:50, Jim Graham wrote:
Hi Sergey,
On 11/14/14 6:40 AM, Sergey Bylokhov wrote:
Hi, Jim
Hello.
Please review the fix for jdk 9.
This fix initially was sent as a fix for JDK-8029253 [1], but was
postponed because another issue became a bottleneck [2]
Description:
We have two codepaths to draw a raster to the opengl surface:
- via glDrawPixels
- via intermediate texture.
We
Hello.
Please review the fix for jdk 9/8u40.
Device transformation fDevTx , which was added in [1] and fFontTx
contains different directions.
Both of them are used in calculation of advances, because of that in
some cases we get incorrect/opposite text rotation.
Note that I am not sure that
in SG2D.checkFontInfo(). And CTextPipeline use this translation instead of
fontinfo.originX/Y.
-phil.
On 12/10/14 5:31 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9/8u40.
Device transformation fDevTx , which was added in [1] and fFontTx contains
different
Hi, Phil.
Probably it is possible to move the new code in CFontManager.loadFonts()
to the SunFontManager.loadFonts()?
Note that in the test the text Big italic red text should be ...black
text, and the window should be disposed at the end of the test. Why
this test is mac specific?
On
Hi, Phil.
On 24.12.2014 0:30, Phil Race wrote:
Because the whole problem is mac-specific and you can't find the
situation
with the fonts that cause this problem elsewhere. Its really iffy to
test at all ..
Note that I am using glyphcodes, which means you have to know exactly
what font you
Hi, Phil.
The fix looks fine. Note that necessary tags are absent in the test
(@test etc).
On 24.12.2014 0:30, Phil Race wrote:
On 12/23/2014 11:10 AM, Sergey Bylokhov wrote:
Hi, Phil.
Probably it is possible to move the new code in
CFontManager.loadFonts() to the SunFontManager.loadFonts
Hi, Phil.
The fix looks good.
On 04.02.2015 14:07, Andrew Brygin wrote:
Hi Phil,
the fix looks fine.
Thanks,
Andrew
On 2/3/2015 11:14 PM, Phil Race wrote:
Fixing the mistakes Sergey just pointed out :
http://cr.openjdk.java.net/~prr/8072433/
I marked these no-reg clean up as both are not
Hi, Clemens.
On 23.01.2015 2:18, Clemens Eisserer wrote:
The D3D OpenGL pipelines have some code to work around the issue by
performing a sync for blits which are equal to the blits of Swing's
backbuffer operations.
Actually it will do this for any blits to the window, because the swing
can
On 23.01.2015 13:01, Clemens Eisserer wrote:
Is there a reason why AWT doesn't explicitly flush and why the
flush-after-blit approach was chosen?
If a sync will be implemented in a Swing, then will be necessary to add
a sync to all places where we paint an images to the screen, and this is
Hello.
Please review a fix for jdk 9.
BufferedImage::getPropertyNames() was implemented according to
specification.
Notes:
- The properties map in the constructor is defined as ?,?, which means
it can have non-String keys. Long time ago (in 2004) it was defined as
String, ? but was changed to
Hello.
Please review a small fix for jdk 9.
The API Doc for ImageWriter.PrepareWriteSequence() claims that this
method will throw UnsupportedOperationException when canWriteSequence()
returns false. But this does not seem to be happening for JPEG ImageWriter.
JPG writer has failed to override
Hi, Prasanta.
The fix looks good.
- prasanta.sadhuk...@oracle.com wrote:
Hi All,
Please review a small fix for jdk9
Fix the getMinValue()/getMaxValue() IllegalArgumentException message.
Bug: https://bugs.openjdk.java.net/browse/JDK-8072678
webrev:
and less fragile too!
http://cr.openjdk.java.net/~prr/8075277.1/
-phil.*
*
On 3/16/15 2:18 PM, Sergey Bylokhov wrote:
Hi, Phil
Is it possible to replace a long list java.desktop_EXCLUDE_FILES
using $(wildcard, or we still using some files on osx from the unix
folder?
Although a more complete
Hi, Phil
Is it possible to replace a long list java.desktop_EXCLUDE_FILES using
$(wildcard, or we still using some files on osx from the unix folder?
Although a more complete fix would do something like refactor the
source files,
as that would be less fragile amongst other things, this at
Hi, Andrew?
Hi, Andrew.
Should we update a readFully() also?
* @exception java.io.EOFException if the stream reaches the end before
* reading all the bytes.
* @exception IOException if an I/O error occurs.
*/
void readFully(byte[] b, int off, int len) throws IOException;
) {
throw new EOFException();
}
I assume this method should throw an exception if nbytes!=len as
described in the specification. same as readShort/readInt.
-phil.
On 03/20/2015 10:32 AM, Sergey Bylokhov wrote:
Hi, Andrew?
Hi, Andrew.
Should we update a readFully() also?
* @exception
= read(b, off, len);
352 if (nbytes == -1) {
353 throw new EOFException();
354 }
355 off += nbytes;
356 len -= nbytes;
357 }
-phil.
On 03/20/2015 10:54 AM, Sergey Bylokhov wrote:
Andrew, The fix looks good to me
11.03.15 18:40, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8/9.
Lots of issues(hangs or focus lost) occurred after we call
NSScreen.backingScaleFactor on a Appkit Thread in time of splash
screen initialization.
This is a regression of two fixes:
https://bugs.openjdk.java.net
Hello.
Please review the fix for jdk 8/9.
Lots of issues(hangs or focus lost) occurred after we call
NSScreen.backingScaleFactor on a Appkit Thread in time of splash screen
initialization.
This is a regression of two fixes:
https://bugs.openjdk.java.net/browse/JDK-8043869
Hi, Alexander.
The fix looks good.
25.03.15 13:31, alexander stepanov wrote:
Hello,
Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8075934
Webrev:
http://cr.openjdk.java.net/~avstepan/8075934/webrev.01/
Just a small HTML markup fix.
Thanks,
Alexander
--
Best
). On osx the best format is argb_pre, but
it is unclear what is the best format on other platforms(especially on
windows where we can switch loops gdi--d3d).
...jim
On 3/27/15 5:31 PM, Sergey Bylokhov wrote:
28.03.15 0:50, Jim Graham wrote:
On 3/27/15 3:48 AM, Hendrik Schreiber wrote
Hello, Jim.
27.03.15 0:48, Jim Graham wrote:
RenderingHints.java:
Where do we process this hint? Don't we need to pass it to the
getVariant() method?
I don't understand the hint values other than the one that always uses
the base image. Default I guess gives us the ability to use the Mac
, Sergey Bylokhov wrote:
28.03.15 4:10, Jim Graham wrote:
Thanks Sergey,
Have you been following the rest of this thread? Any thoughts on how
much the lack of PRE pixel format in the PNG loader might be hurting
us?
It depends. Not the best format can slow down us from x2 to x10 and
more(before
On 04.03.2015 15:51, Alan Bateman wrote:
On 04/03/2015 12:37, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
There are a number of public API whichreference the unsupported
java.awt.peer interfaces.
public java.awt.Component.getPeer() @deprecated 1.1
public
Hello.
Please review the fix for jdk 9.
There are a number of public API whichreference the unsupported
java.awt.peer interfaces.
public java.awt.Component.getPeer() @deprecated 1.1
public java.awt.Font.getPeer() @deprecated 1.1
public java.awt.MenuComponent.getPeer() @deprecated 1.1
There is
The new version of the fix:
http://cr.openjdk.java.net/~serb/8074028/webrev.06
Font.getPeer() was renamed to Font.getFontPeer().
On 04.03.2015 15:51, Alan Bateman wrote:
On 04/03/2015 12:37, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
There are a number of public API
Thanks for clarification. The fix looks good to me.
On 24.02.2015 18:07, Roman Kennke wrote:
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
for some reason, this should
allow us to limp along moderately well as opposed to being in dire straits.
-phil.
On 2/5/15 8:52 AM, Sergey Bylokhov wrote:
Hello, Roman, Phil.
The fix looks fine except an absent documentation in new class and
InternalError + 80 chars per line.
But I have a question: do
28.03.15 0:50, Jim Graham wrote:
On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
That's an odd bug. I'll note that it points out that we had missing
loops in the OpenGL pipeline to directly deal with the non-PRE data
and it links to a bug that adds those loops for more direct handling.
Actually
Hello.
Is that a problem that with the new code we can get OOM earlier in some
cases? Should we take care of overflow more carefully now? It seems that
ArrayList.grow contains similar logic.
02.04.15 23:59, Jim Graham wrote:
All of your comments are spot on (modulo the confusion over
()
- SG2D.getDefaultTransform() is updated to not check
GraphicsConfiguration.getDefaultTransform() on null
- the test is updated to compare SG2D transform with
GraphicsConfiguration transform on all graphics configurations
Thanks,
Alexandr.
On 4/17/2015 4:28 PM, Sergey Bylokhov wrote:
Hi, Alexander.
I assume
Looks fine.
On 20.04.15 22:07, Andrew Brygin wrote:
Hi Phil,
it looks fine to me.
Thanks,
Andrew
20/04/15 21:49, Phil Race пишет:
Andrew Sergey,
Please review this identical 8u60 backport (diff below) of the JDK 9
fix : http://hg.openjdk.java.net/jdk9/hs/jdk/rev/b7e402c9b183
hg diff
The fix looks fine to me. It will be good if an SQE team will port this
test to the jdk ws.
On 27.03.15 17:50, Andrew Brygin wrote:
There is a minor update in the fix: it does not worth to blend
black-on-white
and white-on-black glyphs for the case of AA glyphs, because it makes
no
Hi, Prasanta.
Can you split the long lines in the test?
On 30.04.15 9:03, prasanta sadhukhan wrote:
Hi All,
Any feedback? Can this be committed?
Regards
Prasanta
On 4/15/2015 5:07 PM, prasanta sadhukhan wrote:
Hi,
I would like a review for a jdk9 fix whereby TAG_OPBD tag is updated
to
Looks fine.
On 29.04.15 20:43, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK-8079067
http://cr.openjdk.java.net/~prr/8079067/
Just deleting unused code.
-phil.
--
Best regards, Sergey.
Looks fine to me.
On 30.04.15 0:47, Phil Race wrote:
Please review the 8u backport of the same
http://cr.openjdk.java.net/~prr/8078331.8u/
I will ease this by noting the following
- I generated the webrev by applying the 9 patch to 8u.
- The changes differ from the JDK 9 patch only in the
Hi, Prasanta.
I am not an expert in this code, but a few notes.
- The main question is: is a problem in the Windowed flag or in the
method D3DContext::ConfigureContext which treats non-/windowed windows
in different way.
- Is the changes in the D3DGraphicsDevice.java were made
intentionally,
Hi, Vadim.
Thanks for clarification, please add this information as a comment to
the code, before the push.
On 08.05.15 16:19, Vadim Pakhnushev wrote:
It's invisible and used only for getting application focus
notifications internally by Direct3D.
On 08.05.2015 16:14, Sergey Bylokhov wrote
Hello.
Please review the fix for a typos in jdk9. This CR was filed by me long
time ago and I doubt that someone will take a look at it.
I fixed all clients files in sun.** subpackages.
Bug: https://bugs.openjdk.java.net/browse/JDK-6587235
Webrev can be found at:
Hi, Vadim.
Why we do not use the full screen size for this window?
On 08.05.15 14:07, Vadim Pakhnushev wrote:
Hi,
Please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8079652
Focus window's client area should be bigger otherwise CreateDevice fails.
diff --git
value.
52 */
53 public DialogOwner(Frame frame) {
Huh ? The entire doc seems to be nonsense .. changing the name of the
param
just makes it worse. The text seems to have been copied from
javax.attribute.standard.DialogTypeSelection.java
-phil.
On 05/08/2015 12:25 PM, Sergey
Hi, Prasanta.
The same approach was used in OGL pipeline for the reason. Because we
use glReadPixels and there is no way to apply the clip. So we read
pixels to the temporary buffer and apply the clip later. Can you
additionaly investigate is it possible to apply the clip in d3d directly
or
Hi, Alexander.
I assume that the code in SG2D.getTransform/setTransform is the same as
was before the fix of 8000629.
Code in SG2D.getDefaultTransform can be simplified, id do not think that
GraphicsConfiguration.getDefaultTransform. and
SG2D.getDeviceConfiguration can return null for
Looks fine.
On 17.04.15 22:27, Phil Race wrote:
http://cr.openjdk.java.net/~prr/8076979/
https://bugs.openjdk.java.net/browse/JDK-8076979
-phil.
--
Best regards, Sergey.
Hi, Phil.
The fix looks good. But probably we can rename MFontConfiguration since
dependency on motif was removed?
On 26.03.15 1:48, Phil Race wrote:
Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
- removed the jdk.charsets export to java.desktop from modules.xml
- removed the
Looks fine.
On 03.06.15 22:54, Andrew Brygin wrote:
looks fine to me. Sorry for the mess...
Thanks,
Andrew
03/06/15 22:53, Phil Race пишет:
Sigh ..
I use xcode 4.x still for building JDK 9 - and it appears I have run
into this
and you can't disable it as I can a warning.
I filed
Hello.
Please review the small fix for jdk9.
Two simple warnings were fixed.
The fix contributed by Staffan Larsen.
Bug: https://bugs.openjdk.java.net/browse/JDK-8080993
Webrev can be found at: http://cr.openjdk.java.net/~serb/8080993/webrev.00
--
Best regards, Sergey.
Hi, Mario.
The fix looks good.
On 05.06.15 18:51, Phil Race wrote:
Not sure I count since I proposed the change but +1 anyway :-)
-phil.
On 06/04/2015 02:55 AM, Mario Torre wrote:
Hello all,
This patch should fix the issue mentioned in the bug report:
Looks fine.
On 05.06.15 18:43, Phil Race wrote:
+1
-phil.
On 06/05/2015 07:36 AM, Andrew Brygin wrote:
Hello Sergey, and Phil,
could you please review a fix for CR 8085910?
Bug: https://bugs.openjdk.java.net/browse/JDK-8085910
Webrev: http://cr.openjdk.java.net/~bae/8085910/9/webrev.00/
Hi, Andrew.
Can you additionally provide the bench data about aa(before/after the
fix) vs new lcd lcd?
Probably it well be more obvious if the code in OGLTextRenderer
1007 if (OGLC_IS_CAP_PRESENT(oglc, CAPS_EXT_TEXBARRIER)
1008 dstOps-textureTarget == GL_TEXTURE_2D)
Will be moved
Looks fine.
On 10.06.15 23:25, Phil Race wrote:
Andrew/Sergey,
Could one of you please be a 'sanity check' backport reviewer on
this backport of a missing check for NULL in LittleCMS code.
It is identical to the JDK 9 changeset : -
http://hg.openjdk.java.net/jdk9/client/jdk/rev/80e814d165f9
Hello.
Please review the fix for jdk9.
The reason of the removing is a general deprecation of pbuffers, and a
lack of their support in the java2d, because for a long time pbuffers
were not used by default.
Attempts to disable FBO(which are used by default), and enable the
pbufferes will cause
Hello,
Any volunteers to review the fix?
On 08.06.15 19:52, Sergey Bylokhov wrote:
Hello.
Please review the small fix for jdk9.
Two simple warnings were fixed.
The fix contributed by Staffan Larsen.
Bug: https://bugs.openjdk.java.net/browse/JDK-8080993
Webrev can be found at:
http
101 - 200 of 1345 matches
Mail list logo
