Sagewire Logo

How do I get smooth handwriting on a Tablet PC using JAVA2/Swing?

11 Message(s) by 4 Author(s) originally posted in java machine


From: Christian Stapfer Date:   Saturday, March 17, 2007
I've written a distributed presentation/whiteboarding application
(JAVA2/Swing) for online-tutoring. Currently I use a graphics tablet to draw
and write on the whiteboard.
Now I'd like to switch from using a separate graphics tablet to
using the stylus of a Tablet PC. However, my JAVA application seems to drop
a great many mouse drag event s, which results in hardly legible handwriting
(not so with native Tablet PC applications like Windows Journal).

http://www.freesoft.org/software/tablet-JAVA/ suggests patching the JAVA
runtime to solve this problem - an idea from which I instinctively recoil in
horror. (I'd rather rewrite the whole thing in C#, which I even might
consider a good occasion to finally learn a reasonable amount of C# -
although, sadly, JAVA's level of platform independence'd be lost in the
process .) Does anyone of you know another (less hackish) way to get more
mouse-path information in a JAVA2/Swing application?

Regards,
Christian


From: Boudewijn Dijkstra Date:   Sunday, March 18, 2007
Op Sat, 17 Mar 2007 07:08:31 +0100 schreef Christian Stapfer <nil@xxxxxxxxxxx>:
I have written a distributed presentation/whiteboarding application
(JAVA2/Swing) for online-tutoring. Currently I use a graphics tablet to
draw
and write on the whiteboard.
Now I'd like to switch from using a separate graphics tablet to
using the stylus of a Tablet PC. However, my JAVA application seems to
drop
a great many mouse drag events, which results in hardly legible
handwriting
(not so with native Tablet PC applications like Windows Journal).
http://www.freesoft.org/software/tablet-JAVA/ suggests patching the JAVA
runtime to solve this problem - an idea from which I instinctively
recoil in
horror. (I'd rather rewrite the whole thing in C#, which I even might
consider a good occasion to finally learn a reasonable amount of C# -
although, sadly, JAVA's level of platform independence'd be lost in
the
process.) Does anyone of you know another (less hackish) way to get more
mouse-path information in a JAVA2/Swing application?



java.awt.Mouse Info.getPointerInfo().getLocation()--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/


From: Christian Stapfer Date:   Sunday, March 18, 2007
wrote in message

Op Sat, 17 Mar 2007 07:08:31 +0100 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:
I've written a distributed presentation/whiteboarding application
(JAVA2/Swing) for online-tutoring. Currently I use a graphics tablet to
draw
and write on the whiteboard.
Now I'd like to switch from using a separate graphics tablet to
using the stylus of a Tablet PC. However, my JAVA application seems to
drop
a great many mouse drag events, which results in hardly legible
handwriting
(not so with native Tablet PC applications like Windows Journal).

http://www.freesoft.org/software/tablet-JAVA/ suggests patching the JAVA
runtime to solve this problem - an idea from which I instinctively
recoil in
horror. (I'd rather rewrite the whole thing in C#, which I even might
consider a good occasion to finally learn a reasonable amount of C# -
although, sadly, JAVA's level of platform independence'd be lost in
the
process.) Does anyone of you know another (less hackish) way to get more
mouse-path information in a JAVA2/Swing application?
JAVA.awt.MouseInfo.getPointerInfo().getLocation()



Thank you very much for your reply. - I'm not sure whether
this helps to solve my problem, however.
There are actually two problems involved:

1. How to get high-resolution mouse-drag events
2. How to get high-resolution stylus positioning information

As I understand the situation, neither of these two problems
is really solvable with JAVA.awt.MouseInfo.getPointerInfo().getLocation()
in itself: the resolution isn't as high as it should be on
a tablet PC (the resolution of the digitizer isn't the same
- or at the very least need not be the same - as the resolution
of the screen : but JAVA.awt.MouseInfo.getPointerInfo().getLocation()
is). And continuous polling of the mouse position information
is complete ly out of the question: I need suitable events.

Actually I'm now slowly drifting in the direction of reimplementing
the whole program in C#, since being able to produce high-quality
handwriting during online-tutoring sessions with a tablet PC'd
be great.

Regards,
Christian


From: Chris Uppal Date:   Sunday, March 18, 2007
wrote in message:

I have written a distributed presentation/whiteboarding application
(JAVA2/Swing) for online-tutoring. Currently I use a graphics tablet to
draw and write on the whiteboard.
Now I'd like to switch from using a separate graphics tablet to
using the stylus of a Tablet PC. However, my JAVA application seems to
drop a great many mouse drag events, which results in hardly legible
handwriting (not so with native Tablet PC applications like Windows
Journal).
http://www.freesoft.org/software/tablet-JAVA/ suggests patching the JAVA
runtime to solve this problem [...]



