Graphics

Package iup implements Go bindings for IUP (https://www.tecgraf.puc-rio.br/iup/). IUP is a multi-platform toolkit for building graphical user interfaces. Currently available interface elements can be categorized as follows: IUP has 3 concepts that any user has to understand: Elements, Attributes and Callbacks. Elements are every kind of interface element present in the application. IUP contains several user interface elements. The library's main characteristic is the use of native elements. This means that the drawing and management of a button or text box is done by the native interface system, not by IUP. This makes the application's appearance more similar to other applications in that system. On the other hand, the application's appearance can vary from one system to another. Besides, some additional controls are drawn by IUP, and are independent from the native system. Dialogs are special elements that represent every window created by IUP. Any application that uses IUP will be composed by one or more dialogs. Every dialog can contains one or more controls inside. IUP controls are never positioned in a specific (x,y) coordinate inside the dialog. The positioning is always calculated dynamically from the abstract layout hierarchy. So get used to the Fill, Hbox and Vbox controls that allows you to position the controls in the dialog. Attributes are used to change or consult properties of elements. Each element has a set of attributes that affects its behavior or its appearance. Each attribute may work differently for each elements, but usually attributes with the same name work the same. Attribute names are always upper case. But attribute values like "YES", "NO", "TOP", are case insensitive, so "Yes", "no", "top", and other variations will work. IUP has only a few functions because it uses string attributes to access the properties of each control. So get used to SetAttribute and GetAttribute, because you are going to use them a lot. Attribute names are always upper case, lower case names will not work. But attribute values like "YES", "NO", "TOP", are case insensitive, so "Yes", "no", "top", and other variations will work. If not defined their value can be inherited from the parent container. Boolean attributes accept the values "1", "YES" or "ON" for true, and "0", "NO" or "OFF" for false. But they will return the value described in the documentation. You can also use SetInt with 1 for true and 0 for false. GetInt will return 1 for any of the true values, and 0 for any of the false values. Callbacks are functions which notify the application that some user interface event occurred. Usually callbacks will be called only when the user interacts with the application elements. If the application register the callback function, then the function will be called every time the event occurs. IUP has several global tables along with some system tools that must be initialized before any dialog is created. The default system language used by predefined dialogs and messages is English. But it can be changed to Portuguese or Spanish. Before running any of IUP’s functions, function Open must be run to initialize the toolkit. After running the last IUP function, function Close must be run so that the toolkit can free internal memory and close the interface system. Executing these functions in this order is crucial for the correct functioning of the toolkit. Between calls to the Open and Close functions, the application can create dialogs and display them.

Package gg provides a simple API for rendering 2D graphics in pure Go.

Package gfx is a convenience package for dealing with graphics in my pixel drawing experiments. My experiments are often published under https://gist.github.com/peterhellberg Usage examples and images can be found in the package README https://github.com/peterhellberg/gfx

Package graphics2d contains types and functions for 2D graphics rendering. If all you want to do is render a point, line, arc or path of a particular color into an image, then use the draw functions which hide all of the mechanics described below from you: However, to take full advantage of the package, here's a few more things you'll need to know. The lowest type is a Path. Paths start from a location and add steps using a number of control points. The number of control points determines the polynomial order of the step: 0 - line; 1 - quadratic; 2 - cubic; 3 - quartic; ... A path can be closed which forces a line from the start location to the last. Once a path is closed, no more steps can be added. Unlike other implementations, a path here represents a single stroke (pen down). There is no move (pen up) step. The Shape type is a container for paths and represents something that can be filled and rendered. When paths are rendered, they must be fillable (i.e. closed), so they are forced closed by the renderer. This can lead to unexpected results... If a shape is rendered with a pen (see DrawShape) and the pen has a stroke associated with it, then open paths are not an issue since strokes return closed paths. A pen is a combination of a color (or image), a stroke and a transformation from shape space to image space. If you're defining operations in the same space as the image, then the transformation is simply the identity transformation. If, however, say your operations are in a space [0, 1]^2, then you'd specify a transformation that maps [0, 1] => [0, width-1] etc. (i.e. scale by image width and height). Note that this transformation is applied *after* the stroke, so for a 1 pixel wide stroke the stroke width would be 1 / width. You don't have to use pens, you can use the RenderShape, PathProcessor, image filler and transformation functions directly. Pens just provide a convenient abstraction that hides path processing. Note that if the image is written to every graphics operation (as it is with the Draw*() functions), this can kill performance as the image defined by the shape's bounds is written every time. It's better to collect all the operations associated with a color in a shape and then render that shape once. The PathProcessor interface is where the magic happens. Given a path, a function implementing this interface returns a collection of paths derived from it. This allows for stroking, dashing and a variety of other possibilities: Shapes are rendered with the render functions. Paths are forced closed when rendered (see shapes above). Convenience methods are provided for rendering with a single color or an image (see also pens, above). The full render function allows a clip mask to be supplied, and the draw.Op to be specified. The Aff3 type provides the ability to specify affine transforms on Paths and Shapes. Utility functions are provided to generate common forms of paths: A shape function is provided to capture glyphs:

Package draw2d is a pure go 2D vector graphics library with support for multiple output devices such as images (draw2d), pdf documents (draw2dpdf) and opengl (draw2dgl), which can also be used on the google app engine. It can be used as a pure go Cairo alternative. draw2d is released under the BSD license. Operations in draw2d include stroking and filling polygons, arcs, Bézier curves, drawing images and text rendering with truetype fonts. All drawing operations can be transformed by affine transformations (scale, rotation, translation). Package draw2d follows the conventions of http://www.w3.org/TR/2dcontext for coordinate system, angles, etc... To install or update the package draw2d on your system, run: Package draw2d itself provides a graphic context that can draw vector graphics and text on an image canvas. The following Go code generates a simple drawing and saves it to an image file: There are more examples here: https://gopkg.in/llgcode/draw2d.v1/tree/master/samples Drawing on pdf documents is provided by the draw2dpdf package. Drawing on opengl is provided by the draw2dgl package. See subdirectories at the bottom of this page. The samples are run as tests from the root package folder `draw2d` by: Or if you want to run with test coverage: This will generate output by the different backends in the output folder. Laurent Le Goff wrote this library, inspired by Postscript and HTML5 canvas. He implemented the image and opengl backend with the freetype-go package. Also he created a pure go Postscript interpreter, which can read postscript images and draw to a draw2d graphic context (https://github.com/llgcode/ps). Stani Michiels implemented the pdf backend with the gofpdf package. - https://github.com/llgcode/ps: Postscript interpreter written in Go - https://github.com/gonum/plot: drawing plots in Go - https://github.com/muesli/smartcrop: content aware image cropping - https://github.com/peterhellberg/karta: drawing Voronoi diagrams - https://github.com/vdobler/chart: basic charts in Go

Package gruid provides a model for building grid-based applications. The interface abstracts rendering and input for different platforms. There are drivers for terminal apps (gruid-tcell), native graphical apps (gruid-sdl) and browser apps (gruid-js). The package uses an architecture of updating a model in response to messages strongly inspired from the bubbletea module for building terminal apps (https://github.com/charmbracelet/bubbletea), which in turn is based on the Elm Architecture (https://guide.elm-lang.org/architecture/). The typical usage looks like this: The values of type gruid.Effect returned by Update are optional and represent concurrently executed functions that produce messages. The gruid.Grid type is a convenient 2-dimensional slice type representing the screen's logical contents. See the relevant types documentation for details and usage.

Package tilegraphics implements a graphics rendering using small tiles. This is especially useful for devices with a slow bus to the display, like screens driven over SPI. Instantiate an Engine object using NewEngine and draw objects on it. The objects can be changed and moved after creation. These changes are recorded, but not directly sent to the screen. They're only sent on the next call to Display(). It is therefore recommended to only call Display() when the display should really be updated, to send all the updates in a single batch for improved performance.