[GRASS-dev] Cairo monitor driver

[Lars Ahlzen]

Glynn Clements wrote:
>> Yes, it was primarily to ensure that lines are connected (for nice line 
>> joins etc). But I guess you're right - that's what polyline is for.
> 
> Alas, many things which could use it don't. It doesn't help that the
> R_polyline_* interface is less convenient than R_{move,cont}_*. Adding
> begin/end for paths is a priority for 7.x.

That's a pity (although it does explain a few things). Either way, we 
won't "hack" it, but instead wait for GRASS 7 to fix the problem at its 
source.

>> I believe this means that pretty much all of drawing.c can go... 
> 
> This should make the code significantly easier to understand. At the
> present time, the cairo driver is probably more useful as an example
> of how to use cairo than anything else.

Yes. I'll remove all of the set_drawing_op/finish_drawing_op code.

Once (reasonably) feature complete and stable, the cairo driver could be 
a good alternative to the other monitors, however. I've used it for 
quite a while (before it was announced) and I've found it very useful. 
Then again, I may be somewhat biased... :)

>>> The global cairo_translate(cairo, 0.5, 0.5) is wrong...
>>
>> Well, this one is a little bit tricky.
>>
>> [...]
> 
> That's incorrect. The drivers handle fills correctly, i.e. coordinates
> are interpreted as points in 2D space, not as pixel indices. E.g. 
> R_box_abs(10, 2, 20, 3) will fill 10 pixels for the X and PNG drivers,
> i.e. all <x,y> where 10 <= x < 20 and y == 2.
> 
> You're assuming that the drivers get fills wrong; they don't. With
> lines, they have no choice (well, the pixel-based ones don't; the PS
> driver doesn't do translation).

I stand corrected. Then it makes sense to apply the offset to lines 
only, as you originally suggested. Thanks for clearing up my confusion.

> It definitely doesn't belong on fills, and it's debatable whether it
> should be applied to lines.

Yes, neither option is perfect. I would recommend to still apply it to 
lines, though. This should produce output that is both closer to that of 
other monitors, and generally a clearer result (in most cases).

Remember, it still only applies to PNG output, all other formats are 
completely untranslated, just like the PS driver.

I'll remove translation for everything but lines.

> There is a third option: only use even line widths.

True, although that's probably not a realistic option at present.

>> [...]
>> Does complete documentation for these areas exist?
> 
> Nope.
> 
> Although, the PS driver is probably the best reference for the cairo
> driver, as cairo was heavily modelled on PostScript, and the PS driver
> is the closest to how it "should" work (as it doesn't have to deal
> with pixel-grid issues).

Ok. That will of course make it more difficult to implement functions 
like draw_text that are neither documented nor implemented by other 
drivers (as far as I can tell).

>> Given the text rendering support in Cairo, I hope that adding good 
>> quality text rendering will be relatively straightforward as well.
>>
>> I take it that the best thing for me to do right now would be to work on 
>>   the mentioned issues and missing features and post a patch? Perhaps 
>> add basic documentation in display/drivers/cairo as well?
> 
> There's not much point in documenting the internals...
> 
> IOW, if you write documentation, most of it will end up becoming out
> of date and getting rewritten long before anyone ever reads it.

I actually meant *user* documentation, similar to e.g.
http://grass.itc.it/grass63/manuals/html63_user/psdriver.html

Anyway, I'll get working on the code changes...

/ Lars

-- 
Lars Ahlzen
lars at ahlzen.com