RGB and LAB color spaces: Conversion and interpolation

2015-09-25 Thread Benjamin Gudehus
Hey!

I want to convert colors between different color spaces and interpolate
them within the specific color space (sRGB and its cylindrical
transformations HSL/HLS, HSV/HSB, and HSI. LAB and its cylindrical
transformations LCH, and HCL).

javafx.scene.paint.Color only accepts (s)RGB and HSB and seems to support
interpolate() within RGB only. Should I use java.awt.color.ICC_ColorSpace
(which lacks support for HSI, LCH and HCL) or is there a more complete
library for Java or JavaFX?

Regards,
Benjamin


Re: RGB and LAB color spaces: Conversion and interpolation

2015-09-25 Thread Jim Graham
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 within the specific color space (sRGB and its cylindrical
transformations HSL/HLS, HSV/HSB, and HSI. LAB and its cylindrical
transformations LCH, and HCL).

javafx.scene.paint.Color only accepts (s)RGB and HSB and seems to support
interpolate() within RGB only. Should I use java.awt.color.ICC_ColorSpace
(which lacks support for HSI, LCH and HCL) or is there a more complete
library for Java or JavaFX?

Regards,
Benjamin



Re: In(Sanity) Testing Mondays

2015-09-25 Thread Phil Race
I believe Kevin said integration will be skipped this week so none of 
this is necessary.


-phil.

On 09/25/2015 07:30 AM, Vadim Pakhnushev wrote:

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 
1pm PDT.


Happy testing!

Thanks,
Vadim




Re: Usage of Toolkit firePulse

2015-09-25 Thread Dr. Michael Paus

Hi,
this really works great and is in my opinion the best approach to ensure
a super smooth canvas update. So the trick is to spread the whole work over
several smaller chunks via Platform.runLater calls but instead of creating
all these chunks at once, one has to chain these in such a way that the
first call issues the next call at the end if there is still more work 
to do. This way

there is never more than one call in the queue and the pulses to update
the scene graph are not delayed. I think this may become a general pattern
of how to update a canvas with complex drawings.
Michael

Am 25.09.15 um 00:03 schrieb Tomas Mikula:

Hi Michael,

attached see your original file updated with the continuation-style 
solution.


Regards,
Tomas

On Thu, Sep 24, 2015 at 2:44 PM, Dr. Michael Paus > wrote:


I have written a little test program to evaluate the various
strategies which have
been discussed here. You can download it via this link:



The program creates a large canvas inside a scroll pane and fills
it with some
butterflies. When you scroll the pane the canvas is redrawn when a
certain
threshold is exceeded. With some boolean flags at the top of the
program
you can select the redraw strategy.

This was just a quick and dirty hack, so I hope I haven't made any
mistakes
but the result so far is that only the AnimationTimer strategy
leads to a amazingly
smooth result. For all other strategies the scrolling performance
is terrible.
(I have not yet tried the proposal from Tomas.)

Give it a try yourself. The initial setting are for AnimationTimer.

Michael


Am 24.09.15 um 17:17 schrieb Kevin Rushforth:

Yes, I think this might be a better approach.

-- Kevin


Scott Palmer wrote:

For some of these use cases I wonder if an AnimationTimer
could be used to handle spreading work out.
E.g in the case of rendering to a canvas across multiple
pulses, do a bit at a time in the AnimationTimer’s
handle() method.

Scott

On Sep 24, 2015, at 5:53 AM, Fisher, Robert
> wrote:

I was naively thinking something like:

1. Make small change to canvas
2. Fire pulse
3. Make next small change to canvas
4. Fire pulse
5. Etc..

But I was actually also unaware of this firePulse
method until this morning (and I couldn't have used it
anyway since it's not public API).

-Original Message-
From: openjfx-dev
[mailto:openjfx-dev-boun...@openjdk.java.net
] On
Behalf Of Dr. Michael Paus
Sent: Donnerstag, 24. September 2015 11:07
To: openjfx-dev@openjdk.java.net

Subject: Re: Usage of Toolkit firePulse

Hi,
I wasn't aware of this Toolkit method when I wrote the
mail you are referring to. Can you or anybody else
explain what this method exactly does. It sounds
indeed as if I could solve some problems with it
although I am not sure yet and of course only if
Jonathan does not block it in the future :-) Michael

Am 24.09.15 um 09:31 schrieb Fisher, Robert:

I think it would be great to have in the public
API. It looks like it would allow you to spread
large UI updates out over several pulses in a
well-defined way.

See also this post from a month or so ago:

Hi,
I want to do some performance tuning of a
JavaFX application of mine but before I can
start with that I have to learn a little bit
about the scene graph redraw handling.
Maybe there is someone on this list who can
help me there.

What I want to achieve is a super smooth
animation (movement) of my scene graph.
Let's assume the scene graph itself can be
redrawn fast enough in less than 1/60s.
In addition let's assume the scene graph
contains a canvas which only has to be updated
from time to time but an update of the canvas
takes substantially 

In(Sanity) Testing Mondays

2015-09-25 Thread Vadim Pakhnushev

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 1pm 
PDT.


Happy testing!

Thanks,
Vadim