Million Ether Homepage

Storing Colors in a Pixel Grid

Million Ether Page Essential Smart Contract

Tip: Mining only when there are transactions

Tip: Using Remix IDE

Getting Started

Getting The Pixels and Ethereum Events

Building a DApp UI

Drawing in HTML Canvas

Using Websockets with Web3

Web3 and Events Over WebSockets

Drawing Pixels from the Blockchain

Viewing Pixels

Buying An Image -- Reading Pixels

Buying An Image -- Sending Transactions

Pixel bidding and structs

Payable Contracts, payable Functions

Contract Owner and require

Payable color pixel function

Buying Pixels

Sending funds from a contract

The safer way to send funds from a contract

The Pull Payment Pattern - Withdraw payments when outbid

Million Ether Homepage Summary

Auctioning Pixels

solidity

In this course, we'll build a DApp inspired by [The Million Dollar Homepage](https://en.wikipedia.org/wiki/The_Million_Dollar_Homepage). We'll build a 1 million pixel page, and each pixel can be colored by placing the highest bid.

In this course we'll walk through every step of writing a smart contract, deploying it, hosting auctions, and connecting it to the browser through web3. 

If you're looking to build real, full-stack ethereum Dapps, then this is a perfectly-sized example.

We'll build a DApp inspired by the Million Dollar Homepage, powered by an auction on the Ethereum blockchain

Our contract has a millon pixels. At some point, we're going to want to draw the image that all the pixels create.

Our current pixels method lets us retrieve one pixel at a time, that would take a million calls -- I'm sure we can do better than that.

A first try might be to create a function 

  function getPixels() public constant returns (bytes3[1000][1000]) {
      return pixels;
  }

If you try this, it may or may not work. It will be slow either way, because it's a lot of data.

Another idea we might try is to just get each row:

  function getRow(uint x) public constant returns (bytes3[1000]) {
    return pixels[x];
  }

This will work in a pinch, but it still requires a thousand calls, one for each row.

When we build the UI we probably want to cache the image so we don't have to keep reading from the blockchain. If we had a script to periodically recreate the image, making 1,000 local calls isn't that big of a deal.

However, it would be great to have a real time component to this page. We want any visitor to this page to automatically see any new pixels the instant their purchased.

And thankfully, Ethereum has some mechanisms for this so that we don't have to read every pixel to find out what changed.

. The idea with events is that our contracts can emit events at certain points in our code. These events can be indexed, which means we can find specific events very quickly.

---
title: 'Getting The Pixels and Ethereum Events'


slug: 'getting-all-the-pixels-first-pass'
thumbnail: https://embed-ssl.wistia.com/deliveries/a7f0407377660872e7df513aeccadd4a4e949be6.jpg

privateVideoUrl: https://fullstack.wistia.com/medias/8vfe43plc8
description: ""



---

Our contract has a millon pixels. At some point, we're going to want to draw the image that all the pixels create.

Our current pixels method lets us retrieve one pixel at a time, that would take a million calls -- I'm sure we can do better than that.



A first try might be to create a function `getPixels` which just returns them all:

      function getPixels() public constant returns (bytes3[1000][1000]) {
          return pixels;
      }

If you try this, it may or may not work. It will be slow either way, because it's a lot of data.

Another idea we might try is to just get each row:

      function getRow(uint x) public constant returns (bytes3[1000]) {
        return pixels[x];
      }

This will work in a pinch, but it still requires a thousand calls, one for each row.

When we build the UI we probably want to cache the image so we don't have to keep reading from the blockchain. If we had a script to periodically recreate the image, making 1,000 local calls isn't that big of a deal.

However, it would be great to have a real time component to this page. We want any visitor to this page to automatically see any new pixels the instant their purchased.

And thankfully, Ethereum has some mechanisms for this so that we don't have to read every pixel to find out what changed.

The mechanism is Ethereum _Events_. The idea with events is that our contracts can emit events at certain points in our code. These events can be indexed, which means we can find specific events very quickly.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Million Ether Homepage

WELCOMEIntroduction

Introduction:

Start Here

Module 1: Getting Started

Lesson 1: (3:23)

Million Ether Homepage

Lesson 2: (3:18)

Storing Colors in a Pixel Grid

Lesson 3: (4:29)

Million Ether Page Essential Smart Contract

Lesson 4: (1:56)

Tip: Mining only when there are transactions

Lesson 5: (7:08)

Tip: Using Remix IDE

Module 2: Viewing Pixels

Lesson 1: (6:08)

Getting The Pixels and Ethereum Events

Lesson 2: (7:15)

Gas

Lesson 3: (1:01)

Building a DApp UI

Lesson 4: (3:09)

Drawing in HTML Canvas

Lesson 5: (1:15)

Using Websockets with Web3

Lesson 6: (3:09)

Web3 and Events Over WebSockets

Lesson 7: (3:41)

Drawing Pixels from the Blockchain

Module 3: Buying Pixels

Lesson 1: (1:57)

Buying An Image -- Reading Pixels

Lesson 2: (4:51)

Buying An Image -- Sending Transactions

Lesson 3: (1:25)

Pixel bidding and structs

Lesson 4: (2:48)

Payable Contracts, payable Functions

Lesson 5: (3:35)

Contract Owner and require

Lesson 6: (2:38)

Payable color pixel function

Module 4: Auctioning Pixels

Lesson 1: (4:03)

Sending funds from a contract

Lesson 2: (3:26)

The safer way to send funds from a contract

Lesson 3: (4:37)

The Pull Payment Pattern - Withdraw payments when outbid

Lesson 4: (6:46)

Million Ether Homepage Summary

Getting The Pixels and Ethereum Events