Thanks a lot, Jim! This sheds light on the subject and really sounds
promising.
Anton.
On 10/6/2016 9:31 PM, Jim Graham wrote:
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 s
One issue is that the JViewport lastPaintPosition is exposed to subclasses and is an integer location. It is also
exposed to all apps via getViewPosition() and getViewRect(). That will conflict with indicating the exact location of
the pixel-precise scroll position. It's not clear how these wi
Aren't the components inside the scrollpane located relative to the origin of the entire scrollable region? In which
case, the precise location of the visible part of the view has no effect on any component bounds...?
...jim
On 10/6/16 5:59 PM, Sergey Bylokhov w
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
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
>>>
Hi Sergey,
I'd be interested in the details of that analysis. Are you saying that drawImage can violate the clip? That would be a
big problem if true.
I looked at the clip validation code and did spot an issue. When the clip is a Rectangle2D or a transformed Rectangle
(which produces an R2
Looking to this bug I found something new for me. At least rounding of
the image is non-intuitive. Usually our animation is a sequence of
draw/drawImage+fillRect/clearRect. But in case of fractional scale we
transform drawImage and fillRect differently, which can cause some
artifacts, because d
On 10/4/2016 11:30 PM, Jim Graham wrote:
I wasn't familiar with the test code for this particular case. Is it
in a bug report somewhere?
Jim, I'm re-attaching it (it was in my first e-mail).
Thanks,
Anton.
...jim
On 10/4/16 1:01 PM, Anton Tarasov wrote:
Also, the problem with p
I wasn't familiar with the test code for this particular case. Is it in a bug
report somewhere?
...jim
On 10/4/16 1:01 PM, Anton Tarasov wrote:
Also, the problem with primitives rendering
(http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is
still
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 issue of the demo listed in 8162350, which is cool. It also
solved the
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 image
(other than having to allocate an extra
row/column on occasi
Hi Jim,
On 10/4/2016 1:05 AM, Jim Graham wrote:
Hi Anton,
Yes, the numbers you are describing are consistent with performing
that standard boilerplate using an origin/translate that is not
exactly at an integer pixel location.
My comments about our mechanisms not allowing for scale-aware
a
Hi Anton,
Yes, the numbers you are describing are consistent with performing that
standard boilerplate using an origin/translate that is not exactly at an
integer pixel location.
My comments about our mechanisms not allowing for scale-aware
allocations can be dealt with in a couple of ways:
Hi Jim,
Thank you for the details! This gives a clue.
Anton.
On 10/2/2016 10:10 PM, Jim Graham wrote:
After looking into the code in RepaintManager and re-reading
Alexander's message again I can see how it describes what is going on
more clearly.
Fixing the rounding errors doesn't necessari
Hi Alexandr,
I looked at the testcase 8162350 closely and found your explanation
below not quite precise...
When you repaint a letter with an slightly expanded dirty rect, you've
got it as [40-1, 0-1, 80+2, 60+2] = [39, -1, 82, 62]. Let's count only "x".
As Jim noted, the code to draw is:
/
After looking into the code in RepaintManager and re-reading Alexander's
message again I can see how it describes what is going on more clearly.
Fixing the rounding errors doesn't necessarily require avoiding use of
the intermediate image for damage repair, you just have to make sure
that you
On 9/30/16 3:22 AM, Alexandr Scherbatiy wrote:
The problem is that the RepaintManager draws a region to a buffered image at
first and draws the image after that to the
window.
Suppose the image has int coordinates and size (x, y, w, h) in the user space.
It should be drawn into the region wit
Hi Alexandr,
> On 30 Sep 2016, at 13:22, Alexandr Scherbatiy
> wrote:
>
>
> Hello Anton,
>
> Yes, we are working on it.
>
> For example, there is the known issue DK-8162350 RepaintManager shifts
> repainted region when the floating point UI scale is used.
> https://bugs.openjdk.java.net/b
Hello Anton,
Yes, we are working on it.
For example, there is the known issue DK-8162350 RepaintManager shifts
repainted region when the floating point UI scale is used.
https://bugs.openjdk.java.net/browse/JDK-8162350
The problem is that the RepaintManager draws a region to a buffered
im
Hello,
JDK9 comes with HiDPI support on Windows/Linux which is really great. As
we gave it a try, we found it looking pretty good with an integer scale
(2x) but revealed some rendering flaws with float scales.
Let me please demonstrate it with SwingSet2 + JDK9-ea-b137 + Windows 8.1
in 150% s
26 matches
Mail list logo
