About the closest thing we have right now is the cacheHints which let you specify that
you want to allow the cache to be scaled, but no ability to specify by how much before
we re-render. We've felt that mechanism needs to be eventually be evolved to allow more
customization, but we haven't
Hi Felipe,
The changes look good...
...jim
On 11/6/13 3:06 PM, Felipe Heidrich wrote:
Hi Jim,
Please review
https://javafx-jira.kenai.com/browse/RT-34090
http://cr.openjdk.java.net/~fheidric/RT34090/webrev/
Thanks
Felipe
Hi Felipe,
That looks fine - was there a reason to have the variable to store the
predetermined border size?
...jim
On 11/4/13 4:55 PM, Felipe Heidrich wrote:
Hi Jim
Please review
https://javafx-jira.kenai.com/browse/RT-32837
You will find the webrev at the end:
. Always calculate the stroke bounds
as if the shape will be stroked, so it doesn't affect Canvas.
If you don't want that to affect the bounds used for a gradient fill when you
aren't stroking, set the stoke width to 0.
Scott
On Nov 18, 2013, at 5:58 PM, Jim Graham james.gra...@oracle.com wrote
, Jim Graham james.gra...@oracle.com wrote:
Hi Scott,
That's an odd take on it. It wouldn't be readily obvious to a developer why
their background rectangle had the gradient a little off if they never planned
to ever stroke it.
Also, keep in mind that while it might be slightly more expensive
I'm only occasionally skimming this thread so I hope I don't disrupt
discussions by throwing in a few observations now and then...
On 11/20/2013 7:30 AM, Assaf Yavnai wrote:
Pavel,
I think that this is a very good example why touch events should be processed
separately from mouse events.
For
A number of recent bugs have stemmed from a mistaken assumption in the
D3D code that calls to update the render target would always cause a new
render target to be installed which would clear the clip on D3D.
Recently, that assumption started failing and sometimes the render
target does not
Hi David and Felipe,
Please review my proposed fix for:
https://javafx-jira.kenai.com/browse/RT-28691
The webrev pointer, and a question, are in my recent comment there.
This makes every instance of corner radii handling I could find in
Region and NGRegion internally consistent, enforced by
Updated webrev available in the latest Jira comment, responding to
review feedback from Felipe and (in the Jira comments) answering a
number of questions about the methodology with David...
...jim
On 11/26/13 11:15 PM, Jim Graham wrote:
Hi David and Felipe,
Please
The warning message was printed out unconditionally even when the
summary was requested for other reasons...
http://cr.openjdk.java.net/~flar/RT-34635/webrev.00/
https://javafx-jira.kenai.com/browse/RT-34635
...jim
Hi Lisa,
Here are the changes we discussed. Note that I found the settings at
different lines in the embedded configuration files than you indicated,
but hopefully I modified all of the required platforms correctly...
Jira: https://javafx-jira.kenai.com/browse/RT-34663
webrev:
I fixed some formatting issues with the poolstats output. The diffs are
in the bug report:
https://javafx-jira.kenai.com/browse/RT-35089
...jim
Some key points hidden in the shadows here...
We have direct rendering shaders for simple objects like rects, ovals,
roundrects, simple single lines. We can handle simple strokes on those
with only the stroke width being customized (must use an expected join,
cap, no dashing).
Text is done
Chien answered some of these, but here are my answers (inline)...
On 1/3/14 9:40 AM, Steve Hannah wrote:
Prism. We do mix HW and SW in that we generate masks from a path in SW,
but we cache that on the card and render it using shaders.
Can you describe roughly how the caching works? I
The following Jira is more precisely aimed at the scrolling
optimizations that were disabled for Retina:
https://javafx-jira.kenai.com/browse/RT-27959
...jim
On 1/3/14 4:04 PM, Stephen F Northover wrote:
Hi Jeff,
Please add your weight to the JIRA (indicate the
Chien, Felipe,
I've made some changes to the diagnostic code in glContext.c to help
track down why WebLauncher is currently failing on Mac. I need a review
and perhaps some help making sure that the changes compile on other
platforms...
Jira: https://javafx-jira.kenai.com/browse/RT-35209
Jira: https://javafx-jira.kenai.com/browse/RT-25249
webrev: http://cr.openjdk.java.net/~flar/RT-25249/webrev.00/
The code was taken as a boilerplate from the ImageView code...
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-33294
webrev: http://cr.openjdk.java.net/~flar/RT-33294/webrev.00/
Tested using the submitted test case and then also using all of the
Canvas toys in rt-closed...
...jim
Kevin, Chien, Felipe,
I'm tagging 3 people on this review to hopefully get some more critical
feedback mostly because the webrev is large, though most of the changes
are simple due to some method signature changes...
Jira: https://javafx-jira.kenai.com/browse/RT-13275
webrev:
webrev: http://cr.openjdk.java.net/~flar/RT-35452/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-35452
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-35058/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-35058
...jim
If you look at the first o, the version on top has a leading edge that
is only 2 pixels wide and the one below is a dark middle column flanked
by 2 lightly colored columns. It's as if the placement on the lower
text is trying harder to center its columns of sub-pixel samples to
ensure that
Simple cut/paste error fix:
Jira: https://javafx-jira.kenai.com/browse/RT-36208
webrev: http://cr.openjdk.java.net/~flar/RT-36208/webrev.00/
...jim
Kevin and Jasper hit the nail on the head (Jasper's comment that the
words are usually associated with particular ranges is mostly true
AFAIRemember, but I can't guarantee it).
If there is part of the documentation here that could be made clearer,
let us know...
This is one of the earliest bugs filed against the effects package:
https://javafx-jira.kenai.com/browse/RT-381
I can understand the concept, but since our effects are pixel-based, it
is hard to figure out where the foreground drawing would have rendered
opaquely if it didn't have an alpha
webrev: http://cr.openjdk.java.net/~flar/RT-24903/webrev.01/
jira: https://javafx-jira.kenai.com/browse/RT-24903
...jim
Actually, Box Blurs are no more efficient than Gaussian on GPU hardware
due to the inability of shaders to perform incremental operations from
pixel to pixel. Both are implemented by convolution kernels and N
multiplies per pixel in the first horizontal pass and M multiplies per
pixel in the
The tick marks in the MacOS display settings do not turn off retina
support, they only affect the amount of scaling within the retina
spectrum that is provided.
To turn off retina support you need to use a utility like QuickRes that
allows you to specify HiDPI (retina) vs. non-HiDPI
Jira: https://javafx-jira.kenai.com/browse/RT-36790
webrev: http://cr.openjdk.java.net/~flar/RT-36790/webrev.00/
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-36760/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36760
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-36296/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36296
Do we need 2 reviewers?
...jim
This is likely due to growing the command buffer which was done linearly
at one point (probably still done that way in 2.2), but is now
exponential in 8.0. The first render time is nearly instantaneous in
8.0, but takes a long time as you found when I try it with one of my old
2.x builds...
For the record, no such lengthy caching is done. Ovals are either
rendered using a single oval shader or on some platforms (i.e. embedded)
using a combination of that shader or an oval farm that is populated
nearly instantly on startup (a single texture upload)...
...jim
On
Are you clipping to an arbitrary path in all cases or just a rectangle?
Unfortunately we only offer the arbitrary clip-to-current-path method
that isn't optimized for basic rectangular clipping and it implements
soft clipping.
There is an outstanding tweak that we added faster clipping
case.
I guess that rect clipping is the most common one so having an optimization for
rects and a slow path for none rects might help.
Tom
Von meinem iPhone gesendet
Am 23.05.2014 um 23:35 schrieb Jim Graham james.gra...@oracle.com:
Are you clipping to an arbitrary path in all cases or just
common one so having an optimization for
rects and a slow path for none rects might help.
Tom
Von meinem iPhone gesendet
Am 23.05.2014 um 23:35 schrieb Jim Graham james.gra...@oracle.com:
Are you clipping to an arbitrary path in all cases or just a rectangle?
Unfortunately we only offer
://tomsondev.bestsolution.at/2014/05/24/swtonfx-javafx-canvas-with-many-clipping-calls-unacceptable-slow/#comments
Tom
On 27.05.14 23:47, Jim Graham wrote:
Canvas is, essentially, a draw pixels mechanism. We have to bundle
the requests into a command stream due to threading issues, but when the
requests get
Schindl wrote:
I'm on java8u5!
Tom
On 27.05.14 23:38, Jim Graham wrote:
You may have been testing J2D in a pre-retina-aware VM vs. JavaFX which
was retina aware a little earlier than J2D (due to JavaFX being on a
slightly more liberal feature policy for new releases). I think J2D
went retina
webrev: http://cr.openjdk.java.net/~flar/RT-36016/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36016
This is a regression caused by the recent work on blurs/shadows on retina...
...jim
In that code i n is a tautology. It's purpose seems to be to
prevent the following i+1s from overflowing the string length, but
then it should be i n-1 or n should just be initialized to
name.length()-1 (and be called max or something to make its purpose
clear)...
webrev: http://cr.openjdk.java.net/~flar/RT-37434/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37434
Is there any other way for the properties to be updated that the new fix
doesn't cover?
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-36891/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36891
Details are in the Jira comments...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-37449/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37449
Simple fix, details in Jira comments...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-37475/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37475
Lengthy explanation of an aha moment in the Jira, but the actual fix
is fairly simple...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-36341/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36341
It will be hard to verify the test because webrev mangled the patch file
on the test file, but any image file renamed to the appropriate file
name should work as indicated in the
webrev: http://cr.openjdk.java.net/~flar/RT-37300/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37300
...jim
Jira: http://cr.openjdk.java.net/~flar/RT-37793/webrev.00/
webrev: http://cr.openjdk.java.net/~flar/RT-37793/webrev.00/
...jim
Girod wrote:
Hello, I have a question about this (sorry if you explained it before): does
rectangular clipping on regular Nodes has / had the same performance problems
than with the Canvas?
Hervé
Sent from my iPhone
On Jul 10, 2014, at 21:19, Jim Graham james.gra...@oracle.com wrote:
Jira
Jira: https://javafx-jira.kenai.com/browse/RT-30107
webrev: http://cr.openjdk.java.net/~flar/RT-30107/webrev.00/
Some explanation and benchmark results are in the Jira comments...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-38005/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38005
...jim
If there is a card that can't keep up with what we want it to do then we
should probably be dealing with that on our end as well, whether by
disabling 3D on that card or by black listing it and just falling back
to sw pipeline. We already do that with a number of embedded GPUs...
On 8/9/14 3:19 PM, Edu García wrote:
Hi, I have a few questions about JavaFX usage, I hope this is the right
place to ask them:
1. I'm creating a Pane with a lot of shapes and resizing it to 128x128. I'm
saving it as an image with snapshot() and SwingFXUtils.fromFXImage() (is
there any other
I could have sworn there was a bug for this, but I can't find it. You
should submit one so that we can track the request.
In the meantime, you could apply your trick to any shape by setting that
shape as the clip on the proportionally distorted rectangle...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-37999/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37999
Includes API unit tests and a graphical test is attached to the Jira
issue...
...jim
We simply haven't implemented this yet:
https://javafx-jira.kenai.com/browse/RT-28629
...jim
On 8/26/14 3:29 PM, Felipe Heidrich wrote:
I'm curious. Why setSmooth doesn't work?
I tried setSmooth but it doesn’t work.
See the doc: Indicates whether to use a better
webrev: http://cr.openjdk.java.net/~flar/RT-23822/webrev.01/
Jira: https://javafx-jira.kenai.com/browse/RT-23822
Includes API unit tests and a graphical test is attached to the Jira
issue...
...jim
.
On the other hand, it could just be a bug of JavaFX.
I repeat:
On 8/26/14 4:35 PM, Jim Graham wrote:
We simply haven't implemented this yet:
https://javafx-jira.kenai.com/browse/RT-28629
...jim
setSmooth() is not hooked up to any mechanism at all. Nothing examines
, but
it's free to ask :).
On Thu, Aug 28, 2014 at 8:01 AM, Jim Graham james.gra...@oracle.com wrote:
On 8/27/14 1:04 AM, Nico Krebs | www.mensch-und-maschine.de wrote:
Question 1:
I don't know why setSmooth(false) doesnt work. Perhaps am i using it the
wrong way? I set it for each ImageView object i
webrev: http://cr.openjdk.java.net/~flar/RT-38183/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38183
Short and long explanations of the fix are in the Jira comments...
...jim
.
...jim
On 8/27/14 11:51 PM, Nico Krebs | www.mensch-und-maschine.de wrote:
Thank you both!
i added a vote to the feature request. Could you provide a short sample,
how snapshot(..) can help me zooming without antialiasing?
Nico
Jim Graham mailto:james.gra...@oracle.com
28
Originally it would complain about the resources being locked on every
frame since they remained locked. More recently we installed a report
and forgive mechanism that reports that the locks were outstanding
(because that is a bug), but then it conditionally can either mark the
resource as
A new version of this fix was just posted for review after the sanity
testing failures from this morning...
...jim
On 8/27/14 7:21 PM, Jim Graham wrote:
webrev: http://cr.openjdk.java.net/~flar/RT-38183/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38183
webrev: http://cr.openjdk.java.net/~flar/RT-36205/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36205
Description of fix and testing is in the Jira issue. I'd especially
appreciate some more rigorous testing from Phil if he can spare the time
and has any printing test suites that
webrev: http://cr.openjdk.java.net/~flar/RT-38574/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38574
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-38536/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38536
As mentioned in the Jira comments I would appreciate advice on turning
the tests attached to the issue into unit tests that run in
separate/fresh runtimes...
webrev: http://cr.openjdk.java.net/~flar/RT-36221/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36221
Simple workaround copied from other parts of the code base...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-38556/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38556
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-37356/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37356
Details in the Jira comments...
...jim
Hi Kevin, Chien,
webrev: http://cr.openjdk.java.net/~flar/RT-25263/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-25263
CC'ing Felipe in case he has any comments from when he worked on this
code...
...jim
Hi Kevin,
webrev: http://cr.openjdk.java.net/~flar/RT-36854/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36854
...jim
Kevin already reviewed this fix during a discussion on the Jira issue
(see the comments), but I realized after I pushed that I never sent out
a public request for reviews to the list...
Jira: https://javafx-jira.kenai.com/browse/RT-36566
webrev:
...
...jim
On 10/10/14 2:36 AM, Jim Graham wrote:
Kevin already reviewed this fix during a discussion on the Jira issue
(see the comments), but I realized after I pushed that I never sent out
a public request for reviews to the list...
Jira: https://javafx-jira.kenai.com
Kevin,
You asked for it, you got it, now you get to review it... ;)
webrev: http://cr.openjdk.java.net/~flar/RT-38846/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38846
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-39046
webrev: http://cr.openjdk.java.net/~flar/RT-39046/webrev.00/
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-38948
webrev: http://cr.openjdk.java.net/~flar/RT-38948/webrev.01/
There are some notes that raise questions in the Jira comments. A
webrev.02 will likely follow, but the webrev does fix the bug in question...
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-39120
webrev: http://cr.openjdk.java.net/~flar/RT-39120/webrev.01/
This is a fallout fix from working on RT-38948...
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-39119
webrev: http://cr.openjdk.java.net/~flar/RT-39119/webrev.00/
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-34467/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-34467
This builds on the recent fixes for RT-38923 by adding a mechanism to reuse old
buffers when they are large enough.
Both test cases in RT-34467 now seem to be fairly well behaved
webrev: http://cr.openjdk.java.net/~flar/RT-39209/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-39209
The artifacts directory on Windows was approximately 44k smaller (out of 30m)
after the code/shaders were removed...
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-39424/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-39424
Note that curves still show a lot of errors due to RT-39439. Those will
be fixed by work on the BND constants in a separate fix...
...jim
In case Kevin is not back before our code close on Sunday night, anyone
with access to a retina machine (or intimate familiarity with MacOS and
Glass) feel free to review this fix...
...jim
On 11/26/14 5:00 PM, Jim Graham wrote:
webrev: http://cr.openjdk.java.net
Jira: https://javafx-jira.kenai.com/browse/RT-39590
webrev: http://cr.openjdk.java.net/~flar/RT-39590/webrev.00/
I'm pretty sure these calls to setSmooth(false) are not intentional
because the rectangles were used for rendering, not clipping, and they
have always been rendered AA so far until
Jira: https://javafx-jira.kenai.com/browse/RT-39602
webrev: http://cr.openjdk.java.net/~flar/RT-39602/webrev.00/
This is the fix for the true underlying problem behind RT-39590. It's a
simple application of restore your state in the rendering methods to
the new AA flag in NGShape...
Phil (and Kevin),
Please review:
webrev: http://cr.openjdk.java.net/~flar/RT-33085/webrev.01/
Jira: https://javafx-jira.kenai.com/browse/RT-33085
Mainly I'll need Phil to test the impact on printing...
...jim
I'm currently investigating what changes we need to make to get Windows
HiDPI support up and running. As it stands, anyone with a Hi DPI
Windows machine will see all Java and JavaFX programs run very tiny
since the Java executables have declared that we are DPI Aware in the
program manifest
Fix: http://cr.openjdk.java.net/~flar/RT-28164/webrev.00/
Webrev: https://javafx-jira.kenai.com/browse/RT-28164
...jim
Where are the attached files? When you say you zoomed them in, is that
with a screen pixel scaler, or by applying a scaling transform to the
SVG path?
I'm guessing that you are correct about RT-39439, but the fix there
should have made the paths more accurate? Could the kinks have been in
On 3/30/15 12:04 PM, Jim Graham wrote:
drawPolygon() is a very complex operation that involves things like:
- dealing with only rendering common points of intersection once
An example of the distinction here - try a test case where you execute
the exact same diagonal line primitive 1,000
...@lesspain.de:
The bad full screen performance is without the arcs. It is just one
call to fillRect, two to strokeOval and one to fillOval, that's
all. I will build a simple test case and file an issue.
On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
james.gra...@oracle.com
wrote:
Hi Robert
you
describe: the red and the blue channel are swapped.
Thanks,
Michael
On 23 Feb 2015, at 00:55, Jim Graham james.gra...@oracle.com wrote:
Hi Michael,
What error are you seeing, or is it just rendering incorrectly?
Looking at the code in ES2Texture.uploadPixels() it looks like ES2 might
Hi Michael,
What error are you seeing, or is it just rendering incorrectly?
Looking at the code in ES2Texture.uploadPixels() it looks like ES2 might
support BGRA via an extension. Perhaps we've only encountered platforms
with that extension so far. Otherwise, if I read the code correctly it
Hi Robert,
Please file a Jira issue with a simple test case. Arcs are handled as a
generalized shape rather than via a predetermined shader, but it
shouldn't be that slow. Something else may be going on.
Another test might be to replace the arcs with rectangles or ellipses
and see if the
an expected use case for JavaFX or
would I be better off with Graphics2D?
Thanks,
Chris
On Mon, March 30, 2015 20:04, Jim Graham wrote:
Hi Chris,
drawLine() is a very simple primitive that can be optimized with a
GPU
shader. It either looks like a (potentially rotated) rectangle or a
rounded rect
Hi Damien,
The main problem is that the definition of a stroked path and the
definition of a filled path are at odds. If the default stroke width is
1.0 and the default stroke type is CENTERED, then the stroke is
centered on the outline of a path and half of it falls on either side of
the
want to break out any champagne if it is just this one benchmark)...
...jim
On 4/16/15 12:58 PM, Johan Vos wrote:
Hi Jim,
On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
Excellent work!
- Johan
2015-04-14 21:16 GMT+02:00 Jim Graham james.gra
The Canvas is simply a texture of the specified dimensions. (We do
scale that size by any pixel scale applied to the entire scene, as in
Mac retina's 2x scale, but it's size is interpreted in the same
coordinate space as the Stage, Scene and the root Node coordinates.)
Transform properties
running driver 304.125
Regards,
Chris
On Wed, April 8, 2015 00:16, Jim Graham wrote:
OK, I took the time to put my rMBP on a diet yesterday and find room to
install a 10.10 partition. I get the same numbers for Sierpinski on 10.10,
so my theory that something changed in the OGL implementation
to be sure - is that iMac a dual graphics system, or is it
all-AMD-all-the-time? You can see which GPU is being used if you run it
with -Dprism.verbose=true...
...jim
On 4/2/15 4:13 PM, Jim Graham wrote:
On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw
On Mon, March 30, 2015 20:04, Jim Graham wrote:
Hi Chris,
drawLine() is a very simple primitive that can be optimized with a GPU
shader. It either looks like a (potentially rotated) rectangle or a
rounded rect - and we have optimized shaders for both cases. A large
number of drawLine() calls
of something between 2 - 5 Hz. It is new to me that something like
this is technically possible.
It looks as if the system is running at full speed but skips
displaying most of the generated
frames for some reason. Is such a behavior possible at all?
Am 05.06.15 um 22:49 schrieb Jim Graham:
I
1 - 100 of 246 matches
Mail list logo
