[Rd] using rasterImage within image

[Paul Murrell]

Hi

On 10/02/2011 7:54 p.m., Michael Sumner wrote:
> Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
> 2011-02-09 r54308.

Bother.  Thanks very much for testing.  I'll keep looking.

Paul

> To reproduce, in a fresh R session (Windows in SDI mode):
>
> ## create a dummy dataset
> m<- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)
>
> ## simple helper function to open the windows() device and plot the matrix
> draw.f<- function(x) {
>     plot(0, xlim = c(0, 1), ylim = c(0, 1))
>     rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
> }
>
> draw.f(m)
>
> ## repeat the following 2 lines five times:
>
> dev.off()
> draw.f(m)
>
> On the fifth attempt, only the background plot appears - but the
> raster is visible on resize of the windows() device.
>
> Cheers, Mike.
>
> sessionInfo()
> R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
> Platform: x86_64-pc-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
>
>
> On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
> <baptiste.auguie at googlemail.com>  wrote:
>> Dear all,
>>
>> Back when grid.raster() was introduced, it was suggested that perhaps
>> grid.rect() could use grid.raster() in case of even spacing. The
>> response at the time was that it would be best to keep the two
>> functions separate at a lower level, that is grid.rect() and
>> grid.raster(), but perhaps a new function grid.image() could be
>> proposed at a higher level with the two possible backends. If this is
>> done in grid graphics, perhaps the same convention could be used for
>> base graphics: image() would be high level with the backend option,
>> and a new function ("tiles()", perhaps?) would implement the current
>> behavior of image().
>>
>> In any case, it would be nice to have a unified scheme to switch
>> between "tiles" and raster; currently lattice (panl.levelplot.raster)
>> and a few other packages all do it separately.
>>
>> Best wishes,
>>
>> baptiste
>>
>>
>>
>> On 9 February 2011 23:29, Ben Bolker<bbolker at gmail.com>  wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>>>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>>>> <simon.urbanek at r-project.org>  wrote:
>>>>>
>>>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>>>
>>>>>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>>>>>> <simon.urbanek at r-project.org>  wrote:
>>>>>>> Ben,
>>>>>>>
>>>>>>> I have committed something analogous to R-devel (your rotation
>>>>>>> code was not unlike mine, I replicated the color handling from
>>>>>>> R internals to be consistent, I fixed the drawing limits and
>>>>>>> added a check for x/y conformance). Note that useRaster can
>>>>>>> only be used when x, y form a regular grid. Although I tried a
>>>>>>> lot of corner cases (requiring quite a few fixes), I'm sure I
>>>>>>> did not test all of them, so volunteers please give it a go and
>>>>>>> compare it with non-raster output.
>>>>>>>
>>>>>>> The only thing I'm not quite happy about is the argument name:
>>>>>>> useRaster. Personally, I hate camel case in R (it has crept in
>>>>>>> more recently making it horribly inconsistent) so please feel
>>>>>>> free to suggest a better name ;).
>>>>>>
>>>>>> It.is.spelled.camelCase.
>>>>>>
>>>>>
>>>>> Fortunately not in English ;)
>>>>>
>>>>>
>>>>>> What about style=c("image", "raster")?  This allows for future
>>>>>> extensions too.
>>>>>>
>>>>>
>>>>> Hmm.. it's not really a "style" - the output doesn't change
>>>>> (ideally) - it's more of a back-end specification .. also we
>>>>> already have oldstyle argument in image() adding to the confusion
>>>>> ...
>>>>
>>>> flavor=c("image", "raster") renderer=c("image", "raster")
>>>> backend=c("image", "raster") ...
>>>
>>>   Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
>>> or do we need a warning/workaround there?)
>>>
>>>   I like "backend", or possibly "method"
>>>
>>>   One minor consideration: if "raster" eventually becomes the default
>>> (as I hope it will), there would need to be some internal logic that
>>> drops back to "image" if the user specifies uneven spacing and doesn't
>>> explicitly specify the 'backend/method' parameter ...
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
>>> ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
>>> =/da6
>>> -----END PGP SIGNATURE-----
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>

-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/