On Tue, Feb 15, 2011 at 3:12 PM, Konstantinos Poulios
<
address@hidden> wrote:
> 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.
>
>> Ben
>>
>
> Kostas
>
Hi Ben, I have tested the subplot demo again and I verified that the
iterative calculation of position terminates after a single iteration
step as expected. So it shouldn't add any extra computational
overhead. In my system the demo subplot renders quite fast, so I
cannot explain your observation. Could you maybe compare with previous
revisions of octave?
Concerning subplot in general, I think the layout is quite bad. Now
there is no labels overlapping but the subplots are not very well
aligned and the margin to the left and bottom of the plot window is
extreme. I think we should fix this in subplot.m. Matlab uses
activepositionproperty=position for aligning the subplots to a grid.
Now that we have support for get(h,'tightinset') we have the
possibility of doing the same as ML but we need some listeners, in
case titles and axes labels change.
Actually what I propose is to reimplement sync_positions in the
frontend only for subplot. The algorithm would look like:
1. Get tightinsets for all subplots
2. Find maximum tightinsets for all columns and rows
3. Set the position property of all subplots so that they are row and
column aligned.
What do you think?
Kostas