Ignore that last question - I just realized that you already answered
it, my apologies...
...jim
On 10/15/15 3:18 PM, Jim Graham wrote:
Chien pointed out a system property that is currently disabling the
scrolling optimization. For its implementation look at
CacheFilte
Chien pointed out a system property that is currently disabling the
scrolling optimization. For its implementation look at
CacheFilter.java, in particular the invalidateByTranslation() method and
all that it kicks off.
Another thing to look at is that we added alpha batching to the code
whic
Hi Johan,
This optimization is buggy but to see whether it helps you can try setting
-Dprism.scrollcacheopt=true
Please see JDK-8093860 for reason why it was disabled:
https://bugs.openjdk.java.net/browse/JDK-8093860
- Chien
On 10/15/15, 12:30 PM, Johan Vos wrote:
Thanks Jim.
I tried with di
At least on the Nexus 5 and Nexus 6 devices.
- Johan
On Thu, Oct 15, 2015 at 9:33 PM, Richard Bair
wrote:
> Is it consistent among all android devices, or is it a specific device?
>
> > On Oct 15, 2015, at 12:30 PM, Johan Vos wrote:
> >
> > Thanks Jim.
> > I tried with different optimization f
Is it consistent among all android devices, or is it a specific device?
> On Oct 15, 2015, at 12:30 PM, Johan Vos wrote:
>
> Thanks Jim.
> I tried with different optimization flags, but it doesn't make a big
> difference. Tracing it down to system calls, somehow the gl implementation
> seems be
Thanks Jim.
I tried with different optimization flags, but it doesn't make a big
difference. Tracing it down to system calls, somehow the gl implementation
seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3,
GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per
invocation
Perhaps optimization flags with the native compiler? Also, was it
called a similar number of times on both?
Ideally we'd just be using copyArea for the scrolling, but at one point
we disabled the scrolling optimizations on retina MBP because they
didn't work with a scale factor and I don't th
Hi Werner,
The event is first considered for the ListCell, so when the filter on
ListView would be called, it is already too late.
- Johan
On Thu, Oct 15, 2015 at 4:37 PM, Werner Lehmann <
lehm...@media-interactive.de> wrote:
> Hi Johan,
>
> wouldn't it be possible to use an event filter on the
Is it a bug ? or what? Could someone help me for this issue?
Thanks.
2015-10-06 22:27 GMT+03:00 Rahman USTA :
> Hello;
>
> Some of Mac users are facing with following problem. What can be the
> reason? Thanks.
>
> Hello I have
>
> Software OS X 10.8.5 (12F2560)
> Java 8 U 60
> I just have instal
Jonathan and Kevin,
Please review this simple fix to DragEvent.java. It uses the existing
template for the acceptingObject and has been tested on Mac and Windows.
Thanks much,
--morris
BUG - https://bugs.openjdk.java.net/browse/JDK-8088993
WEBREV - http://cr.openjdk.java.net/~morris
Hi Johan,
wouldn't it be possible to use an event filter on the listview? It would
see (and consume) the event before it even gets to the listcell.
Werner
On 06.10.2015 10:02, Johan Vos wrote:
So it seems to me we need something like "gestureTransparent", by which we
can indicate a Node not
After spending lots of time optimizing JavaFX on iOS, I am now at the point
where scrolling is 10 times faster on iOS than on Android.
The scrolling in the iOS version of the Gluon JavaOne mobile schedule
builder is pretty good imho. On Android, it is much slower. I profiled and
compared both, and
12 matches
Mail list logo
