David,
Thanks for posting that - I've heard from another user that ran into
the same issue and found that update worked for him as well.
Cheers,
Don
On Tue, Jun 16, 2009 at 3:08 PM, David Ward<synriga_at_yahoo.com> wrote:
> Don,
>
> Just a heads up.
>
> We ran it to an XOR rendering issue with later rendering for project running
> on Windows with DirectX/Direct3D. We would occasionally observe very
> sluggish performance on Windows.
>
> Java 6 Update 14 has a bug fix
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6635462) that disables
> the XOR rendering if detected. The bug report has work arounds for earlier
> Java 6 updates.
>
> Cheers,
> David
>
>
>
>
> On Jun 16, 2009, at 11:49 AM, Don Dietrick wrote:
>
>> Ahh, yes, the ZoomMouseMode, I forgot about that one, I don't use it that
>> much. The internal workings of that mouse mode should be updated, I'm not
>> sure at what point that will happen.
>>
>> So it looks like the real sin is the XOR drawing going on with the mouse
>> modes, and now that I think about it, the drawing tool, by painting into the
>> Graphics object. It'll be interesting to test and see if the XOR method is
>> still needed, it was a performance necessity 10 years ago but might be
>> averted now. I'll take a look at it at some point after 5.0 is released.
>>
>> I'm not seeing any weird behavior with the OverviewMapHandler, so if you
>> find something please let me know.
>>
>> Thanks for the feedback,
>>
>> Don
>>
>> On Jun 15, 2009, at 5:53 PM, Fabrice Bouye wrote:
>>
>>> Hi,
>>> It works good and as for most other Swing component that has no JavaFX
>>> wrapper (ie: JButton has a JavaFX wrapper named
>>> javafx.ext.swing.SwingButton), it is just a matter of doing something
>>> similar to (from memory):
>>>
>>> def mapBean = new BufferedLayerMapBean();
>>> // Setup map and everything as usual.
>>> [...]
>>> def mapNode = SwingComponent.wrap(mapBean);
>>> def scene = Scene {
>>> content: mapNode;
>>> }
>>> Stage {
>>> title: "OpenMap test"
>>> override var width = 800 on replace {
>>> mapNode.width = scene.width;
>>> }
>>> override var height = 600 on replace {
>>> mapNode.height = scene.height;
>>> }
>>> content: scene;
>>> }
>>>
>>> This should work on JavaFX 1.0, 1.1/1.1.1 or 1.2 (note: unlike Java, so
>>> far JavaFX binaries are not compatible between the different releases so the
>>> program would need to be recompiled when changing versions). And the map
>>> responds ok without any trouble to mouse movements such as clicks or drags.
>>>
>>> What is missing is the overlay for each mouse modes, that is the visual
>>> feedback of the mouse mode:
>>> - in NavMouseMoude, no drag rectangle or point except sometimes for the
>>> very first click.
>>> - in DistanceMouseMode, the circle and radius that shows the distance
>>> does not appear unless you resize the frame.
>>> - in ZoomMouseMode, partial redrawing of the map on screen (most of the
>>> time not the entire bean surface), may disrupts other nodes rendering.
>>> - in PanMouseMode, partial redrawing of the map on screen (most of the
>>> time not the entire bean surface), may disrupts other nodes rendering.
>>> Etc.
>>>
>>> This is mainly because the mouse modes use direct calls to getGraphics(),
>>> something that is not recommended (see books such as Filthy Rich Clients
>>> p46, 47, 48 -Romain and Chet were part of the Swing Team at that time-, past
>>> JavaOne BOFs, various blogs from members of the Swing Team). JavaFX is more
>>> conservative here and expects Swing component to follow best practices so
>>> they render Ok. It's not critical, and I was just wondering if this would be
>>> fixed later on since version 5.0 has been announced. At some point I may end
>>> up trying to implement the various mouse modes in JavaFX with node rendering
>>> instead of Java2D rendering in replacement if this is not feasible.
>>>
>>> After wandering through the sources to find out if getGraphics() was
>>> indeed is used, I've discovered that Thread.sleep() in the EDT and using a
>>> new Thread to set the projections out of EDT was used as well at least in
>>> ZoomMouseMode, two things that are not good either. Most recent Swing best
>>> practices involve using either a Swing Timer, not a java.util.Timer, (job
>>> occurs entirely in EDT with this one) or a SwingWorker (allows safe
>>> interaction between job executed in external Thread and the EDT) both as
>>> Thread replacements or SwingUtilities.invokeLater() or
>>> SwingUtilities.invokeAndWait() (for interaction with the external Thread and
>>> the EDT ; note: SwingUtilities.invokeAndWait() may be a source of trouble
>>> too).
>>>
>>> I am making API calls to change the bean projection and it work good as
>>> far as the map bean and it layers are concerned (they redraw and show up
>>> properly, etc.).
>>> Apart from the map beans and layers, the only other OpenMap component I
>>> am using so far is the OverviewMapHandler (integration in the JavaFX UI is
>>> done in a similar fashion through SwingComponent.wrap() too) but it seems it
>>> get lost* when I change the map's projection (not related to JavaFX as it
>>> does that in a pure Java test too), I am still investigating about this one.
>>>
>>> *That is once I change the projection's type (i.e.: from Mercator to
>>> LLXY, or any other), its status layer does not follow the projection
>>> anymore, though the handler itself still seems to react Ok to mouse actions.
>>> If I just pan and zoom without changing the projection type, the status
>>> layer works Ok and shows the proper area.
>>>
>>> ----
>>> Fabrice Bouyé (http://fabricebouye.cv.fm/)
>>> Fisheries IT Specialist
>>> Tel: +687 26 20 00 (Ext 411)
>>> Oceanic Fisheries, Pacific Community
>>> http://www.spc.int/
>>>
>>>
>>>> -----Original Message-----
>>>> From: Don Dietrick [mailto:dietrick_at_bbn.com]
>>>> Sent: Tuesday, June 16, 2009 2:43 AM
>>>> To: Fabrice Bouye
>>>> Cc: openmap-users_at_bbn.com
>>>> Subject: Re: [OpenMap Users] OpenMap on JavaFX, getGraphics(),
>>>> Thread.sleep() in EDT and external Thread
>>>>
>>>> Hi Fabrice,
>>>>
>>>> Thanks for the initial feedback on getting OpenMap wrapped in JavaFX,
>>>> this is the first instance I've heard of someone trying this. I'm
>>>> interested in hearing how this works out.
>>>>
>>>> I'm also trying to understand your characterization of the mouse modes
>>>> and how they contribute to making the map unresponsive. The mouse modes
>>>> don't do anything to the EDT in particular, they act much like the
>>>> navigation panel buttons and any other swing widget controlling the
>>>> map.
>>>> The MapBean has a support object, containing a thread, that is
>>>> responsible for telling the layers the map projection has changed, and
>>>> the MapBean generally controls when that thread is woken up and tasked.
>>>> Are you using any of the other Swing widgets, or making API calls, to
>>>> change the MapBean's projection? Are they functioning, or does the
>>>> MapBean only render the initial projection?
>>>>
>>>> Cheers,
>>>>
>>>> - Don
>>>>
>>>> Fabrice Bouye wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've been developing a GIS GUI for a while for one of our internal
>>>>> projects using the OpenMap bean as our GIS component. While the
>>>>> project was initially in pure Java Swing, the project's GUI has now
>>>>> switched to JavaFX since it's been released last December (recently
>>>>> switched to JavaFX 1.2).
>>>>>
>>>>> As expected the map bean can be simply wrapped using the
>>>>> javafx.ext.swing.SwingComponent class and displayed as any other kind
>>>>> of Node in a Scene and it works good.
>>>>>
>>>>> But, there are still some issues in the way OpenMap's various mouse
>>>>> mode are done : when rendering their own overlay, they use direct
>>>>> access to the map bean getGraphics() method, they use Thread.sleep()
>>>>> in the EDT and they launch an external Thread to change the
>>>>
>>>> projection
>>>>>
>>>>> (see ZoomMouseMove, PanMouseMode and NavMouseMode source code for
>>>>> example), things which is usually not considered to be Swing good
>>>>> programming practices as they do get along with Swing's passive
>>>>> rendering architecture and interact poorly with the EDT itself.
>>>>>
>>>>> While the overlays show up Ok in Java when dragging the mouse around,
>>>>> they simply do not show up* at all when the bean is integrated in a
>>>>> JavaFX Scene.
>>>>>
>>>>> *to be true, sometimes it shows up on the initial click and never
>>>>> again after.
>>>>>
>>>>> I was wondering if there was any plan to change that for the next
>>>>> OpenMap major version?
>>>>>
>>>>> (i.e.: replace direct active rendering by some passive rendering
>>>>> architecture, replace Thread by SwingTimer or
>>>>> SwingUtilities.invokeLater(), access to component properties only on
>>>>> EDT, etc.)
>>>>>
>>>>> ----
>>>>> Fabrice Bouyé (http://fabricebouye.cv.fm/)
>>>>> Fisheries IT Specialist
>>>>> Tel: +687 26 20 00 (Ext 411)
>>>>> Oceanic Fisheries, Pacific Community
>>>>> http://www.spc.int/
>>>>>
>>>>
>>>
>>> --
>>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>>> with the following text in the BODY of the message "unsubscribe
>>> openmap-users"]
>>
>> --
>> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
>> with the following text in the BODY of the message "unsubscribe
>> openmap-users"]
>
>
> --
> [To unsubscribe to this list send an email to "majdart_at_bbn.com"
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]
>
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Tue Jun 16 2009 - 15:31:32 EDT