[GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
Glynn Clements
glynn at gclements.plus.com
Tue Nov 26 11:23:52 PST 2013
Markus Neteler wrote:
> Would also a quite different approach be possible? I have somehow the
> idea that generating tmp files on disk is slower than writing into the
> graphics card's memory :-)
The fastest solution is what you get if you use the cairo driver and
$GRASS_PNGFILE has a ".xid" suffix. The driver creates an X11 or
X11+XRender surface (which is in video memory). Rendering operations
use X11 (XRender if available, core protocol otherwise) which will use
the video hardware where possible.
The disadvantages are that it only works with X11, and some GUI
toolkits (including wxPython) are unable to make use of the resulting
image (other than by pulling the data back into client memory so that
it can be used as a source for their naive "image" class). Even if a
particul toolkit has the ability to make use of an image already in
video memory, the mechanism will be non-portable and typically either
poorly documented or undocumented.
Any other method will end up rendering the image in software to client
memory. It may also write the image to a file, but actual disk I/O is
performed by the kernel in the background. The expensive part is if
the driver performs expensive processing (e.g. compression) on the
data in the process.
The biggest obstacle is probably the use of wxWidgets, as its
rendering model is stuck in the early 1990s (the API is essentially
Windows 3.1 GDI with some minor modifications).
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list