[GRASS5] d.barscale drawing bug

Glynn Clements glynn at gclements.plus.com
Thu Mar 2 13:34:51 EST 2006


Hamish wrote:

> > d.barscale. It's computing the bounds of the modified region
> > incorrectly, so it isn't saving (and restoring) enough of the display
> > contents.
> 
> Interesting... so (without studying the code) R_panel_save() and
> R_panel_restore() are only acting on a zoomed chunk, not the whole
> frame? That's quite a bit faster than what I had thought.. I've
> been wanting to move the d.barscale mouse placement code to other
> modules (eg d.legend, d.text.freetype, etc) for a while but it seemed
> rather inefficient to save & restore the entire monitor contents to the
> disk each time.
> 
> Have I got that right?

Yes. R_panel_save() saves a specified rectangle of the screen to disk. 
It's usually used for interactive placement, in conjunction with the
R_get_location_with_* functions, to allow you to undo placement
without having to redraw everything.

As they are only used by interactive programs, the panel functions
aren't implemented by the PNG driver.

In any case, mouse placement is top of the list for removal from the
display architecture. The intention is for the GUI to handle the
placement and to just pass the position (and optionally dimensions) on
the command-line.

Better still would be to do the whole thing in the GUI, i.e. render a
barscale, legend etc to an image, which is added to the canvas as a
separate entity. That would make it feasible to drag the item around
the canvas in real-time. For text labels, you wouldn't even need to
render them, just use text objects.

The only drawback with this approach (compared to compositing) is that
you can't place such items beneath a masked image. In practice, I
doubt that would really matter.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list