Quack.com was an early voice portal company. The domain name later was used for Quack, an iPad search application from AOL. == History == It was founded in 1998 by Steven Woods, Jeromy Carriere and Alex Quilici as a Pittsburgh, Pennsylvania, USA, based voice portal infrastructure company named Quackware. Quack was the first company to try to create a voice portal: a consumer-based destination "site" in which consumers could not only access information by voice alone, but also complete transactions. Quackware launched a beta phone service in 1999 that allowed consumers to purchase books from sites such as Amazon and CDs from sites such as CDNow by answering a short set of questions. Quack followed with a set of information services from movie listings (inspired by, but expanding upon, Moviefone) to news, weather and stock quotes. This concept introduced a series of lookalike startups including Tellme Networks which raised more money than any Internet startup in history on a similar concept. Quack received its first venture funding from HDL Capital in 1999 and moved operations to Mountain View in Silicon Valley, California in 1999. A deal with Lycos was announced in May 2000. In September 2000 Quack was acquired for $200 million by America Online (AOL) and moved onto the Netscape campus with what was left of the Netscape team. Quack was attacked in the Canadian press for being representative of the Canadian "brain drain" to the US during the Internet bubble, focusing its recruiting efforts on the University of Waterloo, hiring more than 50 engineers from Waterloo in less than 10 months. Quack competitor Tellme Networks raised enormous funds in what became a highly competitive market in 2000, with the emergence of more than a dozen additional competitors in a 12-month period. Following its acquisition by America Online in an effort led by Ted Leonsis to bring Quack into AOL Interactive, the Quack voice service became AOLbyPhone as one of AOL's "web properties" along with MapQuest, Moviefone and others. Quack secured several patents that underlie the technical challenges of delivering interactive voice services. Constructing a voice portal required integrations and innovations not only in speech recognition and speech generation, but also in databases, application specification, constraint-based reasoning and artificial intelligence and computational linguistics. "Quack"'s name derived from the company goal of providing not only voice-based services, but more broadly "Quick Ubiquitous Access to Consumer Knowledge". The patents assigned to Quack.com include: System and method for voice access to Internet-based information, System and method for advertising with an Internet Voice Portal and recognizing the axiom that in interactive voice systems one must "know the set of possible answers to a question before asking it". System and method for determining if one web site has the same information as another web site. Quack.com was spoofed in The Simpsons in March 2002 in the episode "Blame It on Lisa" in which a "ComQuaak" sign is replaced by another equally crazy telecom company name. == 2010 onwards == In July 2010, quack.com became the focus of a new AOL iPad application, that was a web search experience. The product delivers web results and blends in picture, video and Twitter results. It enables you to preview the web results before you go to the site, search within each result, and flip through the results pages, making full use of the iPad's touch screen features. The iPad app was free via iTunes, but support discontinued in 2012.
Linux color management
Linux color management has the same goal as the color management systems (CMS) for other operating systems, which is to achieve the best possible color reproduction throughout an imaging workflow from its source (camera, video, scanner, etc.), through imaging software (Digikam, darktable, RawTherapee, GIMP, Krita, Scribus, etc.), and finally onto an output medium (monitor, video projector, printer, etc.). In particular, color management attempts to enable color consistency across media and throughout a color-managed workflow. Linux color management relies on the use of accurate ICC (International Color Consortium) and DCP (DNG Color Profile) profiles describing the behavior of input and output devices, and color-managed applications that are aware of these profiles. These applications perform gamut conversions between device profiles and color spaces. Gamut conversions, based on accurate device profiles, are the essence of color management. Historically, color management was not an initial design consideration of the X Window System on which much of Linux graphics support rests, and thus color-managed workflows have been somewhat more challenging to implement on Linux than on other OS's such as Microsoft Windows or macOS. This situation is now being progressively remedied, and color management under Linux, while functional, has not yet acquired mature status. Although it is now possible to obtain a consistent color-managed workflow under Linux, certain problems still remain: The absence of a central user control panel for color settings. Some hardware devices for color calibration lack Linux drivers, firmware or accessory data. Since ICC color profiles are written to an open specification, they are compatible across operating systems. Hence, a profile produced on one OS should work on any other OS given the availability of the necessary software to read it and perform the gamut conversions. This can be used as a workaround for the lack of support for certain spectrophotometers or colorimeters under Linux: one can simply produce a profile on a different OS and then use it in a Linux workflow. Additionally, certain hardware, such as most printers and certain monitors, can be calibrated under another OS and then used in a fully color-managed workflow on Linux. The popular Ubuntu Linux distribution added initial color management in the 11.10 release (the "Oneiric Ocelot" release). == Requirements for a color-managed workflow == Accurate device profiles obtained with source or output characterization software. Correctly loaded video card lookup tables (LUTs) (or monitor profiles that do not require LUT adjustments). Color-managed applications that are configured to use a correct monitor profile and input/output profiles, with support for control over the rendering intent and black point compensation. Calibration and profiling requires: for input devices (scanner, camera, etc.) a color target which the profiling software will compare to the manufacturer-provided color values of the target. or for output devices (monitor, printer, etc.) a reading with a specific device (spectrophotometer, colorimeter or spectrocolorimeter) of the color patch values and comparing the measured values against the values originally sent for output. === Monitor calibration and profiling === One of the critical elements in any color-managed workflow is the monitor, because, at one step or another, handling and making color adaptation through imaging software is required for most images, thus the ability of the monitor to present accurate colors is crucial. Monitor color management consists of calibration and profiling. The first step, calibration, is done by adjusting the monitor controls and the output of the graphics card (via calibration curves) to match user-definable characteristics, such as brightness, white point and gamma. The calibration settings are stored in a .cal file. The second step, profiling (characterization), involves measuring the calibrated display's response and recording it in a color profile. The profile is stored in an .icc file ("ICC file"). For convenience, the calibration settings are usually stored together with the profile in the ICC file. Note that .icm files are identical to .icc files - the difference is only in the name. Seeing correct colors requires using a monitor profile-aware application, together with the same calibration used when profiling the monitor. Calibration alone does not yield accurate colors. If a monitor was calibrated before it was profiled, the profile will only yield correct colors when used on the monitor with the same calibration (the same monitor control adjustments and the same calibration curves loaded into the video card's lookup table). macOS has built-in support for loading calibration curves and installing a system-wide color profile. Windows 7 onward allows loading calibration curves, though this functionality must be enabled manually. Linux and older versions of Windows require using a standalone LUT loader. === Device profiles === ICC profiles are cross-platform and can thus be created on other operating systems and used under Linux. Monitor profiles, however, require some additional attention. Since a monitor profile depends both on the monitor itself and on the video card, a monitor profile should only be used with the same monitor and video card with which it was created. The monitor settings should not be adjusted after creating the profile. In addition, since most calibration software use LUT adjustments during calibration, the corresponding LUTs must be loaded every time the display server (X11, Wayland) is started (e.g. with every graphical login). In the unlikely case of a colorimeter being unsupported by Linux, a profile created under Windows or macOS can be used under Linux. === Display-channel lookup tables === There are two approaches to loading display channel LUTs: Create a profile that does not modify video card LUTs and thus does not require LUTs be loaded later on. Ideally, this approach would rely on DDC-capable monitors—the internal monitor settings of which are set via calibration software. Unfortunately, monitors capable of making these adjustments through DDC are not common and are generally expensive. There is only one calibration software on Linux that can interact with a DDC monitor. For mainstream monitors, a couple of options exist: BasICColor software, which works with most colorimeters on the market, allows one to adjust display output via the monitor interface, and then to choose a "Profile, do not calibrate" option. By doing this, one can create a profile that does not require video card LUT adjustments. For EyeOne devices, EyeOne Match allows the user to calibrate to "Native" gamma and white point targets, which results in the LUT adjustment curves displayed after the calibration as a simple, linear 1:1 mapping (a straight line from corner to corner). Both BasICColor and EyeOne Match do not presently run under Linux but they are capable of creating a profile that does not require LUT adjustments. Use an LUT loader to actually load the LUT adjustments contained within the profile prepared during calibration. According to the documentation, these loaders do not modify the video card LUT by itself, but achieve the same type of adjustment by modifying the X server gamma ramp. Loaders are available for Linux distributions that use X.org or XFree86—the two most popular X servers on Linux. Other X servers are not guaranteed to work with the currently available loaders. There are two LUT loaders available for Linux: Xcalib is one such loader, and although it is a command-line utility, it is quite easy to use. dispwin is a part of Argyll CMS. If, for any reason, the LUT cannot be loaded, it is still recommended to go through the initial stages of calibration where a user is asked by calibration software to make some manual adjustments to the monitor, as this will often improve display linearity and also provide information on its color temperature. This is especially recommended for CRT monitors. === Color-managed applications === In ICC-aware applications, it is important to make sure the correct profiles are assigned to devices, mainly to the monitor and the printer. Some Linux applications can auto-detect the monitor profile, while others requires that it is specified manually. Although there is no designated place to store device profiles on Linux, /usr/share/color/icc/ has become the de facto standard. Most applications running under WINE have not been fully tested for color accuracy. While 8-bpp programs can have some color resolution difficulties due to depth conversion errors, colors in higher-depth applications should be accurate, as long as those programs perform their gamut conversions based on the same monitor profile as that used for loading the LUT, granted that the corresponding LUT adjustments are loaded. == List of color-managed applications == darktabl
Sprite (computer graphics)
In computer graphics, a sprite is a two-dimensional bitmap that is integrated into a larger scene, most often in a 2D video game. Originally, the term sprite referred to fixed-sized objects composited together, by hardware, with a background. Use of the term has since become more general. Systems with hardware sprites include arcade video games of the 1970s and 1980s; game consoles including as the Atari VCS (1977), ColecoVision (1982), Famicom (1983), Genesis/Mega Drive (1988); and home computers such as the TI-99/4 (1979), Atari 8-bit computers (1979), Commodore 64 (1982), MSX (1983), Amiga (1985), and X68000 (1987). Hardware varies in the number of sprites supported, the size and colors of each sprite, and special effects such as scaling or reporting pixel-precise overlap. Hardware composition of sprites occurs as each scan line is prepared for the video output device, such as a cathode-ray tube, without involvement of the main CPU and without the need for a full-screen frame buffer. Sprites can be positioned or altered by setting attributes used during the hardware composition process. The number of sprites which can be displayed per scan line is often lower than the total number of sprites a system supports. For example, the Texas Instruments TMS9918 chip supports 32 sprites, but only four can appear on the same scan line. The CPUs in modern computers, video game consoles, and mobile devices are fast enough that bitmaps can be drawn into a frame buffer without special hardware assistance. Beyond that, GPUs can render vast numbers of scaled, rotated, anti-aliased, partially translucent, very high resolution images in parallel with the CPU. == Etymology == According to Karl Guttag, one of two engineers for the 1979 Texas Instruments TMS9918 video display processor, this use of the word sprite came from David Ackley, a manager at TI. It was also used by Danny Hillis at Texas Instruments in the late 1970s. The term was derived from the fact that sprites "float" on top of the background image without overwriting it, much like a ghost or mythological sprite. Some hardware manufacturers used different terms, especially before sprite became common: Player/Missile Graphics was a term used by Atari, Inc. for hardware sprites in the Atari 8-bit computers (1979) and Atari 5200 console (1982). The term reflects the use for both characters ("players") and smaller associated objects ("missiles") that share the same color. The earlier Atari Video Computer System and some Atari arcade games used player, missile, and ball. Stamp was used in some arcade hardware in the early 1980s, including Ms. Pac-Man. Movable Object Block, or MOB, was used in MOS Technology's graphics chip literature. Commodore, the main user of MOS chips and the owner of MOS for most of the chip maker's lifetime, instead used the term sprite for the Commodore 64. OBJs (short for objects) is used in the developer manuals for the NES, Super NES, and Game Boy. The region of video RAM used to store sprite attributes and coordinates is called OAM (Object Attribute Memory). This also applies to the Game Boy Advance and Nintendo DS. == History == === Arcade video games === The use of sprites originated with arcade video games. Nolan Bushnell came up with the original concept when he developed the first arcade video game, Computer Space (1971). Technical limitations made it difficult to adapt the early mainframe game Spacewar! (1962), which performed an entire screen refresh for every little movement, so he came up with a solution to the problem: controlling each individual game element with a dedicated transistor. The rockets were essentially hardwired bitmaps that moved around the screen independently of the background, an important innovation for producing screen images more efficiently and providing the basis for sprite graphics. The earliest video games to represent player characters as human player sprites were arcade sports video games, beginning with Taito's TV Basketball, released in April 1974 and licensed to Midway Manufacturing for release in North America. Designed by Tomohiro Nishikado, he wanted to move beyond simple Pong-style rectangles to character graphics, by rearranging the rectangle shapes into objects that look like basketball players and basketball hoops. Ramtek released another sports video game in October 1974, Baseball, which similarly displayed human-like characters. The Namco Galaxian arcade system board, for the 1979 arcade game Galaxian, displays animated, multi-colored sprites over a scrolling background. It became the basis for Nintendo's Radar Scope and Donkey Kong arcade hardware and home consoles such as the Nintendo Entertainment System. According to Steve Golson from General Computer Corporation, the term "stamp" was used instead of "sprite" at the time. === Home systems === Signetics devised the first chips capable of generating sprite graphics (referred to as objects by Signetics) for home systems. The Signetics 2636 video processors were first used in the 1978 1292 Advanced Programmable Video System and later in the 1979 Elektor TV Games Computer. The Atari VCS, released in 1977, has a hardware sprite implementation where five graphical objects can be moved independently of the game playfield. The term sprite was not in use at the time. The VCS's sprites are called movable objects in the programming manual, further identified as two players, two missiles, and one ball. These each consist of a single row of pixels that are displayed on a scan line. To produce a two-dimensional shape, the sprite's single-row bitmap is altered by software from one scan line to the next. The 1979 Atari 400 and 800 home computers have similar, but more elaborate, circuitry capable of moving eight single-color objects per scan line: four 8-bit wide players and four 2-bit wide missiles. Each is the full height of the display—a long, thin strip. DMA from a table in memory automatically sets the graphics pattern registers for each scan line. Hardware registers control the horizontal position of each player and missile. Vertical motion is achieved by moving the bitmap data within a player or missile's strip. The feature was called player/missile graphics by Atari. Texas Instruments developed the TMS9918 chip with sprite support for its 1979 TI-99/4 home computer. An updated version is used in the 1981 TI-99/4A. === In 2.5D and 3D games === Sprites remained popular with the rise of 2.5D games (those which recreate a 3D game space from a 2D map) in the late 1980s and early 1990s. A technique called billboarding allows 2.5D games to keep onscreen sprites rotated toward the player view at all times. Some 2.5D games, such as 1993's Doom, allow the same entity to be represented by different sprites depending on its rotation relative to the viewer, furthering the illusion of 3D. Fully 3D games usually present world objects as 3D models, but sprites are supported in some 3D game engines, such as GoldSrc and Unreal, and may be billboarded or locked to fixed orientations. Sprites remain useful for small details, particle effects, and other applications where the lack of a third dimension is not a major detriment. == Systems with hardware sprites == These are base hardware specs and do not include additional programming techniques, such as using raster interrupts to repurpose sprites mid-frame.
Joseph Stanislaus Ostoja-Kotkowski
Joseph Stanislaus Ostoja-Kotkowski AM, FRSA (also known as J. S. Ostoja-Kotkowski, Ostoja and Stan Ostoja-Kotkowski; 28 December 1922 – 2 April 1994) was best known for his ground-breaking work in chromasonics, laser kinetics and 'sound and image' productions. He earned recognition in Australia and overseas for his pioneering work in laser sound and image technology. His work included painting (instrumental in developing geometric art in Australia), photography, film-making, theatre design, fabric design, murals, kinetic and static sculpture, stained glass, vitreous enamel murals, op-collages, computer graphics, and laser art. Ostoja flourished between 1940 and 1994. Ostoja's films are still being exhibited. == Biography == Joseph Stanislaus Ostoja-Kotkowski was born in Golub, Poland, on 28 December 1922, descending from an old noble family that was part of the Clan of Ostoja. He studied drawing under Olgierd Vetesco in Przasnysz from 1940-1945. After winning a scholarship, he completed his studies at the Düsseldorf Academy of Fine Arts in Germany in 1949. In 1950 Ostoja migrated to Australia, arriving in Melbourne where he supported himself with work as a labourer. He enrolled at the Victorian School of Fine Arts National Gallery School under Alan Sumner and William Dargie 1950-1955 and there introduced the new abstract expression of Europe both to lecturers and students. He settled in the Adelaide Hills, South Australia, on the Booth estate at Stirling, living under the patronage of the Booth family for over 40 years (Freya Booth, the wife of Edward Stirling Booth, was a daughter of the artist Sir Hans Heysen). His first one-man exhibition was also in South Australia at the Royal Society of Arts, Adelaide. In 1956 Ostoja met and collaborated with Ian Davidson in the production of the short film Five South Australian Artists, and became involved in stage and theatre set design. He co-produced several experimental films again with Ian Davidson, including The Quest of Time in 1957 Ostoja's work in abstract expression began to receive accolades. He won the Cornell Prize for the canvas Form in Landscape. He started to design sets for theatre and dance including for Six Characters in Search of an Author by Luigi Pirandello (1957); the South Australian production of Samuel Beckett's Waiting for Godot (1958); Gaetano Donizetti's Elixir of Love, with novel light settings and modulations, for the Elder Conservatorium of the University of Adelaide which used his techniques for their Opera Workshops (1959); for The Egg; and for two performances of the South Australian Ballet Theatre with light/colour abstract presentations (1959). 1960 This year he designed sets for a new opera group which would eventually grow into the South Australian Opera Company. Among other theatrical events, he designed and executed the scenery for Moon on a Rainbow Shawl by Errol John, and The Teahouse of the August Moon by John Patrick, (a production by the University of Adelaide Theatre Guild). He received artistic satisfaction but little financial reward for these efforts. In this year also, he staged a visual production on the theme of Orpheus, using dance, music and voice with several projectors. This was the first attempt at quadraphonic sound in Australia, working in collaboration with Derek Jolly, who provided the sound and projection equipment. It was also the first demonstration of "Chromasonics" - the science of translating sound into visual images. Ostoja then designed innovative "abstracted" scenery for a production of The Marriage of Figaro and Benjamin Britten's The Turn of the Screw. 1961 Ostoja designed the sets for the controversial South Australian production of Patrick White's The Ham Funeral - also Alan Seymour's Swamp Creatures, both performed by the University of Adelaide Theatre Guild. He designed and constructed six stained glass windows for the Refectory at the University of Adelaide. In this period Ostoja designed special lights and gauzes for difficult effects required in an ambitious production of the opera Don Carlos by the Opera Workshop, for the Elder Conservatorium. 1962 Ostoja designed and built sets for the production of J.B, by Archibald MacLeish, for the second Adelaide Festival of Arts. He exhibited vitreous enamel works in Melbourne's Argus Gallery. Max Harris, in The Bulletin of 20 October 1962, praised Ostoja's sets for My Cousin from Fiji in Union Theatre, Adelaide, and his technique of rear screen projections as later adopted throughout Australia. 1963 Ostoja continued to develop Multi-Image projections, demonstrating for the first time in Australia the concept later to be known as 'audio-visuals!'. Ostoja gave Sir Herbert Read, the art critic, a personal viewing of one of his visual presentations. At Christmas, in the Elder Conservatorium, collaborating again with Derek Jolly, Ostoja gave what was probably the world's first "visual concert", using special projectors and incorporating music, colours and shapes. 1964 With fellow Adelaide artist John Dallwitz, Ostoja co-designed the first of several experimental dance and stage productions in the Adelaide Festival of Arts Sound and Image. The production featured Adelaide dancer Elizabeth_Cameron_Dalman. Also for the Adelaide Festival of Arts of that year, he designed the largest light mosaic ever staged up to that time, upon the facade of an 11-storey building. Ostoja was invited to New Zealand, and exhibited the first electronically generated images in Australia in Melbourne, at the Argus Gallery. His design for the 50-foot (15 m) bas-relief mural for the new B.P. building in Melbourne was the subject of a film which won the "Blue Ribbon" Award in the American Film Festival in New York. 1965 Ostoja designed and made the first light kinetic mural in Australia, and continued to evolve theatrical works using multi-screen and Multi-projector techniques. The Production of Jean Genet's The Balcony was very controversial. With Elizabeth Dalman, Ostoja produced new dance forms for Melbourne Television. He introduced Op Art to Australia, both at South Yarra Gallery in Melbourne, and Gallery A in Sydney. 1966 With John Dallwitz, Ostoja was invited by the Adelaide Festival of Arts to present more experimental theatre, Sound and image 1966. This highly acclaimed production incorporated Australian poetry into the sound, electronic music, and visual images and featured the dancer Antonio Rodrigues. The architect Robin Boyd commissioned Ostoja to design two large Op murals for the Australian Pavilion entrance at the Expo 67. Ostoja was awarded a Churchill Fellowship, which enabled him to have extensive world travel, comparing art and technology in many countries. He began to work with language, contemporary poetry and prose, and computers. 1967 John Dallwitz and Ostoja presented Sound and Image at the Festival of Perth. In Berne, Switzerland, Ostoja received the "Excellence F.I.A.P." Award for innovative photography. 1968 At the Adelaide Festival of Arts, Ostoja and John Dallwitz collaborated again to stage Sound and Image. This was the first theatre production in the world to use a laser beam. It also included the first science fiction play (The Veldt by Ray Bradbury) performed in Australia. Ostoja's theatre methods were increasingly attracting the attention of critics to how plays were staged. "Chromasonics", developed and introduced by Ostoja, was now being used extensively in the entertainment industry. 1969 Ostoja staged Krzysztof Penderecki's St. Luke Passion, a controversial, contemporary religious work. The South Australian The Advertiser wrote an extensive critique of Ostoja's work. Robin Boyd commissioned Ostoja to build a "Chromasonic" exhibit located in the Space Tube at the Australian Pavilion for Expo '70 in Osaka. 1970 Ostoja presented an Australian Aboriginal Dreamtime theme in his "Sound and Image" theatre, working with leading contemporary figures in poetry, music and dance. This was the first production of its kind in Australia, and appeared after the Festival in Melbourne, Sydney, Canberra and Perth. Ostoja's Space Scape mural, sixty feet long by ten feet high, won the Australia-wide competition for a mural for Adelaide Airport. His 120 feet (37 m) high 'light and sound' structure for the Adelaide Festival was the first of its kind in the world. 1971 Ostoja awarded a Creative Arts Fellowship at the Australian National University, Canberra. His 18-month stay resulted in the design and building of a "Chromasonics unit-laser", a 100 feet (30 m) Chromasonic tower, and a world premiere of a Synchronos concert. 1972 With Don Burrows and Don Banks, Ostoja presented Synchronos 72, where one could "hear the colours and see the sounds". Ostoja added Cymatics, developed during the Fellowship, to his workshop repertoire. He was invited to exhibit his photography in the National Gallery, Melbourne. 1973 Ostoja received a Fellowship from the Australian American Education Associatio
Sprayprinter
SprayPrinter is a device that attaches to aerosol paint cans whereby users can print images via Bluetooth from a smartphone onto a wall or almost any surface. == History == The technology behind SprayPrinter was developed by Mihkel Joala. He explained in a 2016 interview with New Atlas that his idea was inspired by the modern car engine and the Nintendo Wii console. "Engines nowadays use extremely fast valves to spray fuel to [the] combustion chamber," says Joala. "I realized I can use them to shoot paint with pinpoint accuracy." As of December 2021, the company appears to be no longer selling products. == Awards and Recognitions == In 2015, SprayPrinter received €8,000 from the Estonian prototyping contest Prototron for its initial prototype. In 2016, the SprayPrinter team won the grand prize of €30,000 from the televised pitching competition Ajujaht.
Plotly
Plotly is a technical computing company headquartered in Montreal, Quebec, that develops online data analytics and visualization tools. Plotly provides online graphing, analytics, and statistics tools for individuals and collaboration, as well as scientific graphing libraries for Python, R, MATLAB, Perl, Julia, Arduino, JavaScript and REST. == History == Plotly was founded by Alex Johnson, Jack Parmer, Chris Parmer, and Matthew Sundquist. The founders' backgrounds are in science, energy, and data analysis and visualization. Early employees include Christophe Viau, a Canadian software engineer and Ben Postlethwaite, a Canadian geophysicist. Plotly was named one of the Top 20 Hottest Innovative Companies in Canada by the Canadian Innovation Exchange. Plotly was featured in "startup row" at PyCon 2013, and sponsored the SciPy 2018 conference. Plotly raised $5.5 million during its Series A funding, led by MHS Capital, Siemens Venture Capital, Rho Ventures, Real Ventures, and Silicon Valley Bank. The Boston Globe and Washington Post newsrooms have produced data journalism using Plotly. In 2020, Plotly was named a Best Place to Work by the Canadian SME National Business Awards, and nominated as Business of the Year. == Products == Plotly offers open-source and enterprise products. Dash is an open-source Python, R, and Julia framework for building web-based analytic applications. Many specialized open-source Dash libraries exist that are tailored for building domain-specific Dash components and applications. Some examples are Dash DAQ, for building data acquisition GUIs to use with scientific instruments, and Dash Bio, which enables users to build custom chart types, sequence analysis tools, and 3D rendering tools for bioinformatics applications. Dash Enterprise is Plotly's paid product for building, testing, deploying, managing and scaling Dash applications organization-wide. Chart Studio Cloud is a free, online tool for creating interactive graphs. It has a point-and-click graphical user interface for importing and analyzing data into a grid and using stats tools. Graphs can be embedded or downloaded. Chart Studio Enterprise is a paid product that allows teams to create, style, and share interactive graphs on a single platform. It offers expanded authentication and file export options, and does not limit sharing and viewing. Data visualization libraries Plotly.js is an open-source JavaScript library for creating graphs and powers Plotly.py for Python, as well as Plotly.R for R, MATLAB, Node.js, Julia, and Arduino and a REST API. Plotly can also be used to style interactive graphs with Jupyter notebook. Figure converters which convert matplotlib, ggplot2, and IGOR Pro graphs into interactive, online graphs. == Data visualization libraries == Plotly provides a collection of supported chart types across several programming languages: == Dash == Dash is a Python framework built on top of React, a JavaScript library. Dash also works for R, and most recently supports Julia. While still described as a Python framework, Python isn't used for the other languages: "... describing Dash as a Python framework misses a key feature of its design: the Python side (the back end/server) of Dash was built to be lightweight and stateless [allowing] multiple back-end languages to coexist on an equal footing". It is possible to integrate D3.js charts as Dash components. Dash provides the default CSS (plus HTML and JavaScript), but for custom styling Dash applications, CSS can be added, or Dash Enterprise used. === Dash Enterprise === Dash Enterprise is Plotly's paid product for building, testing, deploying, managing and scaling Dash applications organization-wide. The product integrates with enterprise IT systems to enable organizations to build, deploy and scale low-code Dash applications. With open-source Dash, analytic applications can be run from a local machine, but cannot be easily accessed by others in the organization. ==== Enterprise IT integration ==== Dash Enterprise installs on cloud environments and on-premises. Amazon Web Services, Google Cloud Platform, and Microsoft Azure are supported, as are multiple Linux on-premises servers. Authentication integrations include LDAP, AD, PKI, Okta, SAML, OAuth2, SSO, and email authentication, and Dash application access is managed through a GUI rather than code. Dash Enterprise connects to major big data backends, including Salesforce, PostgreSQL, Databricks via PySpark, Snowflake, Dask, Datashader, and Vaex. In 2020, Plotly partnered with NVIDIA to integrate Dash with RAPIDS, and NVIDIA participated in Plotly's Series C funding round. ==== Low-code capabilities ==== Dash Enterprise enables low-code development of Dash applications, which is not possible with open-source Dash. Enterprise users can write applications in multiple development environments, including Jupyter Notebook. Dash Enterprise ships with several “development engines” for drag-and-drop application editing, application design, and automated reporting, as well as dozens of artificial intelligence and machine learning application templates. ==== Deployment and scaling ==== Dash application code is deployed to Dash Enterprise using the git-push command. Dash application deployments are containerized to avoid dependency conflicts, and can be embedded in existing web platforms without iframes. Deployed applications can be managed and accessed in a single portal called App Manager, where administrators can control user authentication and view usage analytics. Dash Enterprise scales horizontally with Kubernetes. Jobs queuing, GPU acceleration, and CPU parallelization support high performance computing requirements. Plotly also offers professional services for application development and workshop training.
Display list
A display list, also called a command list in Direct3D 12 and a command buffer in Vulkan, is a series of graphics commands or instructions that are run when the list is executed. Systems that make use of display list functionality are called retained mode systems, while systems that do not are as opposed to immediate mode systems. In OpenGL, display lists are useful to redraw the same geometry or apply a set of state changes multiple times. This benefit is also used with Direct3D 12's bundle command lists. In Direct3D 12 and Vulkan, display lists are regularly used for per-frame recording and execution. == Origins in vector displays == The vector monitors or calligraphic displays of the 1960s and 1970s used electron beam deflection to draw line segments, points, and sometimes curves directly on a CRT screen. Because the image would immediately fade, it needed to be redrawn many times a second (storage tube CRTs retained the image until blanked, but they were unsuitable for interactive graphics). To refresh the display, a dedicated CPU called a Display Processor or Display Processing Unit (DPU) was used, which had a memory buffer for a "display list", "display file", or "display program" containing line segment coordinates and other information. Advanced Display Processors also supported control flow instructions, which were useful for drawing repetitive graphics such as text, and some could perform coordinate transformations such as 3D projection. == Home computer display list functionality == One of the earliest systems with a true display list was the Atari 8-bit computers. The display list (actually called so in Atari terminology) is a series of instructions for ANTIC, the video co-processor used in these machines. This program, stored in the computer's memory and executed by ANTIC in real-time, can specify blank lines, any of six text modes and eight graphics modes, which sections of the screen can be horizontally or vertically fine-scrolled, and trigger Display List Interrupts (called raster interrupts or HBI on other systems). The Amstrad PCW family contains a Display List function called the 'Roller RAM'. This is a 512-byte RAM area consisting of 256 16-bit pointers in RAM, one for each line of the 720 × 256 pixel display. Each pointer identifies the location of 90 bytes of monochrome pixels that hold the line's 720 pixel states. The 90 bytes of 8 pixel states are spaced at 8-byte intervals, so there are 7 unused bytes between each byte of pixel data. This suits how the text-orientated PCW constructs a typical screen buffer in RAM, where the first character's 8 rows are stored in the first 8 bytes, the second character's rows in the next 8 bytes, and so on. The Roller RAM was implemented to speed up display scrolling as it would have been unacceptably slow for its 3.4 MHz Z80 to move up the 23 KB display buffer 'by hand' i.e. in software. The Roller RAM starting entry used at the beginning of a screen refresh is controlled by a Z80-writable I/O register. Therefore, the screen can be scrolled simply by changing this I/O register. Another system using a Display List-like feature in hardware is the Amiga, which, not coincidentally, was also designed by some of the same people who developed the custom hardware for the Atari 8-bit computers. Once directed to produce a display mode, it would continue to do so automatically for every following scan line. The computer also included a dedicated co-processor, called "Copper", which ran a simple program or 'Copper List' intended for modifying hardware registers in sync with the display. The Copper List instructions could direct the Copper to wait for the display to reach a specific position on the screen, and then change the contents of hardware registers. In effect, it was a processor dedicated to servicing raster interrupts. The Copper was used by Workbench to mix multiple display modes (multiple resolutions and color palettes on the monitor at the same time), and by numerous programs to create rainbow and gradient effects on the screen. The Amiga Copper was also capable of reconfiguring the sprite engine mid-frame, with only one scanline of delay. This allowed the Amiga to draw more than its 8 hardware sprites, so long as the additional sprites did not share scanlines (or the one scanline gap) with more than 7 other sprites. i.e., so long as at least one sprite had finished drawing, another sprite could be added below it on the screen. Additionally, the later 32-bit AGA chipset allowed the drawing of bigger sprites (more pixels per row) while retaining the same multiplexing. The Amiga also had dedicated block-shifter ("blitter") hardware, which could draw larger objects into a framebuffer. This was often used in place of, or in addition to, sprites. In more primitive systems, the results of a display list can be simulated, though at the cost of CPU-intensive writes to certain display modes, color control, or other visual effect registers in the video device, rather than a series of rendering commands executed by the device. Thus, one must create the displayed image using some other rendering process, either before or while the CPU-driven display generation executes. In many cases, the image is also modified or re-rendered between frames. The image is then displayed in various ways, depending on the exact way in which the CPU-driven display code is implemented. Examples of the results possible on these older machines requiring CPU-driven video include effects such as Commodore 64/128's FLI mode, or Rainbow Processing on the ZX Spectrum. == Usage in OpenGL == To delimit a display list, the glNewList and glEndList functions are used, and to execute the list, the glCallList function is used. Almost all rendering commands that occur between the function calls are stored in the display list. Commands that affect the client state are not stored in display lists. Display lists are named with an integer value, and creating a display list with the same name as one already created overrides the first. The glNewList function expects two arguments: an integer representing the name of the list, and an enumeration for the compilation mode. The two modes include GL_COMPILE_AND_EXECUTE, which compiles and immediately executes, and GL_COMPILE, which only compiles the list. Display lists enable the use of the retained mode rendering pattern, which is a system in which graphics commands are recorded (retained) to execute in succession at a later time. This is contrary to immediate mode, where graphics commands are immediately executed on client calls. == Usage in Direct3D 12 == Command lists are created using the ID3D12Device::CreateCommandList function. Command lists may be created in several types: direct, bundle, compute, copy, video decode, video process, and video encoding. Direct command lists specify that a command list the GPU can execute, and doesn't inherit any GPU state. Bundles, are best used for storing and executing small sets of commands any number of times. This is used differently than regular command lists, where commands stored in a command list are typically executed only once. Compute command lists are used for general computations, with a common use being calculating mipmaps. A copy command list is strictly for copying and the video decode and video process command lists are for video decoding and processing respectively. Upon creation, command lists are in the recording state. Command lists may be re-used by calling the ID3D12GraphicsCommandList::Reset function. After recording commands, the command list must be transitioned out of the recording state by calling ID3D12GraphicsCommandList::Close. The command list is then executed by calling ID3D12CommandQueue::ExecuteCommandLists.