"Boudewijn Dijkstra" <usenet@[EMAIL PROTECTED]
> wrote in message
news:op.tp6a8kwg9s1m7x@[EMAIL PROTECTED]
> Op Thu, 29 Mar 2007 07:36:02 +0200 schreef Christian Stapfer
> <nil@[EMAIL PROTECTED]
>:
>> "Boudewijn Dijkstra" <usenet@[EMAIL PROTECTED]
> wrote in message
>> news:op.tpw3tuhu9s1m7x@[EMAIL PROTECTED]
>>> Op Mon, 19 Mar 2007 07:10:40 +0100 schreef Christian Stapfer
>>> <nil@[EMAIL PROTECTED]
>:
>>>> 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 does not 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, would I handle rubberbanding,
>> if I were to follow your precept ("don't 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 would 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 do not paint on the event dispatch thread, you can
> collect more useful timing information from the events.
Unfortunately, I don't get your point. I don't 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 sup****ding
it with appropriate hardware?
But maybe you have 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 ****t
my application to C#, and have made substantial progress in
that direction.
Regards,
Christian
|
