From felix at nfrac.org  Thu Nov 20 05:26:24 2008
From: felix at nfrac.org (Felix Andrews)
Date: Thu, 20 Nov 2008 15:26:24 +1100
Subject: [Rd] Buggy trellis.focus() with xyplot ?
In-Reply-To: <332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com>
References: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com>
	<eb555e660811191733t707d52f3m6eb7f5985d6c8c11@mail.gmail.com>
	<94730b8a0811191810p1c1f5108x61fa899db1f9c8ef@mail.gmail.com>
	<332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com>
Message-ID: <94730b8a0811192026j119657aay6dfb8d699d01ddea@mail.gmail.com>

2008/11/20 Daniel Kornhauser <dkor at northwestern.edu>:
> Thanks a lot for taking this on guys !
>
> Some more background in case you are interested:
>
> I have almost a working version of focus for selecting a panel with mouse
> over in a stanalone Java application using an REngine I only have two
> issues:
>
> - trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes
> 1.5 seconds to unfocus, do you know any way to speed it up ?

Yep, redrawing R plots is slow. If you remove a grob the whole plot
needs to be redrawn. The solution is to use highlight = FALSE in the
trellis.focus() command. Obviously then there will be no visual
indication (red outline) of which panel is in focus. (If you need that
you could draw it yourself and then overpaint it with white to hide
it, maybe... the best solution would be to draw it using Java
graphics, rather than R graphics, and store a buffer, but I don't know
whether that's possible in your system).

>
> - the conversion problem that Deepayan referred too in the previous, but I
> guess that will be fixed soon. :-)
>
>
> I am working in a bastardized version of trellis.focus taking an x and y
> from an event handler (in Java, C, etc ...) which focuses and highlights the
> panel so the REngine instance can perform more operations on the selected
> panel.
> This would be very useful for easily creating GUI for interactive
> visualizations exploration of large multidimensional data sets using lattice
> and geared towards non programmers.
>
> I don't really know what I am getting into, so any advice would be welcomed.

Sounds similar to some of the functionality of the 'playwith' and/or
'latticist' packages. You might want to look at them. playwith is
built with GTK+.

>
> Daniel.
>
>
> 2008/11/19 Felix Andrews <felix at nfrac.org>
>>
>> 2008/11/20 Deepayan Sarkar <deepayan.sarkar at gmail.com>:
>> > On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
>> > <dkor at northwestern.edu> wrote:
>> >> Hi:
>> >>
>> >> (Tried to find a bug report about this issue, but was unable to find
>> >> it, let
>> >> me know if this is a known issue)
>> >> I have been working on an interface to highlight xyplot panels on mouse
>> >> overs in JavaGD but I have stumbled with what seems to be a bug in
>> >> trellis.focus.
>> >> I am using R 2.8 with lattice 0.17-15
>> >>
>> >>
>> >> *** To replicate the bug:
>> >> 1.- display an xyplot. For example, from the xyplot help page:
>> >> library(lattice)
>> >> require(stats)
>> >> EE <- equal.count(ethanol$E, number=9, overlap=1/4)
>> >> ## Constructing panel functions on the fly; prepanel
>> >> xyplot(NOx ~ C | EE, data = ethanol,
>> >>       prepanel = function(x, y) prepanel.loess(x, y, span = 1),
>> >>       xlab = "Compression Ratio", ylab = "NOx (micrograms/J)",
>> >>       panel = function(x, y) {
>> >>           panel.grid(h=-1, v= 2)
>> >>           panel.xyplot(x, y)
>> >>           panel.loess(x,y, span=1)
>> >>       },
>> >>       aspect = "xy")
>> >> 2.- resize to window be rectangular and have large margins in the left
>> >> hand
>> >> and right hand side.
>> >> 3.- run trellis.focus() and try to select the first or last panel, you
>> >> should observe that it does not select the right one.
>> >>
>> >> sidenotes:
>> >> There are other problems with the focus in JavaGD but I just wanted to
>> >> include a simple self contained example in this mail.
>> >> If you make the window smaller, trellis.focus() works fine, you have to
>> >> make
>> >> it bigger than the initial size.
>> >>
>> >>
>> >> *** To Fix the bug:
>> >> I tried to fix this bug in interraction.R but I was unsuccesful.
>> >>
>> >> The problem should stem from the a bad calculation of the pads in the
>> >> follwoing lines :
>> >>        leftPad <-
>> >> convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), "npc",
>> >> valueOnly = TRUE)
>> >>        rightPad <-
>> >> convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]),
>> >> "npc",
>> >> valueOnly = TRUE)
>> >>        topPad <-
>> >> convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), "npc",
>> >> valueOnly = TRUE)
>> >>        botPad <-
>> >> convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]),
>> >> "npc",
>> >> valueOnly = TRUE)
>> >>
>> >> I was succesful in tweaking the follwing lines adding arbitrary
>> >> constants to
>> >> make it work for a particular instance of a xyplot with a particular
>> >> size of
>> >> a window
>> >>       clickXScaled <- (as.numeric(clickLoc$x) - leftPad +
>> >> Danielconstant1)
>> >> / (1 - leftPad - rightPad  + Danielconstant1)
>> >>        ....
>> >>        clickYScaled <- (as.numeric(clickLoc$y) - botPad +
>> >> Danielconstant2)
>> >> / (1 - botPad - topPad + Danielconstant3)
>> >> This is of course a useless fix, since you want the fix to work for any
>> >> plot
>> >> with any window size, but I might be valuable information.
>> >>
>> >>
>> >> *** Questions:
>> >> - Is this a real bug ?
>> >> - Any suggestions for fixing it ?
>> >> - If it can't be fixed, is there a way around this bug ?
>> >> (For example, setting the margins to be zero and set a fixed size for
>> >> the
>> >> xplot)
>> >
>> > It appears that the conversions used in the current implementation
>> > (contributed by Felix Andrews) don't work when aspect != "fill"
>> > (probably leading back to the use of 'respect = TRUE' in grid.layout).
>>
>> Yep, my fault, didn't think it through.
>>
>> > The right way to do this is to first go down to the subregion
>> > containing just the panels, and then locate the click location within
>> > it. But this requires a suitable viewport to be predefined.
>> >
>> > I have changed print.trellis to create such a dummy viewport
>> > (accessible by trellis.focus("figure")), and modified trellis.focus()
>> > to use it. I will test it a bit more before uploading a new version
>> > (and also give Felix a chance to see if this breaks anything in
>>
>> It won't affect playwith; playwith now uses a different approach: a
>> function
>> inViewport(x.px, y.px, viewport)
>> reports whether a click location in pixels is inside the given
>> viewport. I loop through each panel viewport and check whether the
>> click is inside.
>>
>> > playwith etc.). To see if the fix works, you can try the svn copy at
>> >
>> > https://svn.r-project.org/R-packages/trunk/lattice
>> >
>> > -Deepayan
>> >
>>
>>
>> --
>> Felix Andrews / ???
>> http://www.neurofractal.org/felix/
>> 3358 543D AAC6 22C2 D336  80D9 360B 72DD 3E4C F5D8
>
>



-- 
Felix Andrews / ???
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336  80D9 360B 72DD 3E4C F5D8



[Rd] Buggy trellis.focus() with xyplot ?
Felix Andrews