A couple of thoughts.

If the referenced article is correct then the system is only coalescing mouse
events that you have not consumed -- which means there should only be a problem
if you aren't keeping up with mouse movements. In such a case, you've a
problem /anyway/. The normal system behaviour attempts to compensate for that,
but if the strategy it uses -- chucking stuff away instead of buffering it
up -- is unsuitable (which sounds likely for any kind of mouse drawing), then
the obvious solution is to do the buffering yourself, instead of putting the
slow processing inline with each event as it happens.

Another thought is that the tablet's JAVA implementation may have the AWT
method Component.coalesceEvents() available for override in your custom
Component. I've never tried it myself, but it looks as if you can override
that to control what events are coalesced.

-- chris


From: Tom Hawtin Date:   Sunday, March 18, 2007
wrote in message:
Another thought is that the tablet's JAVA implementation may have the AWT
method Component.coalesceEvents() available for override in your custom
Component. I've never tried it myself, but it looks as if you can override
that to control what events are coalesced.



Looking at the 1.6 EventQueue source (which is quite different from
1.5), you might need to use coalesceEvents as if it were your event
listener. Also note, rather unusually coalesceEvents isn't necessarily
invoked in the EDT.

Tom Hawtin


From: Christian Stapfer Date:   Monday, March 19, 2007
wrote in message

wrote in message:

Another thought is that the tablet's JAVA implementation may have the AWT
method Component.coalesceEvents() available for override in your custom
Component. I've never tried it myself, but it looks as if you can
override
that to control what events are coalesced.
Looking at the 1.6 EventQueue source (which is quite different from 1.5),
you might need to use coalesceEvents as if it were your event listener.
Also note, rather unusually coalesceEvents isn't necessarily invoked in
the EDT.
Tom Hawtin



Thank you both for your replies: I'll look into this.
As to my application possibly not being able to keep
up with mouse movements: although my application has
hardly anything other to do than to process those mouse
movements (i.e. storing them but also drawing a small
line segment connecting the last point with the current
point of the stroke being drawn), this seems quite
possible to me.
If I am not mistaken, the C# low-level Ink handling
system actually takes in an entire stroke before
handing the complete stroke to the application...
Also I vaguely remember having read a comment
stating that in order to have really high-quality
digitizer data for a stroke one needs to handle
the incoming digitizer data with a "real-time"
priority thread. - But maybe there is a medium-quality
way, instead of just a low- or a high-quality
way of capturing an ink stroke? - And medium-quality
just might be good enough for me, and my pupils...

Regards, and thanks again for your replies,
Christian


From: Boudewijn Dijkstra Date:   Wednesday, March 28, 2007
Op Mon, 19 Mar 2007 07:10:40 +0100 schreef Christian Stapfer <nil@xxxxxxxxxxx>:
As to my application possibly not being able to keep
up with mouse movements: although my application has
hardly anything other to do than to process those mouse
movements (i.e. storing them but also drawing a small
line segment connecting the last point with the current
point of the stroke being drawn), this seems quite
possible to me.



Nobody should paint in an event dispatch thread. Just store it and issue
a repaint.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/


From: Christian Stapfer Date:   Thursday, March 29, 2007
wrote in message

Op Mon, 19 Mar 2007 07:10:40 +0100 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:
As to my application possibly not being able to keep
up with mouse movements: although my application has
hardly anything other to do than to process those mouse
movements (i.e. storing them but also drawing a small
line segment connecting the last point with the current
point of the stroke being drawn), this seems quite
possible to me.
Nobody should paint in an event dispatch thread.
Just store it and issue a repaint.



I can understand your position, kind of. However,
the line drawing has to follow the dragging of
the mouse *immediately*: because, for the user,
it represents the movement of the pen.

