Re: Glass Robot and getSCreenCapture
Hi David, sorry to keep you waiting with an answer from Embedded SQE. I assume there will be no major impact on SQE since as you told and it is true, most golden image tests we have are based on a window content. Anyway from what I understood your implementation will be easily rolled back if we reveal some unexpected impact on tests, right? 26.03.2014 23:03, David Hill ?: On 3/26/14, Mar 26, 12:53 PM, Stephen F Northover wrote: I don't like implied contract code either but I also don't like exceptions for cases like this. I would prefer that we return zero for pixels that are unspecified as this seems better than testing screen bounds (which can get you in trouble on multi-display monitors). Anyway, to fix this involves writing a test case that we can run on all platforms in a multi-monitor scenario. Also, the primary monitor can be on either the left or the right and this might affect the result. It's easier to fix this in Java code by testing screen bounds as you were doing and throw the exception. Since this is not API and we need to move on, then we could do this (and possibly break SQE). Alternately, we can construct the test cases, see if the platforms/glass already return zero and assess where to go next. Whatever happens, we need a test case. Is there one in the JIRA? If so, I can run it on the desktop platforms and let you know the results for the current code base. As much as I don't like it - I am no longer sure there is a reasonable pre-test that can be done. I suggested a four corner test, but in the case of two adjacent screens of different heights, it is reasonable to see that you could ask for bounds that would put 3 corners in, and one out (hopefully the asci art will work): +++ ||| ||| ||| ++| || ++ For a one shot screen capture - we would pass in top left and width and height to make the bottom right. Currently this should work on Mac I am told, though what is in the out of bounds pixels is not known. And if we added a third tall screen to the left, life gets even more complicated :-( I was hoping to simplify the native impl for ARM by making it impossible to have an out of bounds pixel. This thought was in line with other API - check for valid values before calling the impl. We still could, but in the above case, there would not be a way to get all the screen in one shot. I really don't think we should be having a major impact on SQE, as I would think that most golden image tests will be based on checking known things - like the content of a window. But ... I have erred recently in the past on this subject... :-) The test case I have been using is in HelloSanity. It is well behaved. It is only one of 2 apps in our repo that perform any screen captures (an the other was used as the basis for HelloSanity). There are some uses of getPixel(x,y) which is a variation. I found the problem in the ARM code by inspection, and have yet to write a reasonable test app that includes the aprox 6-8 variations of overlap (ie, full subset, off left, off right, completely missing up, .) I certainly can throw together something that will try some of the variations to see if we fail on other platforms. Given my current understanding of the problem though, I really don't see how a pre-verification of the bounds can be done. -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
Platform.isSupported behavior
Hello, Lately I have faced a strange behavior while I was using JavaFX Embedded and touch screen. As far as I understand there is no spec where I can find this information, that is why I decided to ask the community. I have developed a simple application with one text field and a button. I run it using JavaFX Embedded runtime with LCD+touch monitor connected to an abstract board. As a result I can see touch mode in the application, the virtual keyboard and other touch features. However if I plug out the touch part, connect mouse, at the runtime, the application does not change its appearance and behavior, the vk is still available with all touch features. So only restart of the application disables touch mode. I know that there is Platform.isSupported method to detect different states, and touch is one of them. So I have checked, that, when I during the runtime plug in/out touch and press the button to check Platform.isSupported value, I can see it changes every time I plug in/out the touch screen. I assume it happens, because every time I call Platform.isSupported the real check is being performed and because of that its value changes. But once again, there is no spec to check it. I have a proposal: * what if there will be some kind of listener to handle state changes * add this listener to the controls where they ask Platform.isSupported to make controls change their appearance and behavior * disable caching of the state in the platform(lens, quantum) * create specification where the realization will be described -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
Re: Platform.isSupported behavior
Hi Daniel, about caching, I placed it in the list, because there is no spec telling about it, and anyone can add/remove it, that why it is an object of concern. It will be great to hear from Controls team, cause from my point of view, dynamical change of controls behavior will improve usability. Talking about ObservableBooleanValue, nice idea, I think it will be really better, than having boolean return value. Are you going to implement it? 19.11.2013 13:32, Daniel Blaukopf ?: Hi Stas, Yes, you have a good point here. The behavior you are seeing is what I would expect, but I agree we could do better in how we specify this. Currently, * States reported by Platform.isSupported are updated when input devices are added and removed * Controls check the connected input devices at startup time. They do not change their behavior on the fly as input devices are added and removed. Enabling listening to state changes certainly makes sense - probably by defining state in ObservableProperties. I’m not sure we actually want controls to reconfigure themselves dynamically and automatically though. Maybe someone working on controls can comment on this, but it seems like it would be a complex transition with many edge cases to deal with. Why change caching of input device state in Lens and Quantum though? Lens needs to cache the state of input devices in order to be able to report on what input features are available. I’m not sure Quantum is doing any caching of this state at all - as far as I know it is going directly to Glass to query input device features. Controls do of course cache input device state. A thought about API for listening to state changes. What if we added an API to Platform like Platform.isSupported that instead of returning a boolean returned an ObservableBooleanValue? This listener would never be notified on conditional features like EFFECT or SCENE3D but would be notified on those conditional features that reflect input device state. Thanks, Daniel On Nov 19, 2013, at 10:09 AM, Stas Smirnov stanislav.smir...@oracle.com mailto:stanislav.smir...@oracle.com wrote: Hello, Lately I have faced a strange behavior while I was using JavaFX Embedded and touch screen. As far as I understand there is no spec where I can find this information, that is why I decided to ask the community. I have developed a simple application with one text field and a button. I run it using JavaFX Embedded runtime with LCD+touch monitor connected to an abstract board. As a result I can see touch mode in the application, the virtual keyboard and other touch features. However if I plug out the touch part, connect mouse, at the runtime, the application does not change its appearance and behavior, the vk is still available with all touch features. So only restart of the application disables touch mode. I know that there is Platform.isSupported method to detect different states, and touch is one of them. So I have checked, that, when I during the runtime plug in/out touch and press the button to check Platform.isSupported value, I can see it changes every time I plug in/out the touch screen. I assume it happens, because every time I call Platform.isSupported the real check is being performed and because of that its value changes. But once again, there is no spec to check it. I have a proposal: * what if there will be some kind of listener to handle state changes * add this listener to the controls where they ask Platform.isSupported to make controls change their appearance and behavior * disable caching of the state in the platform(lens, quantum) * create specification where the realization will be described -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia -- Best regards, Stas Smirnov Stas Smirnov | Java Embedded Phone: +7 812 3346130 | Mobile: +7 921 9262241 Oracle Development SPB, LLC 10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
