At time I am working with large vector maps (in 5.1).
Drawing a set of maps takes some time where the user
doesn't know if the drawing is already finished or
not.
[Yes, the machine is not so slow: 1 GHz]
My question is if it were possible to modify the XDRIVER
to show a hour glass cursor instead of the common arrow
when drawing in the GRASS monitor?
This is already implemented when the user is resizing
the monitor (redraw event).
Markus
Markus Neteler wrote:
My question is if it were possible to modify the XDRIVER
to show a hour glass cursor instead of the common arrow
when drawing in the GRASS monitor?
This is already implemented when the user is resizing
the monitor (redraw event).
By "drawing", do you actually mean:
a) drawing (i.e. from the point that a drawing command is received to
the time it completes), or
b) whenever a client is connected but isn't waiting on one of the
R_get_location_with_* functions, or
c) something else?
The problem with a) is that many drawing modules actually perform
multiple drawing operations; e.g. rasters are drawn using one command
per source row. There isn't any way for the driver to know where the
larger operation begins and ends. A straightforward implementation
would turn the pointer to an hourglass/clock at the start of each row
and back to the arrow at the end of each row, which might result in a
flickering cursor. This issue doesn't apply to redraw, which has a
definite start and end.
The problem with b) is that a client might wait on other sources of
input; although that would cause XDRIVER to stop responding to X
events, as get_command() blocks (this would also rule out using timers
to solve the problems with option a) ).
--
Glynn Clements <glynn.clements@virgin.net>
On Tue, Apr 29, 2003 at 11:56:59PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> My question is if it were possible to modify the XDRIVER
> to show a hour glass cursor instead of the common arrow
> when drawing in the GRASS monitor?
> This is already implemented when the user is resizing
> the monitor (redraw event).By "drawing", do you actually mean:
a) drawing (i.e. from the point that a drawing command is received to
the time it completes), or
Yes. For example:
GRASS 5.1.0-cvs:~ > time d.vect map=streetmap.shp
real 0m29.497s
user 0m12.998s
sys 0m3.318s
GRASS 5.1.0-cvs:~ > v.info streetmap.shp
|----------------------------------------------------------------------------|
| Type of Map: Vector (level: 2)
| Number of points: 0 Number of areas: 0
| Number of lines: 651414 Number of islands: 0
| Number of boundaries: 0 Number of faces: 0
| Number of centroids: 0 Number of kernels: 0
The file size is 110 MB.
When drawing several vector maps of this type, I wait of course even longer.
During the d.vect run the hour glass were great to see to be informed that
the drawing is still running (which is less obvious than for raster maps).
b) whenever a client is connected but isn't waiting on one of the
R_get_location_with_* functions, or
mhh, less important (for me).
c) something else?
The problem with a) is that many drawing modules actually perform
multiple drawing operations; e.g. rasters are drawn using one command
per source row. There isn't any way for the driver to know where the
larger operation begins and ends. A straightforward implementation
would turn the pointer to an hourglass/clock at the start of each row
and back to the arrow at the end of each row, which might result in a
flickering cursor. This issue doesn't apply to redraw, which has a
definite start and end.
But: while drawing one cannot resize the monitor. For this the draw
event is caught. Maybe it could be also used to change the cursor
(as it is exactly the same situation)?
Markus
Markus Neteler wrote:
> > My question is if it were possible to modify the XDRIVER
> > to show a hour glass cursor instead of the common arrow
> > when drawing in the GRASS monitor?
> > This is already implemented when the user is resizing
> > the monitor (redraw event).
>
> By "drawing", do you actually mean:
>
> a) drawing (i.e. from the point that a drawing command is received to
> the time it completes), orYes. For example:
GRASS 5.1.0-cvs:~ > time d.vect map=streetmap.shp
real 0m29.497s
user 0m12.998s
sys 0m3.318s
d.vect isn't a "drawing command" from the monitor's perspective.
d.vect repeatedly calls R_move_abs and R_cont_abs; each R_* function
is a "drawing command".
When drawing several vector maps of this type, I wait of course even longer.
During the d.vect run the hour glass were great to see to be informed that
the drawing is still running (which is less obvious than for raster maps).
Are you saying that you don't see anything until the command
completes?
> b) whenever a client is connected but isn't waiting on one of the
> R_get_location_with_* functions, ormhh, less important (for me).
> c) something else?
>
> The problem with a) is that many drawing modules actually perform
> multiple drawing operations; e.g. rasters are drawn using one command
> per source row. There isn't any way for the driver to know where the
> larger operation begins and ends. A straightforward implementation
> would turn the pointer to an hourglass/clock at the start of each row
> and back to the arrow at the end of each row, which might result in a
> flickering cursor. This issue doesn't apply to redraw, which has a
> definite start and end.But: while drawing one cannot resize the monitor. For this the draw
event is caught. Maybe it could be also used to change the cursor
(as it is exactly the same situation)?
That's basically option b). The monitor cannot be resized while a
client is connected; it doesn't matter if it's drawing, waiting on
R_get_location_with_*, or just doing nothing.
The main reason for not taking that route is that it might result in
long-running programs displaying the hourglass cursor inappropriately.
OTOH, you might be willing to live with that.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, May 01, 2003 at 05:08:12AM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> > > My question is if it were possible to modify the XDRIVER
> > > to show a hour glass cursor instead of the common arrow
> > > when drawing in the GRASS monitor?
> > > This is already implemented when the user is resizing
> > > the monitor (redraw event).
> >
> > By "drawing", do you actually mean:
> >
> > a) drawing (i.e. from the point that a drawing command is received to
> > the time it completes), or
>
> Yes. For example:
>
> GRASS 5.1.0-cvs:~ > time d.vect map=streetmap.shp
>
> real 0m29.497s
> user 0m12.998s
> sys 0m3.318sd.vect isn't a "drawing command" from the monitor's perspective.
d.vect repeatedly calls R_move_abs and R_cont_abs; each R_* function
is a "drawing command".
Ah, ok. I was describing it from a users perpective.
> When drawing several vector maps of this type, I wait of course even longer.
> During the d.vect run the hour glass were great to see to be informed that
> the drawing is still running (which is less obvious than for raster maps).Are you saying that you don't see anything until the command
completes?
No, I can watch it while the vectors are drawn. But with vector (steets)
maps it's difficult to estimate when it is done if you draw for a large area
and don't know the map well (yet). Raster is drawn top-down, so you know
that it is obviously done when the last line at bottom is drawn.
> > b) whenever a client is connected but isn't waiting on one of the
> > R_get_location_with_* functions, or
>
> mhh, less important (for me).
>
> > c) something else?
> >
> > The problem with a) is that many drawing modules actually perform
> > multiple drawing operations; e.g. rasters are drawn using one command
> > per source row. There isn't any way for the driver to know where the
> > larger operation begins and ends. A straightforward implementation
> > would turn the pointer to an hourglass/clock at the start of each row
> > and back to the arrow at the end of each row, which might result in a
> > flickering cursor. This issue doesn't apply to redraw, which has a
> > definite start and end.
>
> But: while drawing one cannot resize the monitor. For this the draw
> event is caught. Maybe it could be also used to change the cursor
> (as it is exactly the same situation)?That's basically option b). The monitor cannot be resized while a
client is connected; it doesn't matter if it's drawing, waiting on
R_get_location_with_*, or just doing nothing.The main reason for not taking that route is that it might result in
long-running programs displaying the hourglass cursor inappropriately.
OTOH, you might be willing to live with that.
You mean live with the latter?
OK, maybe I drop that suggestions, it seems to be too complicated.
Thanks for your comments,
Markus
Markus Neteler wrote:
> > But: while drawing one cannot resize the monitor. For this the draw
> > event is caught. Maybe it could be also used to change the cursor
> > (as it is exactly the same situation)?
>
> That's basically option b). The monitor cannot be resized while a
> client is connected; it doesn't matter if it's drawing, waiting on
> R_get_location_with_*, or just doing nothing.
>
> The main reason for not taking that route is that it might result in
> long-running programs displaying the hourglass cursor inappropriately.
> OTOH, you might be willing to live with that.You mean live with the latter?
I mean live with it displaying the hourglass being displayed when it
shouldn't be.
OK, maybe I drop that suggestions, it seems to be too complicated.
Implementation is non-trivial, but not excessive. The problem is
whether the end result will actually be desirable.
The key issue is that the driver doesn't get to see the "big picture".
It knows when a client connects and disconnects, and it knows when
it's actually performing a drawing command (drawing one row of a
raster, drawing a single line, drawing a polyline etc).
But it doesn't know about larger operations (e.g. drawing an entire
map), other than by assuming that they last for the lifetime of the
client, minus any time spent in the R_get_location_with_* handlers.
This is a reasonable assumption for simple clients (d.rast, d.vect
etc), but maybe not for more complex ones.
--
Glynn Clements <glynn.clements@virgin.net>