[stem-dev] Antw: Some performance enhancement ideas for Map View

["Thoens Christian" <Christian.Thoens@xxxxxxxxxxx>]

Thanks for the suggestions Matt,

I already implemented (2.) in the GraphMapView. The Polygon Border
Image in regenerated every time the map is panned or zoomed. There
panning and zooming are still very expensive when an alpha value for the
borders is used. What do you think of the following idea? We could stop
using alpha every time the map is panned or zoomed and start using it
again when there has not been a panning or zooming for maybe 2 seconds.

Regards,
Chris

>>> Matthew Davis <mattadav@xxxxxxxxxx> 4/26/2012 10:48 pm >>>
Hi Chris,

Per our discussion on the STEM call today, here are a few ideas for 
further performance improvements on the Map View / Graph Map View.  I
have 
done a rough implementation of each just to gauge performance / 
feasibility, but they're not fully implemented.

1.  Move Drawing off UI Thread

A SWT Graphics Context (GC) can draw to an image in regular threads. 
Currently we do all the drawing on the UI thread, which 1) has to wait

until it's available to draw and 2) locks the UI while drawing, which
can 
make the UI seem unresponsive for large periods during simulations.

In my example, created a new Eclipse Job that executes the draw routine

and creates two images:  the filled polygons and borders (See #2). 
This 
job is scheduled by the simulationChanged(...) listener and runs 
asynchronously.  When it finishes, the two images are stored in
memory.

The paintControl() method, which draws the UI and runs on the UI
thread, 
simply draws the two images directly onto the Control.  The total cost
of 
a repaint is ~30ms - that is the time the UI is bound, vs. 300-2000 ms

currently.

Upside:  The combined image is cached, allowing less drawing directly
onto 
the UI, thus a faster and more responsive UI.  Refresh job is easier 
managed using Jobs framework (vs. asyncExec(...))
Downside:  The image is further asynchronous from the simulation; 
complicates panning and zooming.


2.  Cache the Polygon Borders Image

50% of the draw time for each Map refresh is drawing the polygon
borders. 
For a fixed map perspective (pan/zoom settings), the borders and thus
the 
image do not change from step to step, and can be drawn onto a cached 
image and reused. Also, you can apply the alpha (which we like)
uniformly 
at the bitmap level, vs having to calculate the alpha redundantly. The

cost of drawing the image is about 10ms vs. 400-700ms for rendering the

polygons.  When the map perspective changes, the polygons must be
redrawn. 
(* panning with no clipping is an exception)

Upside:  2x average speed-up; can retain border transparency at trivial

cost
Downside:  Increased memory usage; complicates panning and zooming


3.  Cache the Filled Polygons Image; define a value differential to
force 
update

This is kind of tricky, but it also useful.  Step-by-step, the vast 
majority of the nodes do not change in value appreciably (that is,
enough 
to trigger a change in relative value index in the map view).  By 
extension, for a fixed map perspective, most of the filled polygons do
not 
need to be refreshed for each redraw (in fact, most are probably
white). 

With your alpha pre-calculations, we can now overdraw cached images, 
retaining the "look" of alpha, but without worrying about additive 
blending of the previous pixel values and we don't have to pay the 2x
cost 
to redraw the background then draw the fill.

The idea is to set a (configurable) differential in relative value
before 
the polygon is redrawn.  On our index of 0-255, this could be something

like a change of 5% in relative value (10-15 indexed values of alpha) 
would be required before an individual region / polygon is redrawn. 
With 
map perspective changes, the whole thing must be redrawn. (* panning
with 
no clipping is an exception)

Upside:  Up to another 2x speed-up
Downside:  Increased memory usage; complicates panning and zooming;
lots 
of edge cases to take care of; lose accuracy & resolution in the map.

4.  Make sure clipping is working


====

A quick and dirty implementation of 1-3 in the current MapCanvas shows
a 
decrease in average draw time from 700ms to 80ms per redraw (range of
10ms 
to 1200ms) for the USAMexico scenario with a 5% relative value
difference 
before redraw.  Now, there will be steps when it's going to be much 
higher, but for the most part, it's much faster.

Now, one issue is this gets us further and further away from having a 
"correct" map view --- but that leads to the last part.  With an
average 
update of 80ms, a simulation-synchronous map view is no longer that big
of 
a burden (especially if it's not binding the UI).  And the redraw 
differential would be configurable, so you can get a completely
accurate, 
synchronous map with two configuration switches.  A synchronous draw
will 
also be faster, as it's not going to be competing with the simulation
for 
CPU time.

The biggest downside to all this is panning and zooming will have to be

addressed, as all of these options make it even less interactive than
it 
is now (which isn't saying much ...).

I'm interested in hearing everyone's thoughts.  I'm also happy to help

implement any of these changes.


-Matt

_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/stem-dev