Jira: https://javafx-jira.kenai.com/browse/RT-39046
webrev: http://cr.openjdk.java.net/~flar/RT-39046/webrev.00/
...jim
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
res wasting space - similar to the Java heap growth.
- Hopefully this is all transparent, but if you see something odd let us
know...
...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
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: http://cr.openjdk.java.net/~flar/RT-36566/webrev.
Vote: yes
...jim
On 9/24/14 6:17 AM, Kevin Rushforth wrote:
I hereby nominate Morris Meyer to OpenJFX Committer.
Morris was an initial member of JavaFX team at Oracle when the OpenJFX
project was created, and was on the initial list of approved committers
[1]. His status as Ope
Hi Kevin,
webrev: http://cr.openjdk.java.net/~flar/RT-36854/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36854
...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
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
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-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-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-38574/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38574
...jim
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 ar
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
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 u
necessary.
...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...@o
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
led). I don't keep my hopes up, but
it's free to ask :).
On Thu, Aug 28, 2014 at 8:01 AM, Jim Graham 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 fo
f the setSmooth()
method.
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. No
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
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-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
webrev: http://cr.openjdk.java.net/~flar/RT-38315/webrev.0/
Jira: https://javafx-jira.kenai.com/browse/RT-38315
...jim
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
On
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 way
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...
webrev: http://cr.openjdk.java.net/~flar/RT-38005/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38005
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-37945/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37945
I tested with toys/CanvasTest/run-bitmap and run-vector modifying the
build.xml to run them with the SW pipeline. I also ran "gradle test"
and it completed, but it wouldn't have run
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
Hervé 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 wrote:
Jira:
Jira: http://cr.openjdk.java.net/~flar/RT-37793/webrev.00/
webrev: http://cr.openjdk.java.net/~flar/RT-37793/webrev.00/
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-37300/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-37300
...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 com
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-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-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-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
In that code "i < n" is a tautology. It's purpose seems to be to
prevent the following "i+1"s 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-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
..jim
On 5/27/14 2:54 PM, Tom 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 relea
I've filed RT-37300 for this:
https://javafx-jira.kenai.com/browse/RT-37300
...jim
On 5/27/14 3:54 PM, Jim Graham wrote:
Hi Tom,
There are 2 upgrades to consider. One involves new API, but is probably
best in the long run.
Without API, we'd have to det
it looks like I'm not alone with the clipping performance problem
see
http://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 bundl
ess 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 :
Are you clipping to an arbitrary path in all cases or just a rectangle?
Unfortunately we only o
Tom
On 23.05.14 23:57, Tom Schindl wrote:
In the current usecase it is a rect all time but that's just in this special
use 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 ge
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 suppor
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
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...
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
webrev: http://cr.openjdk.java.net/~flar/RT-36760/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-36760
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-36340
webrev: http://cr.openjdk.java.net/~flar/RT-36340/webrev.00/
...jim
Jira: https://javafx-jira.kenai.com/browse/RT-36790
webrev: http://cr.openjdk.java.net/~flar/RT-36790/webrev.00/
...jim
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 resolution
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
webrev: http://cr.openjdk.java.net/~flar/RT-24903/webrev.01/
jira: https://javafx-jira.kenai.com/browse/RT-24903
...jim
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 fi
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...
...ji
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
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 t
webrev: http://cr.openjdk.java.net/~flar/RT-35058/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-35058
...jim
webrev: http://cr.openjdk.java.net/~flar/RT-35452/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-35452
...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: http://cr.openjd
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
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
Chien, Felipe,
Jira: https://javafx-jira.kenai.com/browse/RT-35210
webrev: http://cr.openjdk.java.net/~flar/RT-35210/webrev.00/
I will finish the cleanup of the "shader log" logic (RT-35209) as a
follow-on fix after this is pushed...
...jim
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
we
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 hardwa
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 under
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
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
It's a simple fix. I'm including Lisa on the reviewers because I'm
surprised that this never showed up on embedded where the texture-based
primitives are used by default...?
Jira: https://javafx-jira.kenai.com/browse/RT-34854
webrev: http://cr.openjdk.java.net/~flar/RT-34854/webrev.00/
Tested
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: http://cr.open
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
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
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
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 cha
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
mes
up? It seems using the stroke bounds for the stroke and the fill bounds for
the fill is more correct, even if it makes aligning the gradients more
difficult. That alignment is nice, but having the gradient work consistently
in terms of what 0% and 100% mean is probably important.
Scott
O
t;
bounds, and resulting in less mis-aligned gradients. 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 No
Felipe mentioned recently that we encountered some issues in fixing a
bug with SVGPath.
The outcome of this fix could be a significant change in how your
proportional gradient fills look and so we'd like to get feedback on the
various ideas. You can read about them in that Jira issue, but I'l
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:
http
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
There is one Mesh per MeshView and MeshView is a Node, so we require a
node per mesh.
But, a mesh can have millions of triangles. As long as they all have a
common material...
...jim
On 8/1/13 1:38 PM, Richard Bair wrote:
I intend to agree with you that Node may be
types and twiddles.
Richard
On Jul 31, 2013, at 1:36 PM, Jim Graham wrote:
D'oh! I knew I should have been checking this list a bit. I hope this isn't
too late to have any impact...
As an intermediate solution this is fine, but when we want to get into
providing settings for MSAA
On 7/31/13 1:36 PM, Jim Graham wrote:
D'oh! I knew I should have been checking this list a bit. I hope this
isn't too late to have any impact...
As an intermediate solution this is fine, but when we want to get into
providing settings for MSAA and FSAA and other algorithms I think
c
D'oh! I knew I should have been checking this list a bit. I hope this isn't
too late to have any impact...
As an intermediate solution this is fine, but when we want to get into
providing settings for MSAA and FSAA and other algorithms I think classes are
more flexible than enums. How about
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'
I'm a little behind on getting into this discussion.
I don't have a lot of background in 3D application design, but I do have some low-level rendering
algorithm familiarity, and Richard's summary is an excellent outline of the issues I was having
with rampant mixing of 2D and 3D. I see them as
Another thing to consider is that you may get your port off the ground
and running a little faster by starting with a Canvas port since it is
closer to your Graphics2D code. But, that depends on how much picking
you were doing and/or animation and you'd have to manage your own
(partial or full
On 5/21/13 9:06 AM, Danno Ferrin wrote:
Ok, in JFX 2x how do I get the pixel scale? This commit
http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/51a85b7f59c2 has it for
Images, but where can I tease it out for the whole display? Private APIs
for 2.2 are OK, but will this be a "wait for 8" featur
On 5/18/13 12:20 AM, Jack Moxley wrote:
As such having it done for me, does not appeal, unless I have a way of
overriding it.
Absolutely we should strive to allow any app to manage its own pixel
registration. But, we do need to do something by default to avoid
completely unreadable apps f
201 - 290 of 290 matches
Mail list logo
