Skip to content

Commit

Permalink
Fix conflict in README
Browse files Browse the repository at this point in the history
  • Loading branch information
@nedbat
nedbat committed May 18, 2014
2 parents 7f78636 + a06a4b1 commit f1e87a1
Show file tree
Hide file tree
Showing 22 changed files with 1,097 additions and 53 deletions.
154 changes: 101 additions & 53 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,40 +1,33 @@
*500 Lines or Less*
===================

This is the source for the book *500 Lines or Less*,
the fourth in the [Architecture of Open Source Applications](http://aosabook.org) series.
As with other books in the series,
all written material will be covered by the Creative Commons - Attribution license,
and all code by the MIT License:
please see the [license description](LICENSE.md) for details.
In addition,
all royalties from paid-for versions will all go to Amnesty International.
This is the source for the book *500 Lines or Less*, the fourth in the
[Architecture of Open Source Applications](http://aosabook.org) series. As
with other books in the series, all written material will be covered by the
Creative Commons - Attribution license, and all code by the MIT License: please
see the [license description](LICENSE.md) for details. In addition, all
royalties from paid-for versions will all go to Amnesty International.

Mission
-------

Every architect studies family homes,
apartments,
schools,
and other common types of buildings during her training.
Equally,
every programmer ought to know how a compiler turns text into instructions,
how a spreadsheet updates cells,
and how a browser decides what to put where when it renders a page.
This book's goal is to give readers that broad-ranging overview,
and while doing so,
to help them understand how software designers think.
Every architect studies family homes, apartments, schools, and other common
types of buildings during her training. Equally, every programmer ought to
know how a compiler turns text into instructions, how a spreadsheet updates
cells, and how a browser decides what to put where when it renders a page.
This book's goal is to give readers that broad-ranging overview, and while
doing so, to help them understand how software designers think.

Contributions should not focus on the details of one algorithm
or on the features of a particular language.
Instead,
they should discuss the decisions and tradeoffs software architects make when crafting an application:
Contributions should not focus on the details of one algorithm or on the
features of a particular language. Instead, they should discuss the decisions
and tradeoffs software architects make when crafting an application:

* Why divide the application into these particular modules with these particular interfaces?
* Why divide the application into these particular modules with these
particular interfaces?
* Why use inheritance here and composition there?
* Why multi-thread this but not that?
* When should the application allow for or rely on plugins,
and how should they be configured and loaded?
* When should the application allow for or rely on plugins, and how should
they be configured and loaded?

Contribution Guidelines
-----------------------
Expand All @@ -61,106 +54,161 @@ Contributors
<th>Name</th>
<th>Affiliation</th>
<th>Project</th>
<!-- Is there some way we can loosen up the idea that Github is the one and only place to find code online? -->
<!-- Also, are home pages not a thing any more? -->
<th>Online</th>
<th>GitHub</th>
<th>Twitter</th>
<th>Email (if you choose)</th>
</tr>
<tr>
<td>Mike DiBernardo</td>
<td>freelance</td>
<td>editorial</td>
<td>@MichaelDiBernardo</td>
<td></td>
<td>
<ul>
<li><a href="https://twitter.com/mdibernardo">@mdibernardo</a></li>
<li><a href="http://mikedebo.ca">mikedebo.ca</a></li>
</ul>
</td>
<td><a href="https://github.com/MichaelDiBernardo">MichaelDiBernardo</a></td>
<td>mikedebo@gmail.com</td>
</tr>
<tr>
<td>Dustin Mitchell</td>
<td>Mozilla</td>
<td>cluster</td>
<td>@djmitche</td>
<td>&nbsp;</td>
<td><a href="https://github.com/djmitche">djmitche</a></td>
<td>dustin@mozila.com</td>
</tr>
<tr>
<td>Audrey Tang</td>
<td>g0v.tw, Socialtext, Apple</td>
<td>spreadsheet</td>
<td>@audreyt</td>
<td>@audreyt</td>
<td>
<ul>
<li><a href="https://twitter.com/audreyt">@audreyt</a></li>
</ul>
</td>
<td><a href="https://github.com/audreyt">audreyt</a></td>
<td>audreyt@audreyt.org</td>
</tr>
<tr>
<td>Greg Wilson</td>
<td>Mozilla</td>
<td>web-server</td>
<td>@gvwilson</td>
<td>@gvwilson</td>
<td>
<ul>
<li><a href="https://twitter.com/gvwilson">@gvwilson</a></li>
</ul>
</td>
<td><a href="https://github.com/gvwilson">gvwilson</a></td>
<td>gvwilson@third-bit.com</td>
</tr>
<tr>
<td>Kresten Krab Thorup</td>
<td>Trifork</td>
<td>torrent client</td>
<td>@krestenkrab</td>
<td>@drkrab</td>
<td>
<ul>
<li><a href="https://twitter.com/drkrab">@drkrab</a></li>
</ul>
</td>
<td><a href="https://github.com/krestenkrab">krestenkrab</a></td>
<td>krab@trifork.com</td>
</tr>
<tr>
<td>Taavi Burns</td>
<td>Points.com</td>
<td>data-store</td>
<td>@taavi</td>
<td>@jaaaarel</td>
<td>
<ul>
<li><a href="https://twitter.com/jaaaarel">@jaaaarel</a></li>
</ul>
</td>
<td><a href="https://github.com/taavi">taavi</a></td>
<td>taavi.burns@points.com</td>
</tr>
<tr>
<td>Guido van Rossum</td>
<td>Dropbox</td>
<td>crawler</td>
<td>@gvanrossum</td>
<td>@gvanrossum</td>
<td>
<ul>
<li><a href="https://twitter.com/gvanrossum">@gvanrossum</a></li>
</ul>
</td>
<td><a href="https://github.com/gvanrossum">gvanrossum</a></td>
<td>guido@python.org</td>
</tr>
<tr>
<td>Erick Dransch</td>
<td>Upverter</td>
<td>Modeller</td>
<td>@EkkiD</td>
<td>@ErickDransch</td>
<td>
<ul>
<li><a href="https://twitter.com/ErickDransch">@ErickDransch</a></li>
</ul>
</td>
<td><a href="https://github.com/EkkiD">EkkiD</a></td>
<td>erick.dransch@upverter.com</td>
</tr>
<tr>
<td>Sarah Mei</td>
<td>Ministry of Velocity</td>
<td>testing framework</td>
<td><a href='http://github.com/sarahmei'>@sarahmei</a></td>
<td><a href='http://twitter.com/sarahmei'>@sarahmei</a></td>
<td></td>
<td>
<ul>
<li><a href="https://twitter.com/sarahmei">@sarahmei</a></li>
</ul>
</td>
<td><a href="https://github.com/sarahmei">sarahmei</a></td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Ned Batchelder</td>
<td>edX</td>
<td>templating engine</td>
<td>@nedbat</td>
<td>@nedbat</td>
<td>
<ul>
<li><a href="http://nedbatchelder.com">nedbatchelder.com</a></li>
<li><a href="https://twitter.com/nedbat">@nedbat</a></li>
</ul>
</td>
<td><a href="https://github.com/nedbat">nedbat</a></td>
<td>ned@nedbatchelder.com</td>
</tr>
<tr>
<td>Leah Hanson</td>
<td>Google</td>
<td>static analysis</td>
<td>@astrieanna</td>
<td>@astrieanna</td>
<td>
<ul>
<li><a href="https://twitter.com/astrieanna">@astrieanna</a></li>
</ul>
</td>
<td><a href="https://github.com/astrieanna">astrieanna</a></td>
<td>leah.a.hanson@gmail.com</td>
</tr>
<tr>
<td>Christian Muise</td>
<td>University of Melbourne</td>
<td>flow-shop</td>
<td>@haz</td>
<td>@cjmuise</td>
<td>
<ul>
<li><a href="https://twitter.com/cjmuise">@cjmuise</a></li>
</ul>
</td>
<td><a href="https://github.com/haz">haz</a></td>
<td>christian.muise@gmail.com</td>
<tr>
<td>Carlos Scheidegger</td>
<td>AT&amp;T Research</td>
<td>rasterizer</td>
<td>
<ul>
<li><a href="https://twitter.com/cjmuise">@cscheid</a></li>
</ul>
</td>
<td><a href="https://github.com/cscheid">cscheid</a></td>
<td>carlos.scheidegger@gmail.com</td>
</tr>
</table>
51 changes: 51 additions & 0 deletions rasterizer/README.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# `tiny_gfx`: A tiny rasterizer

A *rasterizer* is a piece of software that converts arbitrary shapes
into *raster images*, which is just a funny name for rectangular grids
of pixels. A rasterizer, in some way or another, is at the heart of
pretty much every modern display technology today, from computer
displays to e-ink displays to printers both 2D and 3D (the graphics in
laser shows are the most notable exception).

In this chapter, I will teach you a little about how rasterizers work,
by describing `tiny_gfx`, a simple rasterizer in pure Python. Along
the way we will pick up some techniques that show up repeatedly in
computer graphics code. Having a bit of mathematical background on
linear algebra will help, but I hope the presentation will be
self-contained.

`tiny_gfx` is not practical in many ways. Besides being slow (see
below), the main shortcoming in `tiny_gfx` is that shapes are all of a
single solid color. Still, for 500 lines of code, `tiny_gfx` has a
relatively large set of features:

- alpha blending for semi-transparent colors
- polygonal shapes (possibly concave, but not self-intersecting)
(TODO: right now only convex polygons are supported)
- circles and ellipses
- transformations of shapes
- boolean operations on shapes (union, intersection, subtraction)
- antialiasing
- empty space skipping and fast rasterization of runs for general
shapes

Maybe most interestingly, shapes in `tiny_gfx` are extensible. New
shapes are easily added, and they compose well with the other parts of
the code.

A description of the current version of the code is in `doc/README.md`.

## A performance caveat

Rasterizers are so central to display technology that their
performance can make or break a piece of software, and these days the
fastest rasterizers are all based in hardware. Your videogame graphics
card (and even the cheapest smartphones these days) is rasterizing
polygons in highly parallel processors; 192 cores is a typical
number. It should be no surprise, then, that the rasterizer we will
see here is slow: if CPU-intensive tasks in Python run around 50 times
slower than heavily-optimized, low-level code, and if a graphics
driver has around 200 cores at its disposal, a slowdown of 10,000
times should not be surprising. In reality, `tiny_gfx` is closer to
1,000,000 times slower than the special-purpose graphics rasterizer
from the laptop in which I'm developing it.
Loading

0 comments on commit f1e87a1

Please sign in to comment.