Integrated: 8281033: Improve ImageCheckboxTest to test all available LaF
On Fri, 11 Feb 2022 10:47:41 GMT, Alexander Zuev wrote: > Test modified to perform test on all available LaF's > During test development bug similar to JDK-8216358 was found in Nimbus and > GTK+ LaFs > so exceptions were added and separate bugs were created to track these LaFs. This pull request has now been integrated. Changeset: aa918a6e Author:Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/aa918a6ec4cd1356efd481c6f6fa94959f94f7b3 Stats: 49 lines in 1 file changed: 38 ins; 1 del; 10 mod 8281033: Improve ImageCheckboxTest to test all available LaF Reviewed-by: serb - PR: https://git.openjdk.java.net/jdk/pull/7439
Integrated: 8274939: Incorrect size of the pixel storage is used by the robot on macOS
On Fri, 8 Oct 2021 10:23:13 GMT, Sergey Bylokhov wrote: > In JDK 9 the native code for the robot class was reworked to get an access to > the HiDPI quality screenshots. So we allocate the data storage for the HiDPI > quality and then request the best quality from the macOS. > > It works fine if the user request the screenshot of some area, since we > properly scale this area. Unfortunately it does not work well if the user > request only one pixel, in this case we allocate the array of one element and > does not multiply the size by the scale, so if the system scale is 2 then the > macOS returns the 2x2 pixels, which does not fit properly to the array of one > element. This can be checked by the Xcheck:jni option which produce fatal > error in this case. > > Solution is to allocate the storage of the proper size 1 * scale * 1 * scale This pull request has now been integrated. Changeset: eff5dafb Author:Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/eff5dafba9f72bd0612357712ffa472ce1c9166a Stats: 12 lines in 3 files changed: 7 ins; 0 del; 5 mod 8274939: Incorrect size of the pixel storage is used by the robot on macOS Reviewed-by: aivanov, prr - PR: https://git.openjdk.java.net/jdk/pull/5864
Re: Area#add(Area) Optimization
I suppose this could be added but it is something an application also
can easily do for itself.
> curves = rhs.curves;
The straight reference, rather than a copy surprised me, but I suppose
(I am not familiar
with the working of the Area class) that all mutations must create a new
Vector ...
-phil.
On 2/11/22 3:51 PM, Jeremy Wood wrote:
I’m working a lot with the Area class lately. Is there any interest in
the following optimization?
Area#add(Area) currently resembles:
public void add(Area rhs) {
curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
invalidateBounds();
}
I propose replacing it with:
public void add(Area rhs) {
if (isEmpty()) {
curves = rhs.curves;
} else if (rhs.isEmpty()) {
return;
} else {
curves = new AreaOp.AddOp().calculate(this.curves, rhs.curves);
}
invalidateBounds();
}
If either operand is empty then this is effectively a null op. But the
current implementation may still take several seconds to return
depending on the complexity of the non-empty operand.
For example the following two snippets of code may have significantly
different execution times:
Area sum = new Area();
for(Shape shape : incomingShapes) {
sum.add(new Area(shape));
}
vs
Area sum = new Area(shapes.get(0));
for(int a = 1; a < incomingShapes.size(); a++) {
Shape shape = incomingShapes.get(a);
sum.add(new Area(shape));
}
And similarly we could review the other operations
(subtract/intersect/exclusiveOr/transform) for obvious potential null
ops.
If I understand openjdk rules correctly: I'm not authorized to submit
an openJDK ticket. Does this interest anyone else on this list enough
to submit this as an openJDK ticket? (I'm happy to work on it if I can
help.)
Regards,
- Jeremy
