Re: RFR: 8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen
On Fri, 18 Feb 2022 17:04:08 GMT, Alexander Scherbatiy wrote: > Zoomed/Rotated with two fingers rectangle flickers (unexpectedly becomes > pretty small or large and then returns back to previous size several times > during zooming/rotating) on a Raspberry Pi with Touchscreen. > > The log with traced events shows that it is possible that only one > ABS_MT_POSITION_X or ABS_MT_POSITION_Y can be sent for a given slot. In this > case the corresponding omitted Y/X value is undefined and is assigned from > ABS_Y/X value. This produces incorrect result for slots different from 0. > > Example of the trace events log, enabled by > `-Dmonocle.input.traceEvents.verbose=true -Dmonocle.input.traceEvents=true` > flags: > > traceEvent: Processing EV_ABS ABS_MT_SLOT 1 [index=48] > traceEvent: Processing EV_ABS ABS_MT_TRACKING_ID 302 [index=64] > traceEvent: Processing EV_ABS ABS_MT_POSITION_X 399 [index=80] > traceEvent: Processing EV_ABS ABS_MT_POSITION_Y 272 [index=96] > traceEvent: Processing EV_KEY BTN_TOUCH 1 [index=112] > traceEvent: Read EV_ABS ABS_MT_SLOT 0 [index=176] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 315 [index=192] > traceEvent: Read EV_ABS ABS_Y 315 [index=208] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=224] > > ... > > traceEvent: Read EV_ABS ABS_MT_SLOT 1 [index=320] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 271 [index=336] > traceEvent: Read EV_ABS ABS_X 552 [index=352] > traceEvent: Read EV_ABS ABS_Y 322 [index=368] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=384] > > First both ABS_MT_POSITION_X/Y events with values x: 399 and y: 272 are > received for the slot 1. > Next only ABS_MT_POSITION_Y with y: 271 value is received (which implies that > the x value has not been changed) for the slot 1. > The x value is undefined in the > LinuxStatefulMultiTouchProcessor.processEvents() loop and is unexpectedly > assigned to the ABS_X 552 value which belongs to the slot 0. > > The fix skips setting ABS_X/Y values for slots different from 0. The fix also fixes the first use case described in the JDK-8087370 1. Consider you're touching the screen with two fingers, for example coordinates of one point is ~100,100 and second point is ~200,200. While still touching around the same points some events are reported with one or another point to be either 100,200 or 200,100. - PR: https://git.openjdk.java.net/jfx/pull/737
Re: RFR: 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v4]
On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote: >> @johanvos >> As requested, we've made a unit test, which tests this bug. >> It's based on your test and our original test class. It can be added to the >> ListViewTest. >> You can find it, in the JDK ticket. >> >> Btw, adding the cells incrementally seems to make a difference - which is >> why the new test class tests both cases. >> >> It accepts various inputs of cell sizes - and should work with any inputs. >> It should catch all the cases from the original test class. >> Because it works with all possible inputs - one could even make a random >> test-cases generator to make sure it works in every case. >> >> It basically only works well, when the sizes are only 20s - in most other >> cases it fails. > > The later reported issues were due to the fact that the estimatedSize got > updated during the layoutChildren call. That makes things much more > complicated and leads to discrepancies. I disabled the updates to the > estimated size during the layoutChildren call, so that all operations that > are happening in that call are using a consistent value of the estimated > size. We now pass all the tests added by @FlorianKirmaier on the JBS issue . > Those tests are great regression tests. Hi @johanvos, I've updated the TestClass once more. You can find it on the ticket. There are 2 cases that seem to not work properly yet. 1.) If the elements are very big, the tests seem to fail - but it only happens if the scene is layouted again. 2.) On Click, the element gets selected and the VirtualFlow "jumps around". I've adapted the tests to simulate the click with the selectionModel. I've also added another assert, to check whether our cell is visible - which seems to be not always the case. Both cases were also reproducible with the original test application. Btw, can I somehow become an official reviewer for this PR? - PR: https://git.openjdk.java.net/jfx/pull/712
