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 <bbol...@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.urba...@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.urba...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
