|
|
Gestalt Items |
Copyright © 2008, 2009 Arndt Roger Schneider
A bitmapped computer graphic aka »image« is always encoded with a certain resolution. Images can be shrunken and zoomed to adapt them to the monitor resolution. An image deprecates in quality if it is shrunken. Otherwise, if an image is zoomed, then the additional resolution is wasted. Tcl/Tk does not have shrink or zoom capabilities of its own for images.
In the realm of Gstripes shrinking and zooming could be delegated to »pimage« from TkPath. But this cannot be seen as a solution! The dimensions, reported by hijacked controls, would be wrong, too; because these controls only work with unscaled images.
Example 7.1. Pimage shrink and zoom
image create photo myimage ...
set image_width [image width myimage]
set image_height [image height myimage]
set pimage_width \
[expr {[tk scaling] * $image_width}]
set pimage_height \
[expr {[tk scaling] * $image_height}]
canvas .canvas
.canvas create pimage \
100 100 \
-image myimage \
-width $pimage_width \
-height $pimage_height
Another, and more suitable solution, is to render images in various resolutions. 72ppi for low resolution and AQUA®. And images with higher resolution for high resolution monitors. »tk scaling« can be used to determine what image set is required for the current monitor. Example 7.1, “Pimage shrink and zoom” deploys tk scaling in order to zoom or shrink an image as needed. In this scenario, the question is: what image object is to be created.
I was never very fond of loading masses of application resources, depending on some settings. In the case of Tcl/Tk and images: I usually prefer »base64« encoded images embedded in the source code. This way images are ordinary code themselves. This works fine for »Gif®« images, but not necessarily for other image types.
# Default Image Directory:
set image_directory icons72
if { 1.49 < [tk scaling] } {
set image_directory icons100
}
if { 2.0 < [tk scaling] } {
set image_directory icons144
}
# ... then load images from
# the specified directory.
The »package« mechanism is better suited to select image directories. The Example 7.2, “tk scaling ” is only a demonstration.
Another, quit similar technique to Example 7.1, “Pimage shrink and zoom” is to apply a transformation on an image when displayed. Transformations are available with TkZinc 3.3.6 (Zoolbar) and TkPath (Goolbar).
Example 7.3. TkPath Transformation
image create photo myimage ...
canvas .canvas
.canvas create pimage 100 100 \
-image myimage \
-tags myimage \
-matrix [tkpath::transform scale \
[tk scaling]]
# With TkPath Version 0.3:
# tkp::transform scale [tk scaling]
The pimage transformation, as shown in Example 7.3, “TkPath Transformation” is not really usable with TkPath 0.2.4! The transformation »matrix« is evenly applied to every point of the image and thus the position is altered, too. In this case: the coordinates of the pimage are modified through »tk scaling«!
With TkPath 0.3, pimages can be encapsulated inside a »group« element, and the scale transformation applied on a pimage item. The described solution is technically identical to a vector.
Example 7.4. TkZinc 3.3.6 transformation
image create photo myimage ...
zinc .zinc
.zinc scale [tk scaling] [tk scaling] \
[.zinc add icon 1 \
-image myimage \
-position {100 100} \
-tags myimage] ;# 100 100
# Optional define where to zoom.
# Of course, it is better to use a
# transformation set, here!
The Zoolbar provides image zooming out-of-the-box. The »vectorSize« property gets used to determine the required image size. I recommended to use a resolution independent value for »vectorSize«! The default value is set to »24p« (24 points). 24p translates into 24 pixels for tk scaling set to 1.0.
There is another technical issue with images. The historic way to craft a Graphical User Interface was by drawing it into an off-screen bitmap and then to copy this image into the graphics card memory. Higher resolution reads larger images and are performance-wise very bad.
Technical solutions are under way: such as Quartz® 2D Extreme and XRender®.
Tcl/Tk is »hardware-accelerated« for 2D graphics –at least– under X Window System and thus is today still a fast. However the drawing performance scales directly with memory speed. This is usually an indicator for massive bitmap usage or over-reliance on local data-storage.
Local data-storage is a very bad thing for the presentation layer. Not only does it tend to slow down the graphics –by increased memory consumption–, but also the data must be gathered up-front. Object-Orientation in the presentation layer is often implemented by copying the data (model) into the presentation layer. Deprecating the Graphical User Interface’s performance and flexibility.