Hi,
If I do
d.barscale -m -n
and click around a few spots with the left mouse button, then cancel
with the middle button, black dots are left on the screen at the bottom
left of where each arrow was placed.
Xdriver or d.barscale bug?
Hamish
Hi,
If I do
d.barscale -m -n
and click around a few spots with the left mouse button, then cancel
with the middle button, black dots are left on the screen at the bottom
left of where each arrow was placed.
Xdriver or d.barscale bug?
Hamish
Hamish wrote:
d.barscale -m -n
and click around a few spots with the left mouse button, then cancel
with the middle button, black dots are left on the screen at the bottom
left of where each arrow was placed.Xdriver or d.barscale bug?
d.barscale. It's computing the bounds of the modified region
incorrectly, so it isn't saving (and restoring) enough of the display
contents.
--
Glynn Clements <glynn@gclements.plus.com>
I've fixed the bug.
Huidae Cho
On Wed, Mar 01, 2006 at 05:43:27PM +0000, Glynn Clements wrote:
Hamish wrote:
> d.barscale -m -n
>
> and click around a few spots with the left mouse button, then cancel
> with the middle button, black dots are left on the screen at the bottom
> left of where each arrow was placed.
>
> Xdriver or d.barscale bug?d.barscale. It's computing the bounds of the modified region
incorrectly, so it isn't saving (and restoring) enough of the display
contents.--
Glynn Clements <glynn@gclements.plus.com>_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
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?
Hamish
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@gclements.plus.com>