Op Tue, 03 Apr 2007 06:43:17 +0200 schreef Christian Stapfer <nil@[EMAIL PROTECTED]
>:
> "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]
>:
>>>> 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.
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 would require
> more work than the drawing of those many, usually
> very small line segments.
Don't 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 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?
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 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.
For one, you could consider using some JNI functionality to pump custom
mouse events into the system. You will have to manually perform the
coordinate conversions, though.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
|
