[GRASS-dev] Re: [GRASS5] Improvements to gis.m map canvas

[Glynn Clements]

Michael Barton wrote:

> > Okay, that makes sense from an efficiency perspective. Drawing
> > probably won't be noticably affected, but composition and reading the
> > image into Tk should be faster.
> 
> It would  be nice if this could be speeded up.

Which part?

I don't think that there's much that can be done about reading the
image into Tk ("image create photo ...").

g.pnmcomp should be relatively fast compared to the actual rendering,
but if you've managed to minimise rendering (does it cache previous
renders yet?), g.pnmcomp will probably be the bottleneck.

One possibility would be to cache intermediate stages of compositing,
so that the whole process doesn't need to be re-done. E.g. if you have
A+B+C+D+E and you are only changing C, caching A+B and D+E means that
you only need to do two passes rather than four.

Although, that would require knowing ahead of time how to break up the
process. Also, for the layers above the one being changed, g.pnmcomp
would have to write out the alpha channel. That would be easy enough
to do, if there was any need.

Another way to make g.pnmcomp faster would be to use MMX/SSE/3DNow
extensions (which were designed for exactly this kind of task). I'd
use gcc's SIMD extensions rather than assembly language.

For a C/C++ GUI, you would just read the individual layers and perform
the compositing using the OS' graphics API where possible. Core X11
doesn't support blending, although the RENDER extension does. OpenGL
is a possibility, but the texture size limit and the requirement that
texture sizes are a power-of-two complicate matters.

-- 
Glynn Clements <glynn at gclements.plus.com>