Re: (subplot changes) Outerposition Patch

[Ben Abbott]

On Feb 13, 2011, at 4:41 PM, logari81 wrote:

> On Sun, 2011-02-13 at 14:49 -0500, Ben Abbott wrote:
>> On Feb 13, 2011, at 2:03 PM, Ben Abbott wrote:
>> 
>> I've attached a changeset that decreases the margins between rows/columns. 
>> It looks to me like there remains to much space between the title and the 
>> axes position property. I haven't pushed this change as it looks to me like 
>> more needs to be done ..
>> 
> I think subplots look much better with the factor 0.7 you have used in
> your patch.
> 
> Concerning your question:
> " should the margins between the columns / rows be derived from the
> fontsize of the axis and its labels/title?"
> 
> I would say, no. Because this is done now during position/outerposition
> synchronization.

Can you give me a analytic description of how position/outerposition is 
synchronized? Also, how is the tightinset handled?

For reference, the tightinset is the difference between the edges of the 
position and outerposition boxes. This it is 1x4 double whose elements are 
ordered as  [left bottom right top].

The method Matlab uses is a bit convoluted.

        http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html

The gnuplot backend uses a simple scheme. Effectively gnuplot behaves as ...

        if (strcmp (get (gca, "activepositionproperty", "position"))
                position = get (gca, "position");
                inset = get (gca, "tightinset");
                outerposition = position + [-1,-1,1,1] .* tightinset;
        else
                outerposition = get (gca, "outerposition");
                inset = get (gca, "tightinset");
                position = outerposition + [1,1,-1,-1] .* tightinset;
        endif

We don't actually have access to the values for the tightinset (internal to 
gnuplot). So it is only the values associated with the activepositionproperty 
that are reflected in the result.

Matlab effectively does ...

        if (strcmp (get (gca, "activepositionproperty", "position"))
                position = get (gca, "position");
                inset = get (gca, "tightinset");
                # grow outerposition to accommodate the position and 
tightinset, but the outerposition box never lies *inside* the specified/default 
value.
                # Meaning some method to remember the specified outerposition 
is needed.
                .
                .
                .
        else
                outerposition = get (gca, "outerposition");
                inset = get (gca, "tightinset");
                # shrink position to accommodate the outerposition and 
tightinset, but the position box never lies *outside* the specified/default 
value.
                # Meaning some method to remember the specified position is 
needed.
                .
                .
                .
        endif

Is this the same or similar to what has been implemented?

Personally, I'd be happy to pass on the Matlab approach and use the approach of 
gnuplot. But we should discuss that on the list before deviating from the 
Matlab standard.

>> Specifically, I noticed that displaying the subplot demo is much slower. Is 
>> that due to "sync_positions"? What is happening here? Is the subplot 
>> function and the c++ side competing to synchronize the 
>> position/outerposition?
>> 
> some certain overhead due to positions synchronization is to be expected
> in general. I don't now if for subplots there is anything else that we
> should take into account. I will try to see if I can do some
> optimizations.
> 
>> If that is the case, I think subplot.m should be rewritten and let the c++ 
>> synchronization of position / outerposition do its job.
>> 
> Actually, I believe subplot should just create a layout for
> outerpositions of all subplots and let the c++ part decide for their
> positions.

Ok. I'll have a cleared understanding of this if you respond to the questions 
above.

>> Perhaps subplot() should only specify the outerposition, and let the c++ 
>> synchronization take care of the rest?
> 
> With regard to the issue with legends in demo axis 4, I have identified
> the problem but I don't know how easy it is to fix. The legend position
> is actually calculated correctly, but after a title is added to the
> subplots the position of its axes changes and we have no way to tell
> legend to update its position accordingly. Would this be easy to
> implement with listeners in the frontend?

A listener needs to be added that will triggers an update to the legend 
"position" when the "position" of the parent axes changes. 

I had thought that existed, but I see it is not there.

Ben