How, for example,'d I handle rubberbanding,
if I were to follow your precept ("do not ever
draw anything in an event handler")? As compared
to rubberbanding of a large rectangle, I have
to draw a really only very tiny line segment when
incrementally drawing the pen-path from within
an event handler...

Regards,
Christian

P.S: No amount of clever coding seems to help
compensate for the fact that mouse-coordinates
are coarser than pen-coordinates on a Tablet PC
(because they are screen coordinates rather
than pen-digitizer coordinates) .


From: Boudewijn Dijkstra Date:   Monday, April 02, 2007
Op Thu, 29 Mar 2007 07:36:02 +0200 schreef Christian Stapfer <nil@xxxxxxxxxxx>:
Op Mon, 19 Mar 2007 07:10:40 +0100 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:
As to my application possibly not being able to keep
up with mouse movements: although my application has
hardly anything other to do than to process those mouse
movements (i.e. storing them but also drawing a small
line segment connecting the last point with the current
point of the stroke being drawn), this seems quite
possible to me.

Nobody should paint in an event dispatch thread.
Just store it and issue a repaint.
I can understand your position, kind of. However,
the line drawing has to follow the dragging of
the mouse *immediately*: because, for the user,
it represents the movement of the pen.



Drawing involves at least an order of magnitude more work than registering
and storing a mouse event. It doesn't matter much if drawing is
interrupted shortly when an event comes in. Note that "immediately" is
for the user something different than to the machine.

How, for example,'d I handle rubberbanding,
if I were to follow your precept ("do not ever
draw anything in an event handler")?



What is the problem with rubberbanding?

As compared
to rubberbanding of a large rectangle, I have
to draw a really only very tiny line segment when
incrementally drawing the pen-path from within
an event handler...
Regards,
Christian
P.S: No amount of clever coding seems to help
compensate for the fact that mouse-coordinates
are coarser than pen-coordinates on a Tablet PC
(because they are screen coordinates rather
than pen-digitizer coordinates) .



Does that include Newtonian physics calculations on speed, drag and
momentum? If you don't paint on the event dispatch thread, you can
collect more useful timing information from the events.--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/


From: Christian Stapfer Date:   Tuesday, April 03, 2007
wrote in message

Op Thu, 29 Mar 2007 07:36:02 +0200 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:
Op Mon, 19 Mar 2007 07:10:40 +0100 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:
As to my application possibly not being able to keep
up with mouse movements: although my application has
hardly anything other to do than to process those mouse
movements (i.e. storing them but also drawing a small
line segment connecting the last point with the current
point of the stroke being drawn), this seems quite
possible to me.
Nobody should paint in an event dispatch thread.
Just store it and issue a repaint.

I can understand your position, kind of. However,
the line drawing has to follow the dragging of
the mouse *immediately*: because, for the user,
it represents the movement of the pen.
Drawing involves at least an order of magnitude more work than registering
and storing a mouse event. It doesn't matter much if drawing is
interrupted shortly when an event comes in. Note that "immediately" is
for the user something different than to the machine.
How, for example,'d I handle rubberbanding,
if I were to follow your precept ("do not ever
draw anything in an event handler")?
What is the problem with rubberbanding?



Well, maybe I am just not being professional. I took
the basic idea of how to implement rubberbanding from
the book "Graphic JAVA: Mastering the JFC" by David
M. Geary (published by Sun Microsystems).
Geary does the drawing of rubberband lines from ...
... well, from within mouse event handlers.
If I were to queue the handling of every tiny piece
of a freehand line being drawn for later processing,
I might end up queuing about two hundred line draws
in the process. The whole queuing process'd require
more work than the drawing of those many, usually
very small line segments.

As compared
to rubberbanding of a large rectangle, I have
to draw a really only very tiny line segment when
incrementally drawing the pen-path from within
an event handler...

Regards,
Christian

P.S: No amount of clever coding seems to help
compensate for the fact that mouse-coordinates
are coarser than pen-coordinates on a Tablet PC
(because they are screen coordinates rather
than pen-digitizer coordinates) .
Does that include Newtonian physics calculations on speed, drag and
momentum? If you don't paint on the event dispatch thread, you can
collect more useful timing information from the events.



Unfortunately, I do not get your point. I do not necessarily
need more timining information: what I need is sufficient
resolution of pen coordinates. On a tablet PC, the pen
has higher resolution than the screen. Why did they provide
higher resolution pen coordinates, if, according to you,
higher resolution can be had some other way than by suppording
it with appropriate hardware ?
But maybe you've a very clever idea of a workaround
for the limitation to mouse (screen) coordinates. As for me:
I'm not a great friend of cleverness, and avoid it whenever
I can. Getting good pen stroke information is very easy
from within a C# application. Not so from JAVA2, and that
was my problem. For that reason I am already trying to port
my application to C#, and have made substantial progress in
that direction.

Regards,
Christian


From: Boudewijn Dijkstra Date:   Tuesday, April 03, 2007
Op Tue, 03 Apr 2007 06:43:17 +0200 schreef Christian Stapfer <nil@xxxxxxxxxxx>:
Op Thu, 29 Mar 2007 07:36:02 +0200 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:
Op Mon, 19 Mar 2007 07:10:40 +0100 schreef Christian Stapfer
<nil@xxxxxxxxxxx>:



Nobody should paint in an event dispatch thread.
Just store it and issue a repaint.
I can understand your position, kind of. However,
the line drawing has to follow the dragging of
the mouse *immediately*: because, for the user,
it represents the movement of the pen.

Drawing involves at least an order of magnitude more work than
registering and storing a mouse event. It doesn't matter much if
drawing is interrupted shortly when an event comes in. Note that
"immediately" is for the user something different than to the machine.

How, for example,'d I handle rubberbanding,
if I were to follow your precept ("do not ever
draw anything in an event handler")?

What is the problem with rubberbanding?
Well, maybe I am just not being professional. I took
the basic idea of how to implement rubberbanding from
the book "Graphic JAVA: Mastering the JFC" by David
M. Geary (published by Sun Microsystems).
Geary does the drawing of rubberband lines from ...
... well, from within mouse event handlers.



Examples often take shortcuts in order to not confuse the layman.

If I were to queue the handling of every tiny piece
of a freehand line being drawn for later processing,
I might end up queuing about two hundred line draws
in the process. The whole queuing process'd require
more work than the drawing of those many, usually
very small line segments.



Do not underestimate the time a drawing operation takes, and the time it
takes until the next screen refresh.

P.S: No amount of clever coding seems to help
compensate for the fact that mouse-coordinates
are coarser than pen-coordinates on a Tablet PC
(because they are screen coordinates rather
than pen-digitizer coordinates) .

Does that include Newtonian physics calculations on speed, drag and
momentum? If you don't paint on the event dispatch thread, you can
collect more useful timing information from the events.
Unfortunately, I do not get your point. I do not necessarily
need more timining information: what I need is sufficient
resolution of pen coordinates. On a tablet PC, the pen
has higher resolution than the screen. Why did they provide
higher resolution pen coordinates, if, according to you,
higher resolution can be had some other way than by suppording
it with appropriate hardware?



Clearly, fancy physics calculations are a bit over-the-top and of course
the hardware provides a relatively high resolution. You can notice the
relatively low resolution of very cheap optical mice, which will once in a
while start to 'walk' towards one end of the screen.

But maybe you've a very clever idea of a workaround
for the limitation to mouse (screen) coordinates. As for me:
I'm not a great friend of cleverness, and avoid it whenever
I can. Getting good pen stroke information is very easy
from within a C# application. Not so from JAVA2, and that
was my problem. For that reason I am already trying to port
my application to C#, and have made substantial progress in
that direction.



For one, you could consider using some JNI functionality to pump custom
mouse events into the system. You'll have to manually perform the
coordinate conversions, though.--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/



Next Message: Connect to JAVA application from JAVA login form


Blogs related to How do I get smooth handwriting on a Tablet PC using JAVA2/Swing?

College Girls On Spring Break Seeking Fun Sex Partners
+com.com www.colorado snowboarding.com www.creative muvo 256mb sport.com www.switchfoot nothing is sound.com www.before dont get give i if there up.com www.martha stewart butternut squash soup.com www.top rail for chain link fence.com ...

The Business of WiMAX Deepak Pareek Resource4Business, India The ...
Tablet PC A personal computer that allows a user to take notes using natural handwriting on a stylus- or digital pen-sensitive touch screen instead of requiring the use of a keyboard. The tablet PC is similar in size and thickness to a ...

Pda Obd Software
... window are easy large fonts in the The main feature of superdoc text using superfonts is the ability to display http://www.ezpdastore.com/pocket-pc-dvd.html Of 4 you have a choice Setting in the preferences in order to do this, ...

Ipaq Utils
http://www.ezpdastore.com/free-software-for-pocket-pc.html With a price thats nice this reader has features galore To say nothing of those of us on a tight budget the latest version, 5mo3, contains many bug fixes that make this app an ...

Lease Hp Ipaq
... and down buttons Files using the iambic reader desktop tools it can do this by converting said Main window and marquee window 3 text size options for the as for font options, you have http://www.ezpdastore.com/quicken-pocket-pc.html ...

Basketballs
No Money Down Investing Medical Facilities In Stillwater Mn Minnesota Microsoft Office 2000 Upgrade Stage Portable Lighting System Tablet Pc Pentium M Stage Lighting Drama Saint Petersburg Florida Birth Injury Lawyer Cartoon Flash Media ...


Programming | Sports | Autos

copyright 2006
Valid XHTML 1.0 Transitional