Re: (subplot changes) Outerposition Patch

[Ben Abbott]

On Feb 14, 2011, at 10:49 AM, Konstantinos Poulios wrote:

> On Sun, Feb 13, 2011 at 11:29 PM, Ben Abbott <address@hidden> wrote:
>> 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
> 
> Actually the subroutine sync_positions in graphics.cc corresponds to
> the behavior you described for Matlab. There are only two exceptions
> with respect to the activepositionproperty=outrerposition case:
> 
> 1. For 3D plots the inset depends on the position property, so that it
> cannot be calculated a priori. Currently in Octave the axes position
> is determined iteratively by shrinking gradually the position box and
> recalculating the new inset each time. Matlab doesn't do this, it
> seems to calculate position in one step using some approximation of
> the inset. The following video shows the positions behavior in Octave:
> http://ubuntuone.com/p/cYM/
> 
> 2. I have set a lower limit for the automatic calculated position
> property at 20% of the width/height of outerposition. You can test
> this if you try too resize the plot window to tiny dimensions. In
> Matlab the axes will disappear, only labels will remain visible. In
> Octave axes will never disappear, the labels will be cropped if
> position width/height falls bellow 20% of outerposition.
> 
> One comment: I haven't given access to the calculated tight inset
> values to the frontend yet, so get(h,'tightinset') still returns zeros
> but I am going to push a changeset later in order to fix this.
> 
> BR
> 
> Kostas

Why do the subplot demos take so long to render?

Is the process you're using iterative?

Ben