Re: (subplot changes) Outerposition Patch

[logari81]

On Sun, 2011-02-13 at 14:49 -0500, Ben Abbott wrote:
> On Feb 13, 2011, at 2:03 PM, Ben Abbott wrote:
> 
> > On Feb 13, 2011, at 12:05 PM, logari81 wrote:
> > 
> >> On Thu, 2011-02-10 at 20:00 +0100, Konstantinos Poulios wrote:
> >>> On Thu, Feb 10, 2011 at 1:59 PM, Konstantinos Poulios
> >>> <address@hidden> wrote:
> >>>> On Thu, Feb 10, 2011 at 9:25 AM, David Bateman <address@hidden> wrote:
> >>>>> 
> >>>>> Le 10 févr. 2011 à 00:25, logari81 <address@hidden> a écrit :
> >>>>> 
> >>>>>>> 
> >>>>>> thank you for this information.
> >>>>>> 
> >>>>>> It seems that the previously attached patch causes problems only with
> >>>>>> legends. However, in order to treat legends correctly I need to
> >>>>>> understand their logic. How do legends exploit the outerposition and
> >>>>>> position properties? Is anyone familiar with legend.m to give me a 
> >>>>>> short
> >>>>>> introduction?
> >>>>>> 
> >>>>>> Best regards
> >>>>>> 
> >>>>> You shouldn't try to understand the logic of legend's use of the 
> >>>>> position and outerposition properties. It's just a hack that worked 
> >>>>> with the existing behavior. If your patch doesn't work well with legend 
> >>>>> it is probably legend that needs to be fixed
> >>>>> 
> >>>>> D.
> >>>> 
> >>>> The attached patch replaces the previous one and implements the
> >>>> calculation of both position and outerposition depending on the value
> >>>> of activepositionproperty.
> >>>> 
> >>>> It is not very well tested yet, so there will probably be some issues,
> >>>> e.g. legends will not work, but it brings a feature that maybe is
> >>>> awesome. It is something that Matlab cannot do and maybe you like it.
> >>>> See the following video:
> >>>> 
> >>>> http://ubuntuone.com/p/cYM/
> >>>> 
> >>>> The position property is calculated dynamically while you rotate the
> >>>> view, so that all labels fit in outerposition. I think it works quite
> >>>> well in order to keep it. What do you think?
> >>>> 
> >>>> As this operation involves certain computational overhead, it would be
> >>>> interesting to get some tests on older machines. Unfortunately all
> >>>> pc's that I have access to, are too fast.
> >>>> 
> >>>> This patch also fixes http://savannah.gnu.org/bugs/?31610 for the fltk 
> >>>> toolkit.
> >>>> 
> >>>> Finally, if we adopt the attached patch we have to adapt legend.m also.
> >>>> 
> >>>> BR
> >>>> 
> >>>> Kostas
> >>> 
> >>> After some more testing and fixes I think the patch is quite mature in
> >>> the form you find in the attachment. I think it could be checked in.
> >>> 
> >> I have just checked in this changeset along with some further
> >> fixes/improvements. Now, I would like to provide some additional
> >> information and ask for some help with regard to the open issues that I
> >> had listed.
> >> 
> >>> There are still some general issues with fltk that I will try to sum up:
> >>> 
> >>> 1. In some demo plots axes labels seem to be too close to the axes
> >>> (e.g. demo legend 9). Probably in some of the previous changes there
> >>> is something that I have overseen.
> >>> 
> >> Actually after testing older revisions of octave I realized that the
> >> problem is not new. The reason that I hadn't noticed it before is
> >> because the problem appears only in the print output and not in the plot
> >> window. It seems that gl-render and gl2ps position strings differently
> >> considering either the bottom line or the baseline of the string
> >> respectively. It is not difficult to fix, we just have to decide which
> >> of gl-render and gl2ps are we going to fix in order to make both
> >> consistent.
> > 
> > I suspect the culprit may be that gl2ps requires assumes that the DPI is 72.
> > 
> > Perhaps the font position is correct, but the fontsize is off by 100/72? 
> > But is that due to a bug in gl2ps or a problem with Octave's positioning of 
> > text objects?
> > 
> >>> 2. Legends for barplots don't show colors (this is an old problem).
> >>> 
> >>> 3. Some small y axes interference for plotyy (also not new).
> >>> 
> >>> 4. Now there is no labels-titles interference in demo subplot 1, so
> >>> there is no need for extra space between the subplots, we can reduce a
> >>> bit the padding (someone which is familiar with subplot.m I suppose).
> >>> 
> >> Waiting for someone familiar with subplot.m
> > 
> > I'll take a look.
> 
> 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.

> 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.

> Perhaps subplot() should only specify the outerposition, and let the c++ 
> synchronization take care of the rest?
> 
> Ben
> 

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?

Kostas