Hi, Jim.
Can you please clarify why the exact pixels copyarea is necessary(As
well as the problem in RepaintManager) I am not sure it is clear why we
need to do something in the users space in floats. I mean that all our
Swing components uses int(units) as bounds, all of them uses integers as
Yes, most likely. It involves making sure that the origin of the viewport is always an even multiple of pixels, then
the copyArea will match up with the repainting. The damage repair messages here have already pointed out how to deal
with making sure the repaints are on integer coordinates, the
Ah, I see.
There are a lot of mistaken assumptions in the rendering there. It's not just line thickness, it is assumptions about
stroke control and positioning of strokes.
The biggest issue seems to be that developers (including our own internal Swing developers who heard this lecture from
m
I've also had a suggestion to be more succinct and just add one line :
"Glyphs may not always be rendered with the requested properties (e.g,
font and style)
due to platform limitations such as absence of certain fonts".
I'd be OK with either my wording or the above ..
-phil.
On 10/05/2016 04
On 06.10.16 16:24, Sergey Bylokhov wrote:
Immediately after I sent a message I realized that we had similar
discussion about clip already.
It seems this is the same bug as discussed here:
http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html
And those solution fix this bug as well.
Immediately after I sent a message I realized that we had similar
discussion about clip already.
It seems this is the same bug as discussed here:
http://mail.openjdk.java.net/pipermail/2d-dev/2016-July/007299.html
And those solution fix this bug as well. I will file a separate bug and
send a re
hi, Jim.
Can you please take a look to the small example(attached) which was
created by Alex.
The test uses 3 operations: fillRect, drawImage, drawRect.
Each time we draw something to the left rectangle [0,0,w,h] and to the
right rectangle[w,0,w,h].
I can understand why fillrect draw the shapes
Hi all,
On 04 Oct 2016, at 23:28, Jim Graham wrote:
>
> On 10/4/16 1:01 PM, Anton Tarasov wrote:
>> Anyway, I roughly tried your approach mentioned in the previous e-mail, but
>> forcing RM to paint via offscreen
>> BufferedImage, not volatile (just for a quick check).
>> It solved the shift is
> On 04 Oct 2016, at 23:22, Jim Graham wrote:
>
> On 10/4/16 1:01 PM, Anton Tarasov wrote:
>>> - Simply ask for a large enough integer to make sure you got the entire
>>> clip to fit in it and let the allocator give
>>> you an even larger image. It doesn't matter if you paint into a larger
>>>
Looks OK to me.
Regards,
Ajit
From: Philip Race
Sent: Wednesday, October 05, 2016 9:49 PM
To: Jayathirth D V
Cc: 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call
made whilst holding JNI critical lock.
+1
-phil.
On 9/29/16, 1:49 AM, Jayathirth D V w
Hi Phil,
As discussed offline, I have updated test case to include check for duplication
of compression types for all ImageIO plugins.
Please review the updated webrev at your convenience :
http://cr.openjdk.java.net/~jdv/6294607/webrev.01/
Thanks,
Jay
From: Jayathirth D V
Sent
11 matches
Mail list logo
