Vote: yes
...jim
On 4/28/16 8:16 AM, Kevin Rushforth wrote:
I hereby nominate Guru Hb [1] to OpenJFX Committer.
Guru is a member of JavaFX team at Oracle working on WebKit, who has
contributed 10 changesets [5] to OpenJFX, at least 8 of which are
significant.
Votes are due by May 12,
Vote: yes
...jim
On 4/21/16 9:48 AM, Kevin Rushforth wrote:
I hereby nominate Arunprasad Rajkumar [1] to OpenJFX Committer.
Arunprasad is a member of JavaFX team at Oracle working on WebKit, who
has contributed 10 changesets [5] to OpenJFX, at least 8 of which are
significant.
https://bugs.openjdk.java.net/browse/JDK-8153348
...jim
Changeset: e1688df54bdc
Author:flar
Date: 2016-04-12 15:26 -0700
URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/e1688df54bdc
8153348: JavaFX API doc examples use nonexistent package
"javafx.an
53542
...jim
On 3/31/16 12:52 AM, Jim Graham wrote:
I've updated the fix with the following additions:
http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.02/
- Redundant or obsolete command line overrides removed from Windows code
as follows:
Settings still
All Shape antialiasing should be grayscale. The only non-grayscale AA
we have is for text only, and that can be controlled using the
fontSmoothingType property on the Text node. Are these Text nodes or
other nodes that show the colored pixels?
It might help to submit a small test case (as in
Vote: yes
...jim
On 3/31/16 2:04 PM, Kevin Rushforth wrote:
I hereby nominate Murali Billa [1] to OpenJFX Committer.
Murali is a member of JavaFX team at Oracle working on WebKit, who has
contributed 10 changesets [5] to OpenJFX, at least 8 of which are
significant.
Votes are
aling of embedded Swing nodes. I looked at what was
needed and have an idea of what the fix would involve, but decided that
it was outside the scope of these fixes that are needed to get the HiDPI
FX properties implemented.
...jim
On 3/28/16 6:25 PM, Jim Graham wrote:
en X- and
Y-direction is actually relevant.
I've never seen such a system before.
Michael
Am 29.03.16 um 03:25 schrieb Jim Graham:
bug: https://bugs.openjdk.java.net/browse/JDK-8091832
webrev: http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.00/
This webrev fixes pixel snapping a
bug: https://bugs.openjdk.java.net/browse/JDK-8091832
webrev: http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.00/
This webrev fixes pixel snapping and application control over pixel
scaling on HiDPI screens:
- snap*() methods are all updated to take the current scale into account
- new
ation...
...jim
On 3/9/16 3:26 PM, Jim Graham wrote:
Hi Johan,
That sounds like the fix then.
Note that there is another optimization issue here that could be
addressed in a follow-on - basically when a larger physical size is
allocated, then we could expand the co
0, 0, 0, 0, highMaskCol, nextMaskRow,
- maskTex.getPhysicalWidth(), true);
+ maskTex.getContentWidth(), true);
maskTex.unlock();
curMaskRow = curMaskCol = nextMaskRow = highMaskCol = 0;
}
On Tue, Mar 8, 2
I think I see the issue.
In the code that calls maskTex.update(...) it passes
maskTex.physicalWidth() as the scan stride of the buffer, but the scan
stride of the buffer is based on the content size, not the physical
size. Thus, the checkUpdateParams() method overestimates how many bytes
are
Hi Johan,
Notes in line below...
On 3/8/16 6:14 AM, Johan Vos wrote:
We got a number of bug reports (on Android and iOS) reported by developers
using large images:
java.lang.IllegalArgumentException: Upload requires 2475266 elements, but
only 1549938 elements remain in the buffer
at com.sun.p
The thing about this use of pixcoord is that the same information can be
supplied much more efficiently as a pair of texture coordinates. The
value of pixcoord ends up being a linear equation over the area of the
primitive which is exactly what texture coordinate samples give you for
free.
I
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
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
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
[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
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
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
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
...
...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
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.
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
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
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
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:
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
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
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
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
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
/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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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)
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
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
%, 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
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
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
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
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
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
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
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
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
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
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
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 :
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
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
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
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
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
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
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
¬Â¦.
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
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
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 (
webrev: http://cr.openjdk.java.net/~flar/RT-40041/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-40041
...jim
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
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
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
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
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
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
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
Fix: http://cr.openjdk.java.net/~flar/RT-28164/webrev.00/
Webrev: https://javafx-jira.kenai.com/browse/RT-28164
...jim
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
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...
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
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
webrev: http://cr.openjdk.java.net/~flar/RT-39327/webrev.00/
Jira: https://javafx-jira.kenai.com/browse/RT-39327
...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
Jira: https://javafx-jira.kenai.com/browse/RT-38060
webrev: http://cr.openjdk.java.net/~flar/RT-38060/webrev.00/
...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
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
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-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-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
Jira: https://javafx-jira.kenai.com/browse/RT-39119
webrev: http://cr.openjdk.java.net/~flar/RT-39119/webrev.00/
...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-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
101 - 200 of 290 matches
Mail list logo
