Re: [jira] Created: (PIVOT-226) Cached preferred size values cause layout problems in BoxPane

[Niclas Hedhman <ni...@hedhman.org>]

Another option is to not centralize caching in the component inheritance
hierarchy and instead provide external caching strategy concerns that the
components can engage.... oops, this is not Qi4j... seriously, I think that
caching responsibility should not be generic... and there are a couple of
ways to provide it.

Also, if you have components with real quick siye calculation, you have just
wasted memory ;-)

-- Niclas

On Aug 11, 2009 10:44 PM, "Greg Brown (JIRA)" <ji...@apache.org> wrote:

Cached preferred size values cause layout problems in BoxPane
-------------------------------------------------------------

                Key: PIVOT-226
                URL: https://issues.apache.org/jira/browse/PIVOT-226
            Project: Pivot
         Issue Type: Bug
   Affects Versions: 1.3
           Reporter: Greg Brown
           Assignee: Greg Brown
           Priority: Minor
            Fix For: 1.3


We currently cache the values of the preferred size calculations for
performance reasons. As a result, when a vertical BoxPane is set to fill the
available space, the widest component doesn't get scaled up (nor do any
other components that report the same preferred width).

One possible fix is to call invalidate() on the component in
BoxPane#layout() before asking it for its constrained preferred height. That
ensures that we get the correct value, and it doesn't impose a significant
performance penalty most of the time.

However, this may not be the "right" place to put this logic. Since this is
a side effect of caching logic in Component, the logic for invalidating the
cache probably also belongs in Component. Ideally, containers such as
BoxPane shouldn't need to know that they must call invalidate() in order to
clear the cache.

A better solution may be to add a method to Skin that will allow Component
to ask it how to handle cases like this. The exact nature/name of this
method is TBD. Some ideas:

isFixedAspectRatio():boolean
isVariableAspectRatio():boolean
getPreferredAspectRatio():float (if Float.NaN, aspect ratio is not fixed)

If any of these return true/non-NaN, Component would know that it shouldn't
use the cached value.



--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (PIVOT-226) Cached preferred size values cause layout problems in BoxPane

[Greg Brown <gk...@mac.com>]

We had actually talked about performing caching in the container skins  
that required it. This would have put the responsibility for caching  
in the "right" place, but would have produced a lot of code  
duplication. The current approach is just the centralization of that  
logic.

This issue is an edge case that we hadn't considered, but I think it  
can be addressed pretty easily by providing a small amount of  
additional information to Component.


On Aug 11, 2009, at 12:14 PM, Niclas Hedhman wrote:

> Another option is to not centralize caching in the component  
> inheritance
> hierarchy and instead provide external caching strategy concerns  
> that the
> components can engage.... oops, this is not Qi4j... seriously, I  
> think that
> caching responsibility should not be generic... and there are a  
> couple of
> ways to provide it.
>
> Also, if you have components with real quick siye calculation, you  
> have just
> wasted memory ;-)
>
> -- Niclas
>
> On Aug 11, 2009 10:44 PM, "Greg Brown (JIRA)" <ji...@apache.org> wrote:
>
> Cached preferred size values cause layout problems in BoxPane
> -------------------------------------------------------------
>
>                Key: PIVOT-226
>                URL: https://issues.apache.org/jira/browse/PIVOT-226
>            Project: Pivot
>         Issue Type: Bug
>   Affects Versions: 1.3
>           Reporter: Greg Brown
>           Assignee: Greg Brown
>           Priority: Minor
>            Fix For: 1.3
>
>
> We currently cache the values of the preferred size calculations for
> performance reasons. As a result, when a vertical BoxPane is set to  
> fill the
> available space, the widest component doesn't get scaled up (nor do  
> any
> other components that report the same preferred width).
>
> One possible fix is to call invalidate() on the component in
> BoxPane#layout() before asking it for its constrained preferred  
> height. That
> ensures that we get the correct value, and it doesn't impose a  
> significant
> performance penalty most of the time.
>
> However, this may not be the "right" place to put this logic. Since  
> this is
> a side effect of caching logic in Component, the logic for  
> invalidating the
> cache probably also belongs in Component. Ideally, containers such as
> BoxPane shouldn't need to know that they must call invalidate() in  
> order to
> clear the cache.
>
> A better solution may be to add a method to Skin that will allow  
> Component
> to ask it how to handle cases like this. The exact nature/name of this
> method is TBD. Some ideas:
>
> isFixedAspectRatio():boolean
> isVariableAspectRatio():boolean
> getPreferredAspectRatio():float (if Float.NaN, aspect ratio is not  
> fixed)
>
> If any of these return true/non-NaN, Component would know that it  
> shouldn't
> use the cached value.
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.