[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] the letter for UDIG developers and architects.
|
I'm just curious what timeline you had in mind for these improvements?
I going to be spending my time for the next month on bug fixes and
performance tweaks and won't have time to perform any changes like the
ones suggested here (other fixing the viewport refreshing).
Jesse
Vitali Diatchkov wrote:
Hello, UDIG architects and developers!
While working with "UDIG framework" (it is a really good framework for
client GIS solutions) and the time being I would like to share some issues
and probably solutions.
1)
From observation and testing the catalog is a persistent entity. But
problems appear while closing and opening UDIG. Especially when the remote
connection is not valid anymore (WMS servers, database connections) -
starting UDIG leads to "hanging" while it tries to restore these
connections. Or in database cases getting metadata (that is a first step as
I suppose) is a long-running process. Even WMS GetCapabilities request takes
time. But what if there were 10 WMS connections during previous UDIG session
in catalog?
Sure it is an obvious issue, does anybody has a solution, probably not
implemented but is supposed to be implemented to establish full lazy-loading
behavior for the Catalog? Let's have fully remote-independent
stubs/descriptors/whatever - just to have a label in catalog and the
opportunity to restore real connection when it is first-time accessed.
In my case of just one database connection persisted through catalog leads
to 30-40 seconds of restoring it during starting UDIG (just example of slow
db connection).
2)
Selection tool.
The behavior is simple and sufficient for most of cases for users: selection
tool just sets filter for the layer and somehow highlights selected
features.
Problem: for the developers using UDIG as a framework with custom extended
functionality more customizable behavior of selection tool is needed.
Writing own custom selection tool solves the problem but only half of them.
Try to explain.
The semantic of selection in GIS is the same as in other applications,
Photoshop, for example. If something is selected and I select another entity
- the old selection disappears (if it is not special case of modifying
current selection). There can be different selection tools with different
functionality, but it is necessary to easy integrate them into the platform
and behavior of all selection tools should be heterogeneous.
The example: in my project I developed multi-selection tool for defining
let's call "Area of Interest". The tool just selects polygonal geometries
making geometric predicates (union, cutting, etc) if needed forming "Area of
Interest".. (AOI is used with arbitrary purposes later).
I expect that if filter is defined by default selection tool and there is
that yellow graphic rendered on the map - it should be cleared and graphic
of AOI selection tool is rendererd - "substitution" behavior.
The same "substitution" policy can be used in other places for the
flexibility and extendibility of the platform. Now selection tool is
strongly integrated and there is no possibility to add custom functionality
with "selection" behavior without changing "net.refractions.*" code that is
bad approach from my point of view.
3) Rendering
Continuing to propagate "substitution" behavior of selection tools.
Selection on another layer kills selection on the previous. Why each layer
has the peer layer - SelectionLayer? If there are 10 layers - means there
are 20 rendering jobs and at least 9 of them renders nothing.
What if there is one special SelectionLayer and one SelectionRenderer for it
where all selection graphics is rendered.. Selection tools just send
commands somehow to render something custom on this layer..
This approach can be extended for adding any special graphics layers using
special extension point for example - not only for rendering selection masks
and graphics for selection tools.
Rendering can be organized in a same way as ViewportPainter draws graphics
above all maps - using commands.
SelectionLayer has a special Renderer that has the same architecture as
ViewportPainter
All selection tools send two kinds of commands to that renderer: 1) just to
start redrawing; 2) special drawing commands that have long life-cycle in a
same way as in ViewportPainter. The second type of commands has a
"substitution" behavior: each next command substitutes the old one.
This idea outlines what do I mean - "substitutional" behavior in similar
group of tools from other developers: such framework lets add new tools with
new functionality but visual behavior among all tools from this "semantic"
group in application remains the same.
4) Rendering optimization.
Lets call features rendered on the layer - long-running graphics and for
example bounding box when I drag mouse while selecting features -
"temporary graphics".
The second type is rendered using command approach in ViewportPainter, the
first one is rendered using Renderer API and cached by buffered images.
First impression from new editing tools - very good and thought-out
architecture but no optimization for rendering.
"temporary graphics" drawing commands are sent from commands with
business-logic. The last are executed in special thread by CommandManager..
So we have the following sequence: mouse has moved -> tool gets event and
sends command with business-logic into thread of CommandManager -> in this
thread CommandManager executes command -> somewhere during execution the
drawing command is sent to ViewportPainter or repaint() method is called..
Because of synchronization and thread stuff this repaint() call is sent with
delay - I see terrible slide-show of painting "temporary graphics" while
dragging vertex of the feature, for example, by mouse..
Great optimization that I used in developing custom tools for UDIG - when
the event comes from mouse in the beginning all commands responsible for the
"temporary painting" are sent to ViewportPainter and repaint() is called
directly from tool class, then business logic command is sent to
CommandManager thread to do something. repaint() method is asynchronous by
its nature- no problem to call it anywhere.. of course there can be complex
chains of operations to be performed by tools and commands but such
rendering optimization of "temporary graphics" is important and can be
widely applied.
Any comments, questions? I really would like to discuss and help to make
UDIG the best open source GIS platform in future:)
Vitali.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
