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-38923/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-38923
The main issues are testing this in various configurations and with whatever
tests were used that led us to the previous solution of having an unbounded
number of outstanding pixel b
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 (wi
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-39275/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-39275
Long explanations about the rework of the original fix for RT-36130 are
in the Jira comments...
...jim
Some pie in the sky observations about the background here...
Note that there was a fine line there that had to be evaluated. Many of
the printing detection changes were basically just "Oh, look, I have a
new ResourceFactory now, that probably means new Textures", but it was
tempered with "On
Jira: https://javafx-jira.kenai.com/browse/RT-38060
webrev: http://cr.openjdk.java.net/~flar/RT-38060/webrev.00/
...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
webrev: http://cr.openjdk.java.net/~flar/RT-39327/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-39327
...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 C
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
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
t
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
One interesting point to note that makes one concern seem less
compelling in a practical sense:
On 2/17/2015 5:27 PM, Jim Graham wrote:
To get an idea of the kinds of problems we might encounter when trying
to translate the screens into "virtual coordinates", consider that the
defa
Thanks for looking at this Werner!
On 2/18/2015 2:13 AM, Werner Lehmann wrote:
Hi Jim,
As to the question of integer vs float
coordinates, there is a lot of snapToPixel stuff going on. And one of
the reasons is to get crisp pixel-aligned lines. Snapping to logical
coordinates could then snap to
On 2/18/2015 2:13 AM, Werner Lehmann wrote:
Finally, it would be nice to get information about the actual screen
DPI. In my tests Screen.getDpi always returns 96, regardless of what it
actually is...
I'm not sure if there is a legacy API for that value in Windows
pre-Win8.1, but I know that
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
actly what you
describe: the red and the blue channel are swapped.
Thanks,
Michael
On 23 Feb 2015, at 00:55, Jim Graham 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
support B
webrev: http://cr.openjdk.java.net/~flar/RT-40041/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-40041
...jim
think it makes sense to use a byte array in both cases as you
initially suggested.
- Michael
On 23 Feb 2015, at 20:58, Jim Graham wrote:
Oh dear, it is a bit worse than that. The texture creation code doesn't even
have an enum constant to specify BYTE_RGBA_PRE. It has BYTE_BGRA_PRE (
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 p
¬Â¦.
Am 27.03.2015 um 22:10 schrieb Robert Krüger
:
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
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
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
ed 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 rec
ference.
Just 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 a
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 - and we have optimized shaders for both cases. A large
number of drawLi
th an Nvidia Quadro FX 580
graphics card 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 som
Jira: https://javafx-jira.kenai.com/browse/RT-40533
webrev: http://cr.openjdk.java.net/~flar/RT-40533/webrev.02/
(note that this latest webrev is generated against 9-dev and has a few
lines/names/copyrights cleaned up, but no change in the logic...)
...jim
t I
don't 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 :
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 on
I'm not an expert on how to use OpenGL on Mac to avoid the discrete
grahpics, but I do know that the retina support in the SW pipeline on
the Mac should be addressed soon in 8u60 as a result of fixing RT-27960.
The fix has been pushed to 8u-dev (and 9-dev) and is awaiting a sync
into the maste
8u45 is already out, shouldn't we require that as long as we are updating?
...jim
On 5/27/2015 12:53 PM, Kevin Rushforth wrote:
David, Chien, and Amy:
As announced previously, this fix will update our builds to use (and
require) JDK 8u40 to build FX.
https://javafx-jir
https://jdk8.java.net/download.html
The 8u60 b17 build should now contain changes recently made to support
HiDPI displays on Windows. This will probably be most visible on
laptops where the advertised DPI has been climbing in recent years.
The main thing you might notice is that your windows
I actually use a retina MBP for testing - dual booting Windows and MacOS.
There should be no changes at all on other platforms, particularly in
regard to rendering speed. There was one small regression on Linux
resulting in a bad first paint due to asynchronous initialization of the
Window si
a visual frame rate
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 sc
ons proposed by Kevin but they did not change
anything
and the output suggest that I am not using too much vram.
Am 08.06.15 um 20:33 schrieb Jim Graham:
The only thing that might affect this was the change in the default
size of the vram pool, but that happened in 8u40 which predates both
Hi Michael,
On 6/10/15 12:39 AM, Dr. Michael Paus wrote:
If I understand you correctly you are saying that all this
HiDPI-handling is done under the covers and should
be fully transparent to the programmer, whereas I think that this is not
possible for non-trivial cases.
(Is this foo. versus foo
Hi Tobi,
Can you share your small clock app? Perhaps file a bug and attach the
source?
Also, what version of MacOS are you running on what hardware? (And
compared to what version of Windows on what hardware?)
...jim
On 7/7/15 4:32 AM, Tobias Bley wrote:
Hi,
cu
jira: https://bugs.openjdk.java.net/browse/JDK-8130749
webrev: http://cr.openjdk.java.net/~flar/JDK-8130749/webrev.01/
The issue turned out to be a mismatch between layer bounds being in
device coordinates and then being used in drawTexture() which has a
transform from the HiDPI scaling.
Are
%, Windows: 0-3%
Best regards,
Tobi
Am 07.07.2015 um 21:23 schrieb Jim Graham :
Hi Tobi,
Can you share your small clock app? Perhaps file a bug and attach the source?
Also, what version of MacOS are you running on what hardware? (And compared to
what version of Windows on what hardware
Would adding final to the field declarations also aid in the
inline-ability of the getters?
...jim
On 7/29/15 5:32 PM, Kevin Rushforth wrote:
Point2D is immutable by design, so there are no setters. And yes, the
private variables for x and y could be made final, but sin
Let me understand what is going on here.
I get the result you are trying to achieve - blur the scene as
background for something.
I get that Mac and iOS seem to have direct support for this technique
which appears to work faster than what we provide via the Effect mechanism.
I also get that
Hi Matthias,
On 8/10/2015 11:44 PM, Matthias Hänel wrote:
If we had a "snapshot to texture" mechanism then that might reduce the memory
copying of the work around technique.
Well, did you say there is no snapshot to texture in JavaFX? In plain OpenGL
you can use FBO's (Frame Buffer Objects)
duplicate copy of the underlying tree and setting a blur effect and a
clip (and possibly cache=true) on the copy and placing that behind the
overlying node...
...jim
On 8/10/2015 11:29 AM, Jim Graham wrote:
Let me understand what is going on here.
I get the result you are trying to achieve
On 8/13/2015 1:29 AM, Matthias Hänel wrote:
I'd argue that we sort of do have something like that - it is the cache flag.
If a Node is cached then we do have a copy of it in a texture and that can help
make the Blur Effect work more efficiently, but there may be some additional
copies betwe
What I would do to blur an entire scene is to add the blur to the top
level of it. If the stuff on top of the blur is re-rendering a lot,
then I'd add setCache(true) to that same top-level node:
oldroot.setCache(true);
oldroot.setEffect(blur);
Group newroot = new Group(newroot, overlay);
set(n
On 8/13/2015 12:33 PM, Kevin Rushforth wrote:
* Node caching was intended as a hint to the system to cache the result
of potentially expensive effects into a texture (which is rendered into
by the GPU) and re-render that texture when needed. Jim was suggesting
that an application might be able to
Hi Tobias,
I'm not sure what problem you are fixing here, but "node scaling" is not
something the pipelines implement. They support a transform in the
Graphics object and the NGNode code is responsible for setting up that
transform in its render methods.
What aspect of scaling is not workin
Hi Johan,
Can you file a bug on this?
...jim
On 9/8/15 5:14 AM, Johan Vos wrote:
Hi,
I am running into an issue on Android that seems more general to me.
I noticed that scroll gestures where passed with wrong coordinates, as
the physical coordinates are used instead of
I assume by "canvas" you mean "a Canvas Node"? I can only answer one of
your questions...
On 9/8/15 11:14 AM, Dr. Michael Paus wrote:
When an update of the canvas is in progress will this delay the next
pulse until all
internal drawing within the canvas is finished? From my observations I
thin
We don't yet query any platform properties on Linux, but the underlying
pipelines should support it just fine. I created a new bug in JBS to
track Linux support. Any information about how to query UI scale
factors on various Linux flavors and GUI toolkits should be added there.
It should be
JavaFX has no color conversion libraries. The classes in java.awt.color
are the only alternative that ships standard with the JDK...
...jim
On 9/25/15 7:42 AM, Benjamin Gudehus wrote:
Hey!
I want to convert colors between different color spaces and interpolate
them wi
se PixelReader to extract the
integer color values, and the implemention uses some padding for the
colors at start and end. Then the implementation is in
com.sun.prism.impl.paint so I can't access it directly.
Seems I have to implement this library by myself.
On Fri, Sep 25, 2015 at 9:33 P
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
d.
If you can give me a direction on where to search for the disabled
scrolling optimization, I'll try to re-enable that and see how it
improves performance. It might be a huge and quick win...
Thanks again,
- Johan
On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham mailto:james.gra...@ora
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
It should be supported. Which version of Windows were you using before?
We've supported HiDPI on Windows since JDK8u60 on all supported
versions of Windows...
...jim
On 10/27/15 11:24 PM, Felix Bembrick wrote:
I just installed JavaFX on my new Windows 10 machine whic
I doubt it would be simply a "number of pixels" issue. I don't have a
4K monitor, but I've run it on some HiDPI monitors that keep up just
fine with much more modest hardware.
There are a couple of possible things that may get in the way:
- Our max texture size is 4096x4096 which should be la
K monitors.
Hi-DPI is supported in the sense that everything renders at the correct size
etc (unlike Swing) but it performs so slowly that there must be something
fundamentally wrong, especially since JavaFX seems to be the only technology
that's affected.
On 31 Oct 2015, at 06:49, Ji
eateShader: LinearConvolve_8
PPSRenderer: scenario.effect - createShader: LinearConvolve_64
PPSRenderer: scenario.effect - createShader: Blend_ADD
PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_16
PPSRenderer: scenario.effect - createShader: LinearConvolve_12/*
#
On 31 October 20
Should we have a column for the default setting?
Also, targetvram shouldn't be set higher unless you also set maxvram
higher - we'll need a place to mention dependent properties.
Should all of that just be mentioned in text in the description field?
...jim
On 11/2/201
/2015 1:24 PM, Jim Graham wrote:
For reference, I just ran the Ensemble8 demo on a Windows 10 laptop with
a 200% scaled HiDPI screen (3000x2000) with integrated Intel HD Graphics
520 and it ran smooth as glass, even the 3D samples.
The laptop also has an embedded nVidia 900 series GPU, but I need to
or will be batched together
with a single description box perhaps...
...jim
On 11/2/2015 1:40 PM, David Hill wrote:
On 11/2/15, 4:27 PM, Jim Graham wrote:
Should we have a column for the default setting?
Also, targetvram shouldn't be set higher unless you also set
All this does is change the prime constant used to produce the hash value.
Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a) +
hash(b) that the embedded implementation uses.
I don't really think this is a bug. The fact that Integer objects make
it easy to reverse enginee
Not really impressive, but still, and it uses well-defined utility
method.
Yeah, I know it's not really a bug since you don't want to rely on
the hashCode at all...
Thanks,
Vadim
On 03.11.2015 22:35, Jim Graham wrote:
All this does is change the prime constant used to produce the h
I've created 2 versions of the fix for this bug. One is low source
impact but maintains the current convoluted role of the VertexBuffer
class in the code base and makes it slightly more murky. The second fix
touches a bunch of files, but it cleans up the use of the VB class
throughout the cod
And, even if it isn't, shouldn't we have a concept of "you can't draw
right now, just go away and we'll tell you when it's available again"
built into the Presentable API? You shouldn't have to set the
dimensions to 0,0 to mean "I'm not here right now"...
...jim
On 11
k.java.net/browse/JDK-8140503
http://cr.openjdk.java.net/~vadim/8140503/webrev.01/
Thanks,
Vadim
On 04.11.2015 1:43, Kevin Rushforth wrote:
Inlining it seems like a fine way to go to me, too. As another point
of reference, we use 7/31 in other places in JavaFX.
-- Kevin
Jim Graham wrote:
That sounds good.
...jim
On 11/23/15 12:32 PM, Vadim Pakhnushev wrote:
How about "Improve javafx.util.Pair hash code computation" ?
Vadim
On 23.11.2015 22:56, Jim Graham wrote:
Looks fine to me. Perhaps the synopsis on the bug should be changed
to &quo
A formatting nit - "if" is not a function, it is a control statement and
so there should always be a space between it and the condition being tested:
"if(foo)" => "if (foo)"
Just to make sure we are on the same page,
ResourceFactory.getMaxTextureSize() is clamped by an arbitrary limit we
use
Jira: https://bugs.openjdk.java.net/browse/JDK-8143598
webrev: http://cr.openjdk.java.net/~flar/JDK-8143598/webrev.00/
Since the min/max properties are enforced asynchronously (at least on
the Windows platform), there wasn't an easy test case to write to verify
that the values were enforced unf
Vote: yes
...jim
On 12/21/15 11:45 AM, David Hill wrote:
I hereby nominate Johan Vos to OpenJFX Committer.
Johan Vos (jvos) has been active in the OpenJFX community, and
instrumental in the maturity of Monocle, the owner of the Android and
IOS ports and is an OpenJFX Author.
...
...jim
On 11/7/15 3:57 PM, Jim Graham wrote:
I've created 2 versions of the fix for this bug. One is low source
impact but maintains the current convoluted role of the VertexBuffer
class in the code base and makes it slightly more murky. The second fix
touc
Yes, we should look to have a separate header block that various shader
program pieces can append to independently of the code they insert into
the main body of the shader. I've been through it a few times and could
probably come up with something if needed, but do you feel confident
trying to
How often are listeners added and removed? It might make more sense to
make them copy-on-write instead...?
...jim
On 1/14/16 4:52 AM, Doswald Michael wrote:
While profiling a JavaFX application that runs on embedded hardware, I have
found that the Toolkit.firePulse me
Hi Ramon,
Currently the effects framework has no public API for extending it for
new effects. WritableImage would be the only option of a public API
that you could use at this point...
...jim
On 2/3/2016 1:44 PM, Ramon Santiago wrote:
Just to be clear, I know how to
[I believe you sent this to the wrong mailing list - the "-request" list
is for changing your membership to the mailing list, not for sending
mail to the list itself. I fixed it here in my reply...]
That looks fine. I'll note that the "dashCumulative" variable does not
need to be computed if
I added a comment on the bug about BC, but it sounds like you already
considered it. I'm fine with this as is, but would push for moving to
JDK9 ASAP...
...jim
On 2/16/2016 3:49 PM, Kevin Rushforth wrote:
[resend with correct subject line]
Jim and Alexander,
Please
Looks great. Approved...
...jim
On 2/17/2016 1:11 AM, Andrey Rusakov wrote:
Updated that:
<http://cr.openjdk.java.net/%7Earusakov/8088853/webrev.01>http://cr.openjdk.java.net/~arusakov/8088853/webrev.01
17.02.2016 01:22, Jim Graham пишет:
[I believe you sent t
ment.
-- Kevin
Sergey Bylokhov wrote:
Note that in jdk9 the same data can be obtained via
GraphicsConfiguration.getDefaultTransform();
On 17.02.16 2:53, Jim Graham wrote:
I added a comment on the bug about BC, but it sounds like you already
considered it. I'm fine with this as is, but woul
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
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
201 - 290 of 290 matches
Mail list logo