On 11/30/2016 2:11 AM, Jim Graham wrote:
I agree that the two versions of the paintDoubleBuffered functions
look like they may not have any noticeable performance difference. It
would be nice to avoid the duplication if they don't, I had assumed
that such a performance test had already been do
I wouldn't necessarily recommend Area as the replacement. It's designed for complicated path intersection, not as an
optimal path storage mechanism.
Also, since the constraint has to be installed on every repaint, re-rasterizing the shaped boundary on every repaint
could potentially impact per
On 30.11.16 2:11, Jim Graham wrote:
- Region.getScaledRegion() - this method should be deleted. I think it
is only used in SG2D.constrain() which needs to be rewritten as you
cannot scale a region and expect any amount of accuracy, but we live
with it for now until a better fix comes along. I d
These results are good. I'm for simplifying as well...
...jim
On 11/30/16 3:57 PM, Sergey Bylokhov wrote:
On 29.11.16 20:46, Alexandr Scherbatiy wrote:
The result of running SwingMark 2 with the following JDK is:
1. without the fix
1st test run [1]: 92373
2
On 29.11.16 20:46, Alexandr Scherbatiy wrote:
The result of running SwingMark 2 with the following JDK is:
1. without the fix
1st test run [1]: 92373
2nd test run [2]: 92156
average: (92373 + 92156) / 2 = 92264.5
2. paintDoubleBufferedImp() method is always used
1st test ru
I've filed JDK-8170514 to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8170514
...jim
On 11/29/16 10:11 PM, Jim Graham wrote:
I took another look at the use of clipScale/clipRound in the SG2D.drawHiDPI
method.
The sub-image parameters are given relative
I took another look at the use of clipScale/clipRound in the SG2D.drawHiDPI
method.
The sub-image parameters are given relative to the base image and the intention (ignoring scaling and DPI variants) is
to extract those complete pixels from the (base) source images and do the rendering operatio
I agree that the two versions of the paintDoubleBuffered functions look like they may not have any noticeable
performance difference. It would be nice to avoid the duplication if they don't, I had assumed that such a performance
test had already been done...?
clipRound() has appropriate logic
On 11/24/2016 7:40 PM, Sergey Bylokhov wrote:
I have a few questions which probably discussed already, then ignore it:
- SunGraphics2D.java: As far as I understand the clipScale() was
replaced by clipRound(), because they have different round logic? It
seems that when I wrote the clipScale()
I have a few questions which probably discussed already, then ignore it:
- SunGraphics2D.java: As far as I understand the clipScale() was
replaced by clipRound(), because they have different round logic? It
seems that when I wrote the clipScale() I was not aware about round
logic, and looks l
Hi Alexandr,
Looks fine. +1
...jim
On 11/21/16 5:59 AM, Alexandr Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8162350/webrev.04
- isFloatingPointScale(AffineTransform) is moved from the SunGraphics2D to the
Swing
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8162350/webrev.04
- isFloatingPointScale(AffineTransform) is moved from the
SunGraphics2D to the SwingUtilities2 class.
Thanks,
Alexandr.
On 11/18/2016 11:23 PM, Jim Graham wrote:
Hi ALexandr,
This looks g
Hi ALexandr,
This looks great.
BTW, when I suggested moving the FPscale test into SG2D I was suggesting that to avoid having to copy the transform out
of it via getTransform(), but you've found a different solution to that issue (i.e. the new getTransform(g) method) so
it no longer matters whe
Thank you. I see that using the integer device-pixel translations
preserves the component painting in the same way for floating point scales.
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8162350/webrev.03
- translation adjustment is removed
- Region.clipRound()
Let me clarify something...
On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Let's consider the following use case:
scale = 1.5
A component calls fillRect(1, 1, 1, 1).
This is (1.5, 1.5, 3.0, 3.0) in the device space
which fills (1, 1, 3, 3) and covers 2x2 pixels
Agreed.
Now the
On 11/15/16 2:49 AM, Alexandr Scherbatiy wrote:
Were you seeing that happen? Because that would be a rendering bug in
fillRect...
Let's consider the following use case:
scale = 1.5
A component calls fillRect(1, 1, 1, 1).
This is (1.5, 1.5, 3.0, 3.0) in the device space
which fills
On 11/15/2016 2:44 AM, Jim Graham wrote:
I want to clarify the following issue...
On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote:
Using floating point scale leads that drawing the same thing from
different coordinates gives different results. For example filling a
rectangle with size (1, 1)
I want to clarify the following issue...
On 10/24/2016 9:11 AM, Alexandr Scherbatiy wrote:
Using floating point scale leads that drawing the same thing from
different coordinates gives different results. For example filling a
rectangle with size (1, 1) from location (0, 0) and UI scale 1.5 giv
Hi Alexandr,
On 11/14/2016 7:51 AM, Alexandr Scherbatiy wrote:
The current fix tries to adjust the component translation to a value
which allows to draw a component in the same way when floating point
scale is used.
The scale is converted to the irreducible fraction n / m where m is
the step
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8162350/webrev.02
The previous fix renders the dirty region to the backbuffer from the
same (x, y) coordinates where it should be repainted.
The JScrollPane can have large (x, y) values which can exceed the
do
Is SunGraphics2D accessible from Swing? If so, then I'd recommend
putting the isFPScale() method right on that class so we don't have to
clone the transform by calling g.getTransform(). Also note that
g.getTransform() does more than clone the transform as it has to factor
out the constrainXY
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8162350/webrev.01
- JScrollPane copy area functionality is disabled for floating point
scale
- VolatileImage buffer size is recalculates using transform translate
Using floating point scale leads that d
On 10/6/2016 11:42 PM, Sergey Bylokhov wrote:
Hi, Alexandr.
Can you please provide some standalone small example, which emulates
this artifacts via java2d API. (The pattern which we use in
RepainManager). It will help to understand the problem.
The code sample [1] draws two the same shapes (
Hi Alexandr,
Is the fully scaling code noticeably slower than the regular code? Is there a reason to test and only use it
conditionally? It shouldn't be a lot of overhead considering everything else that goes on during a repaint. Some of
the set/unset of attributes could also be optimized ar
Hi, Alexandr.
Can you please provide some standalone small example, which emulates
this artifacts via java2d API. (The pattern which we use in
RepainManager). It will help to understand the problem.
On 06.10.16 20:07, Alexandr Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https:/
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8162350
webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00
The fix uses the solution suggest by Jim in the email:
http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html
To draw to a
26 matches
Mail list logo
