On Tue, Feb 15, 2011 at 1:12 PM, Ben Abbott <
address@hidden> wrote:
>
> 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?
yes, but for 2D plots it should stop after the 1st iteration step. For
3D plots it could possibly do 3-4 iterations but as shown in the
screencast I had uploaded it didn't cause any performance problems
e.g. with responsiveness while rotating the plot.
In any case the subplot demo shouldn't noticeably longer to render, I
will try to debug this case a bit in order to see why that happens.