Bug 1379 - NewtCanvasAWT in JSplitPane on macOS
Summary: NewtCanvasAWT in JSplitPane on macOS
Status: CONFIRMED
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: tbd
Hardware: All macosx
: P4 normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2019-04-25 10:11 CEST by Bogdan Nicula
Modified: 2023-02-25 18:24 CET (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments
Test program showing the problem. (2.37 KB, text/plain)
2019-04-25 10:11 CEST, Bogdan Nicula
Details
Screenshot showing the difference between macOS and Linux. (110.52 KB, image/png)
2019-04-25 10:13 CEST, Bogdan Nicula
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bogdan Nicula 2019-04-25 10:11:35 CEST
Created attachment 813 [details]
Test program showing the problem.

If the canvas is the top component, it is not well resized when moving the divider of a vertically split JSplitPane. A similar situation occurs when the canvas is the right component in a horizontally split JSplitPane.

This appears only on macOS, Java versions 8-13.

First reported at http://forum.jogamp.org/NewtCanvasAWT-in-JSplitPane-on-macOS-td4039717.html

Attached a small program to reproduce the behavior.
Comment 1 Bogdan Nicula 2019-04-25 10:13:28 CEST
Created attachment 814 [details]
Screenshot showing the difference between macOS and Linux.
Comment 2 Bogdan Nicula 2019-04-25 10:18:52 CEST
So, my investigation led me to believe the culprit is the code dealing with `superlayer` in fixCALayerLayout() of OSXmisc.m (in jogl/src/nativewindow/native/macosx). Commenting the whole block fixed the symptom.

That code was introduced by 9a8f9b9f7e6148b60b6f0f4326df8d213774284c in response to bug 816. My suspicion is that there is something wrong with the calculation of the origin of those frames.
Comment 3 Sven Gothel 2019-08-20 20:10:24 CEST
(In reply to Bogdan Nicula from comment #2)
> So, my investigation led me to believe the culprit is the code dealing with
> `superlayer` in fixCALayerLayout() of OSXmisc.m (in
> jogl/src/nativewindow/native/macosx). Commenting the whole block fixed the
> symptom.
> 
> That code was introduced by 9a8f9b9f7e6148b60b6f0f4326df8d213774284c in
> response to bug 816. My suspicion is that there is something wrong with the
> calculation of the origin of those frames.

Thank you for your detailed report, hence confirmed.

I need to see whether I find time to check this for 2.4.0.
In case you have a regression free patch, please post.