Skip to main content

SGRenderCache Update Bug

4 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Stephen Chin

Jim,

Any update on this bug? I haven't noticed any fixes checked in to
Subversion.

In my opinion, it is a pretty serious defect, because it causes
incorrect rendering when caching is enabled. Given the choice of
correctness vs. performance, most people will have to choose the former,
which may reflect poorly on the perceived performance of the JavaFX release.

For now I can work around this by including my own Scenegraph jar file,
but once the JavaFX 1.0 SDK comes out I won't have that luxury.

Please tell me if there is anything I can do to help.

Cheers,
--Steve

Stephen Chin wrote:
> Thanks for picking this one up, Jim.
>
> I was going for the simplest fix that would work, but did notice some
> placeholders in the code for future work in this area.
>
> I would be happy to run a more involved fix through my full application
> if you want the additional validation.
>
> Cheers,
> --Steve
>
> -----Original Message-----
> From: Jim.A.Graham@Sun.COM [mailto:Jim.A.Graham@Sun.COM]
> Sent: Monday, July 21, 2008 12:49 PM
> To: dev@scenegraph.dev.java.net
> Subject: Re: SGRenderCache Update Bug
>
> This will fix the situation at hand, but cause other problems. The test
>
> for the TRANSFORM bit really does need to be a bit test as it can often
> come with other bits set which are harmless with respect to whether or
> not a transform check is sufficient. The problem is that there are
> other bits which trump the transform check which are not noticed by this
>
> test.
>
> Your fix will correctly avoid the transform check optimization if
> another bit is set which trumps this optimization, but it will also
> remove the optimization if any other harmless bits are set.
>
> What we need is more along the lines of:
>
> if (TX bit is set && are not set) {
> checkXform = true;
> } ...
>
> I'll have to do some investigation to figure out what those "worse bits"
>
> are, but I'm catching up on 10 days of back email today... :-(
>
> ...jim
>
> Stephen Chin wrote:
>
>> I found a bug in scenegraph where the cache would prevent update of
>> nested components in the case where there are translations and bounds
>> changes happening in parallel.
>>
>> I've attached a stand-alone JavaFX Script example (CacheTest.fx) that
>> can be used to reproduce the problem. This example may seem
>>
> contrived,
>
>> but it is actually distilled down from a real-world example I stumbled
>>
>
>
>> on while developing WidgetFX, JavaFX Desktop Widget
>> Platform
.
>>
>> When you run the example notice that during the animation the blue
>> rectangle does not resize properly. To see the expected results, flip
>>
>
>
>> the cache property to false and rerun the example.
>>
>> Here is a candidate fix that solves this problem:
>> |--- src/com/sun/scenario/scenegraph/SGRenderCache.java (revision
>>
> 306)
>
>> +++ src/com/sun/scenario/scenegraph/SGRenderCache.java (working
>>
> copy)
>
>> @@ -187,7 +187,7 @@
>> @Override
>> void markDirty(int state) {
>> super.markDirty(state);
>> - if ((state & DIRTY_TRANSFORM) != 0) {
>> + if (state == DIRTY_TRANSFORM) {
>> checkXform = true;
>> } else {
>> // TODO - mark the image dirty for VISUAL changes and
>>
> reuse it|
>
>> My theory is that prior to this change, if you had a combination of
>> dirty flags (some for transform and some for bounds), it would be
>> treated as a transform dirty check. If this check passed, then it
>>
> would
>
>> not clear the cache, resulting in a stale image.
>>
>> I've also attached the fix as a patch file (cachefix.diff) that can be
>>
>
>
>> applied to the scenegraph trunk.
>>
>> Tell me if there is anything else I can do to help.
>>
>> Cheers,
>> --Steve
>>
>>
>>
>>
>>
> ------------------------------------------------------------------------
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Joshua Marinacci

There hasn't been much work on scenegraph lately because we are *all*
working very, very hard on getting the JavaFX SDK out the door. Thus
only fixes needed for JavaFX are being worked on. Once the SDK ships
we'll have more time to look at these. I know it's rough going right
now, so if there are any possible workarounds please use them.

Thanks,
Josh

On Sep 20, 2008, at 4:11 AM, Stephen Chin wrote:

> Jim,
>
> Any update on this bug? I haven't noticed any fixes checked in to
> Subversion.
>
> In my opinion, it is a pretty serious defect, because it causes
> incorrect rendering when caching is enabled. Given the choice of
> correctness vs. performance, most people will have to choose the
> former, which may reflect poorly on the perceived performance of the
> JavaFX release.
>
> For now I can work around this by including my own Scenegraph jar
> file, but once the JavaFX 1.0 SDK comes out I won't have that luxury.
>
> Please tell me if there is anything I can do to help.
>
> Cheers,
> --Steve
>
> Stephen Chin wrote:
>> Thanks for picking this one up, Jim.
>>
>> I was going for the simplest fix that would work, but did notice some
>> placeholders in the code for future work in this area.
>>
>> I would be happy to run a more involved fix through my full
>> application
>> if you want the additional validation.
>>
>> Cheers,
>> --Steve
>>
>> -----Original Message-----
>> From: Jim.A.Graham@Sun.COM [mailto:Jim.A.Graham@Sun.COM] Sent:
>> Monday, July 21, 2008 12:49 PM
>> To: dev@scenegraph.dev.java.net
>> Subject: Re: SGRenderCache Update Bug
>>
>> This will fix the situation at hand, but cause other problems. The
>> test
>>
>> for the TRANSFORM bit really does need to be a bit test as it can
>> often come with other bits set which are harmless with respect to
>> whether or not a transform check is sufficient. The problem is
>> that there are other bits which trump the transform check which are
>> not noticed by this
>>
>> test.
>>
>> Your fix will correctly avoid the transform check optimization if
>> another bit is set which trumps this optimization, but it will also
>> remove the optimization if any other harmless bits are set.
>>
>> What we need is more along the lines of:
>>
>> if (TX bit is set && are not set) {
>> checkXform = true;
>> } ...
>>
>> I'll have to do some investigation to figure out what those "worse
>> bits"
>>
>> are, but I'm catching up on 10 days of back email today... :-(
>>
>> ...jim
>>
>> Stephen Chin wrote:
>>
>>> I found a bug in scenegraph where the cache would prevent update
>>> of nested components in the case where there are translations and
>>> bounds changes happening in parallel.
>>>
>>> I've attached a stand-alone JavaFX Script example (CacheTest.fx)
>>> that can be used to reproduce the problem. This example may seem
>>>
>> contrived,
>>> but it is actually distilled down from a real-world example I
>>> stumbled
>>>
>>
>>
>>> on while developing WidgetFX, JavaFX Desktop Widget
>>> Platform
.
>>>
>>> When you run the example notice that during the animation the blue
>>> rectangle does not resize properly. To see the expected results,
>>> flip
>>>
>>
>>
>>> the cache property to false and rerun the example.
>>>
>>> Here is a candidate fix that solves this problem:
>>> |--- src/com/sun/scenario/scenegraph/SGRenderCache.java (revision
>>>
>> 306)
>>
>>> +++ src/com/sun/scenario/scenegraph/SGRenderCache.java (working
>>>
>> copy)
>>
>>> @@ -187,7 +187,7 @@
>>> @Override
>>> void markDirty(int state) {
>>> super.markDirty(state);
>>> - if ((state & DIRTY_TRANSFORM) != 0) {
>>> + if (state == DIRTY_TRANSFORM) {
>>> checkXform = true;
>>> } else {
>>> // TODO - mark the image dirty for VISUAL changes and
>>>
>> reuse it|
>>
>>> My theory is that prior to this change, if you had a combination
>>> of dirty flags (some for transform and some for bounds), it would
>>> be treated as a transform dirty check. If this check passed, then
>>> it
>>>
>> would
>>> not clear the cache, resulting in a stale image.
>>>
>>> I've also attached the fix as a patch file (cachefix.diff) that
>>> can be
>>>
>>
>>
>>> applied to the scenegraph trunk.
>>>
>>> Tell me if there is anything else I can do to help.
>>>
>>> Cheers,
>>> --Steve
>>>
>>>
>>>
>>>
>>>
>> ------------------------------------------------------------------------
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Stephen Chin

I appreciate the fact you guys are working very, very hard on the JavaFX
release. I also believe that JavaFX is worth the effort, which is why I
have spend the time and effort to dig in on the serious issues I find.
To reduce the bandwidth on you guys I have tried to do the following:

* Focus only on problems that show up in JavaFX
* Clearly describe the problem and any workarounds
* Give a reproducible scenario (in this case I also included some code)
* Provide a proposed fix as a patch that resolves the problem

While this caching issue is in the Scenario code, it is a showstopper
for a JavaFX program I am writing. I have an animated clock that uses
node caching so the hour and minute hands don't need to be redrawn every
time the second hand ticks. This caching bug causes the minute and hour
hands to "stick" in the same position (showing the wrong time) until you
force a repaint of the whole clock. The only workaround for this defect
is to disable caching, which has a big performance impact for something
I want to run on user's desktops constantly.

In response to Jim's concerns about which bits are harmless, vs. which
bits need to force a cache refresh, here is my analysis:

* DIRTY_SUBREGION - Not applicable - This only gets set on Leaf
nodes, so it will never never get set on an SGRenderCache node.
Instead you will have the DIRTY_CHILDREN_VISUAL flag set (per
implementation of SGNode.markSubregionDirty())
* DIRTY_VISUAL - Should trigger cache flush - This flag is set a few
places in the SGRenderCache specifically to force a repaint.
* DIRTY_BOUNDS - Should trigger cache flush - The node bounds are
used to size the image cache, so this needs to clear the cache.
* DIRTY_TRANSFORM - Should set checkXForm, and may not need to clear
the cache if it is just a translation
* DIRTY_CHILDREN_VISUAL - Should trigger cache flush - One of the
child nodes has changed appearance.
* DIRTY_CHILDREN_BOUNDS - Should trigger cache flush - One of the
child nodes has changed bounds. An example of this is
SGNode.setVisible() which sets DIRTY_BOUNDS (and will trickle up
as DIRTY_CHILDREN_BOUNDS to the SGRenderCache node). Hiding or
showing a child node will definitely need to force a cache flush.

So the quick summary is that the only case in which you can do the
transform optimization in SGRenderCache is when only DIRTY_TRANSFORM is
set. If any other bits are set on the state, you need to flush the
cache and re-render the child nodes.

I hope this helps. I've reattached the original scenario and patch,
which I believe is the correct fix.

Cheers,
--Steve

Joshua Marinacci wrote:
> There hasn't been much work on scenegraph lately because we are *all*
> working very, very hard on getting the JavaFX SDK out the door. Thus
> only fixes needed for JavaFX are being worked on. Once the SDK ships
> we'll have more time to look at these. I know it's rough going right
> now, so if there are any possible workarounds please use them.
>
> Thanks,
> Josh
>
> On Sep 20, 2008, at 4:11 AM, Stephen Chin wrote:
>
>> Jim,
>>
>> Any update on this bug? I haven't noticed any fixes checked in to
>> Subversion.
>>
>> In my opinion, it is a pretty serious defect, because it causes
>> incorrect rendering when caching is enabled. Given the choice of
>> correctness vs. performance, most people will have to choose the
>> former, which may reflect poorly on the perceived performance of the
>> JavaFX release.
>>
>> For now I can work around this by including my own Scenegraph jar
>> file, but once the JavaFX 1.0 SDK comes out I won't have that luxury.
>>
>> Please tell me if there is anything I can do to help.
>>
>> Cheers,
>> --Steve
>>
>> Stephen Chin wrote:
>>> Thanks for picking this one up, Jim.
>>>
>>> I was going for the simplest fix that would work, but did notice some
>>> placeholders in the code for future work in this area.
>>>
>>> I would be happy to run a more involved fix through my full application
>>> if you want the additional validation.
>>>
>>> Cheers,
>>> --Steve
>>>
>>> -----Original Message-----
>>> From: Jim.A.Graham@Sun.COM [mailto:Jim.A.Graham@Sun.COM] Sent:
>>> Monday, July 21, 2008 12:49 PM
>>> To: dev@scenegraph.dev.java.net
>>> Subject: Re: SGRenderCache Update Bug
>>>
>>> This will fix the situation at hand, but cause other problems. The
>>> test
>>>
>>> for the TRANSFORM bit really does need to be a bit test as it can
>>> often come with other bits set which are harmless with respect to
>>> whether or not a transform check is sufficient. The problem is that
>>> there are other bits which trump the transform check which are not
>>> noticed by this
>>>
>>> test.
>>>
>>> Your fix will correctly avoid the transform check optimization if
>>> another bit is set which trumps this optimization, but it will also
>>> remove the optimization if any other harmless bits are set.
>>>
>>> What we need is more along the lines of:
>>>
>>> if (TX bit is set && are not set) {
>>> checkXform = true;
>>> } ...
>>>
>>> I'll have to do some investigation to figure out what those "worse
>>> bits"
>>>
>>> are, but I'm catching up on 10 days of back email today... :-(
>>>
>>> ...jim
>>>
>>> Stephen Chin wrote:
>>>
>>>> I found a bug in scenegraph where the cache would prevent update of
>>>> nested components in the case where there are translations and
>>>> bounds changes happening in parallel.
>>>>
>>>> I've attached a stand-alone JavaFX Script example (CacheTest.fx)
>>>> that can be used to reproduce the problem. This example may seem
>>>>
>>> contrived,
>>>> but it is actually distilled down from a real-world example I stumbled
>>>>
>>>
>>>
>>>> on while developing WidgetFX, JavaFX Desktop Widget
>>>> Platform
.
>>>>
>>>> When you run the example notice that during the animation the blue
>>>> rectangle does not resize properly. To see the expected results, flip
>>>>
>>>
>>>
>>>> the cache property to false and rerun the example.
>>>>
>>>> Here is a candidate fix that solves this problem:
>>>> |--- src/com/sun/scenario/scenegraph/SGRenderCache.java (revision
>>>>
>>> 306)
>>>
>>>> +++ src/com/sun/scenario/scenegraph/SGRenderCache.java (working
>>>>
>>> copy)
>>>
>>>> @@ -187,7 +187,7 @@
>>>> @Override
>>>> void markDirty(int state) {
>>>> super.markDirty(state);
>>>> - if ((state & DIRTY_TRANSFORM) != 0) {
>>>> + if (state == DIRTY_TRANSFORM) {
>>>> checkXform = true;
>>>> } else {
>>>> // TODO - mark the image dirty for VISUAL changes and
>>>>
>>> reuse it|
>>>
>>>> My theory is that prior to this change, if you had a combination of
>>>> dirty flags (some for transform and some for bounds), it would be
>>>> treated as a transform dirty check. If this check passed, then it
>>>>
>>> would
>>>> not clear the cache, resulting in a stale image.
>>>>
>>>> I've also attached the fix as a patch file (cachefix.diff) that can be
>>>>
>>>
>>>
>>>> applied to the scenegraph trunk.
>>>>
>>>> Tell me if there is anything else I can do to help.
>>>>
>>>> Cheers,
>>>> --Steve
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>>>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>

/*
* CacheTest.fx
*
* Created on Jul 19, 2008, 8:10:25 PM
*/

package org.widgetfx;

import javafx.application.*;
import javafx.scene.*;
import javafx.animation.*;
import javafx.scene.paint.Color;
import javafx.scene.geometry.Rectangle;

/**
* Simple test case to exercise the scenegraph cache.
* This is not automated, because it depends on visual feedback.
* - Expected: The rectangle should resize with the window
* - Actual (before fix): The rectangle doesn't resize during animation
*
* @author Stephen Chin
*/
var width = 200;
var width2 = 200;

Timeline {
repeatCount: Timeline.INDEFINITE
autoReverse: true
keyFrames: [
KeyFrame {time: 1s, values: [
width => 400 tween Interpolator.EASEBOTH,
width2 => 400 tween Interpolator.EASEBOTH
]}
]
}.start();

Frame {
width: bind width
visible: true
stage: Stage {
content: [
Group {
cache: true
content: Rectangle {width: bind width2, height: 100, fill: Color.BLUE}
horizontalAlignment: HorizontalAlignment.CENTER
translateX: bind width / 2
}
]
}
}

Index: src/com/sun/scenario/scenegraph/SGRenderCache.java
===================================================================
--- src/com/sun/scenario/scenegraph/SGRenderCache.java (revision 306)
+++ src/com/sun/scenario/scenegraph/SGRenderCache.java (working copy)
@@ -187,7 +187,7 @@
@Override
void markDirty(int state) {
super.markDirty(state);
- if ((state & DIRTY_TRANSFORM) != 0) {
+ if (state == DIRTY_TRANSFORM) {
checkXform = true;
} else {
// TODO - mark the image dirty for VISUAL changes and reuse it
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net

Joshua Marinacci

Thank you very much Stephen. We appreciate all of your research. It
really helps.

- Josh

On Sep 20, 2008, at 2:51 PM, Stephen Chin wrote:

> I appreciate the fact you guys are working very, very hard on the
> JavaFX release. I also believe that JavaFX is worth the effort,
> which is why I have spend the time and effort to dig in on the
> serious issues I find. To reduce the bandwidth on you guys I have
> tried to do the following:
>
> * Focus only on problems that show up in JavaFX
> * Clearly describe the problem and any workarounds
> * Give a reproducible scenario (in this case I also included some
> code)
> * Provide a proposed fix as a patch that resolves the problem
>
>
> While this caching issue is in the Scenario code, it is a
> showstopper for a JavaFX program I am writing. I have an animated
> clock that uses node caching so the hour and minute hands don't need
> to be redrawn every time the second hand ticks. This caching bug
> causes the minute and hour hands to "stick" in the same position
> (showing the wrong time) until you force a repaint of the whole
> clock. The only workaround for this defect is to disable caching,
> which has a big performance impact for something I want to run on
> user's desktops constantly.
>
> In response to Jim's concerns about which bits are harmless, vs.
> which bits need to force a cache refresh, here is my analysis:
>
> * DIRTY_SUBREGION - Not applicable - This only gets set on Leaf
> nodes, so it will never never get set on an SGRenderCache
> node. Instead you will have the DIRTY_CHILDREN_VISUAL flag set
> (per
> implementation of SGNode.markSubregionDirty())
> * DIRTY_VISUAL - Should trigger cache flush - This flag is set a few
> places in the SGRenderCache specifically to force a repaint.
> * DIRTY_BOUNDS - Should trigger cache flush - The node bounds are
> used to size the image cache, so this needs to clear the cache.
> * DIRTY_TRANSFORM - Should set checkXForm, and may not need to clear
> the cache if it is just a translation
> * DIRTY_CHILDREN_VISUAL - Should trigger cache flush - One of the
> child nodes has changed appearance.
> * DIRTY_CHILDREN_BOUNDS - Should trigger cache flush - One of the
> child nodes has changed bounds. An example of this is
> SGNode.setVisible() which sets DIRTY_BOUNDS (and will trickle up
> as DIRTY_CHILDREN_BOUNDS to the SGRenderCache node). Hiding or
> showing a child node will definitely need to force a cache flush.
>
> So the quick summary is that the only case in which you can do the
> transform optimization in SGRenderCache is when only DIRTY_TRANSFORM
> is set. If any other bits are set on the state, you need to flush
> the cache and re-render the child nodes.
>
> I hope this helps. I've reattached the original scenario and patch,
> which I believe is the correct fix.
>
> Cheers,
> --Steve
>
> Joshua Marinacci wrote:
>> There hasn't been much work on scenegraph lately because we are
>> *all* working very, very hard on getting the JavaFX SDK out the
>> door. Thus only fixes needed for JavaFX are being worked on. Once
>> the SDK ships we'll have more time to look at these. I know it's
>> rough going right now, so if there are any possible workarounds
>> please use them.
>>
>> Thanks,
>> Josh
>>
>> On Sep 20, 2008, at 4:11 AM, Stephen Chin wrote:
>>
>>> Jim,
>>>
>>> Any update on this bug? I haven't noticed any fixes checked in to
>>> Subversion.
>>>
>>> In my opinion, it is a pretty serious defect, because it causes
>>> incorrect rendering when caching is enabled. Given the choice of
>>> correctness vs. performance, most people will have to choose the
>>> former, which may reflect poorly on the perceived performance of
>>> the JavaFX release.
>>>
>>> For now I can work around this by including my own Scenegraph jar
>>> file, but once the JavaFX 1.0 SDK comes out I won't have that
>>> luxury.
>>>
>>> Please tell me if there is anything I can do to help.
>>>
>>> Cheers,
>>> --Steve
>>>
>>> Stephen Chin wrote:
>>>> Thanks for picking this one up, Jim.
>>>>
>>>> I was going for the simplest fix that would work, but did notice
>>>> some
>>>> placeholders in the code for future work in this area.
>>>>
>>>> I would be happy to run a more involved fix through my full
>>>> application
>>>> if you want the additional validation.
>>>>
>>>> Cheers,
>>>> --Steve
>>>>
>>>> -----Original Message-----
>>>> From: Jim.A.Graham@Sun.COM [mailto:Jim.A.Graham@Sun.COM] Sent:
>>>> Monday, July 21, 2008 12:49 PM
>>>> To: dev@scenegraph.dev.java.net
>>>> Subject: Re: SGRenderCache Update Bug
>>>>
>>>> This will fix the situation at hand, but cause other problems.
>>>> The test
>>>>
>>>> for the TRANSFORM bit really does need to be a bit test as it can
>>>> often come with other bits set which are harmless with respect to
>>>> whether or not a transform check is sufficient. The problem is
>>>> that there are other bits which trump the transform check which
>>>> are not noticed by this
>>>>
>>>> test.
>>>>
>>>> Your fix will correctly avoid the transform check optimization if
>>>> another bit is set which trumps this optimization, but it will
>>>> also remove the optimization if any other harmless bits are set.
>>>>
>>>> What we need is more along the lines of:
>>>>
>>>> if (TX bit is set && are not set) {
>>>> checkXform = true;
>>>> } ...
>>>>
>>>> I'll have to do some investigation to figure out what those
>>>> "worse bits"
>>>>
>>>> are, but I'm catching up on 10 days of back email today... :-(
>>>>
>>>> ...jim
>>>>
>>>> Stephen Chin wrote:
>>>>
>>>>> I found a bug in scenegraph where the cache would prevent update
>>>>> of nested components in the case where there are translations
>>>>> and bounds changes happening in parallel.
>>>>>
>>>>> I've attached a stand-alone JavaFX Script example (CacheTest.fx)
>>>>> that can be used to reproduce the problem. This example may seem
>>>>>
>>>> contrived,
>>>>> but it is actually distilled down from a real-world example I
>>>>> stumbled
>>>>>
>>>>
>>>>
>>>>> on while developing WidgetFX, JavaFX Desktop
>>>>> Widget Platform >>>>> shamelessPlug>.
>>>>>
>>>>> When you run the example notice that during the animation the
>>>>> blue rectangle does not resize properly. To see the expected
>>>>> results, flip
>>>>>
>>>>
>>>>
>>>>> the cache property to false and rerun the example.
>>>>>
>>>>> Here is a candidate fix that solves this problem:
>>>>> |--- src/com/sun/scenario/scenegraph/SGRenderCache.java
>>>>> (revision
>>>>>
>>>> 306)
>>>>
>>>>> +++ src/com/sun/scenario/scenegraph/SGRenderCache.java (working
>>>>>
>>>> copy)
>>>>
>>>>> @@ -187,7 +187,7 @@
>>>>> @Override
>>>>> void markDirty(int state) {
>>>>> super.markDirty(state);
>>>>> - if ((state & DIRTY_TRANSFORM) != 0) {
>>>>> + if (state == DIRTY_TRANSFORM) {
>>>>> checkXform = true;
>>>>> } else {
>>>>> // TODO - mark the image dirty for VISUAL changes and
>>>>>
>>>> reuse it|
>>>>
>>>>> My theory is that prior to this change, if you had a combination
>>>>> of dirty flags (some for transform and some for bounds), it
>>>>> would be treated as a transform dirty check. If this check
>>>>> passed, then it
>>>>>
>>>> would
>>>>> not clear the cache, resulting in a stale image.
>>>>>
>>>>> I've also attached the fix as a patch file (cachefix.diff) that
>>>>> can be
>>>>>
>>>>
>>>>
>>>>> applied to the scenegraph trunk.
>>>>>
>>>>> Tell me if there is anything else I can do to help.
>>>>>
>>>>> Cheers,
>>>>> --Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>>>>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>>>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
>> For additional commands, e-mail: dev-help@scenegraph.dev.java.net
>>
>
> /*
> * CacheTest.fx
> *
> * Created on Jul 19, 2008, 8:10:25 PM
> */
>
> package org.widgetfx;
>
> import javafx.application.*;
> import javafx.scene.*;
> import javafx.animation.*;
> import javafx.scene.paint.Color;
> import javafx.scene.geometry.Rectangle;
>
> /**
> * Simple test case to exercise the scenegraph cache.
> * This is not automated, because it depends on visual feedback.
> * - Expected: The rectangle should resize with the window
> * - Actual (before fix): The rectangle doesn't resize during animation
> *
> * @author Stephen Chin
> */
> var width = 200;
> var width2 = 200;
>
> Timeline {
> repeatCount: Timeline.INDEFINITE
> autoReverse: true
> keyFrames: [
> KeyFrame {time: 1s, values: [
> width => 400 tween Interpolator.EASEBOTH,
> width2 => 400 tween Interpolator.EASEBOTH
> ]}
> ]
> }.start();
>
> Frame {
> width: bind width
> visible: true
> stage: Stage {
> content: [
> Group {
> cache: true
> content: Rectangle {width: bind width2, height: 100,
> fill: Color.BLUE}
> horizontalAlignment: HorizontalAlignment.CENTER
> translateX: bind width / 2
> }
> ]
> }
> }
>
> Index: src/com/sun/scenario/scenegraph/SGRenderCache.java
> ===================================================================
> --- src/com/sun/scenario/scenegraph/SGRenderCache.java (revision 306)
> +++ src/com/sun/scenario/scenegraph/SGRenderCache.java (working copy)
> @@ -187,7 +187,7 @@
> @Override
> void markDirty(int state) {
> super.markDirty(state);
> - if ((state & DIRTY_TRANSFORM) != 0) {
> + if (state == DIRTY_TRANSFORM) {
> checkXform = true;
> } else {
> // TODO - mark the image dirty for VISUAL changes and
> reuse it
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
> For additional commands, e-mail: dev-help@scenegraph.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@scenegraph.dev.java.net
For additional commands, e-mail: dev-help@scenegraph.dev.java.net