xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Drag event, mouse events beyound elements, transformation of coordinates.
Date Tue, 19 Oct 2004 11:54:44 GMT
Dmitrij Sakara wrote:

> Thank you (Thomas DeWeese,  Tonny Kohar) for answers on my previous 
> questions. Now I have a next portion. :)
> I need to handle the drag event and mouse clicks beyond of elements. As 
> far I understand there is two possible solutions:
> 1)       To handle AWT drag event and perform transformation between 
> screen and user coordinates. In this case, how can I do this 
> transformation with considering viewBox too?

    You need to use something like getScreenCTM.

> 2)       Create invisible rectangle over all screen and handle DOM 
> MouseMove event over it. In this case, I should protect this rectangle 
> against pan in order to insure his positioning strictly over the whole 
> screen. I achieve this by using JavaScript for standalone SVG documents 
> and Adobe SVG Viewer. Should I use the same approach in case of Batik? 
> What is the performance of this solution?

    This will work fine, and is what I normally use.  I usually don't
bother to protect against pan an instead just ensure that the rect
is larger than any reasonable pan amount (it doesn't cost you anything
extra to have an extremely large rectangle).

    You should use visibility="hidden" to make the rectangle invisible
(this is slightly better than fill="none" and a million times better
than opacity="0" - actually I think we trap that case now but still
visibility is the way to go!). You will then need to set
pointer-events="fill" to continue to receive events.

> So, which solution is better from standpoint of performance?

    I suppose #1 would be ever so slightly faster (if done 100%
correct) however in this context I doubt if the difference would
ever show up.  Since #2 is way less code, and it only depends on
standard interfaces it is without a doubt the way I would go.

To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message