Title: Graphics Development In occampi
1Graphics Development In occam-pi
Aims Of Project
To develop the occam-pi graphics library To test
the libraries capabilities, including its
rendering speed To develop my skills in
concurrent programming
Samantha Davis sld5
2Graphics Development In occam-pi
Starting Point Of Project
Samantha Davis sld5
3Graphics Development In occam-pi
Programming
I started off with basic graphics drawings,
starting with drawing rectangles, squares and
discs. The programming for squares and discs was
used a basis for a Brownian Motion study. I
modified the square programming to draw discs,
and used these discs (as well as raw pixels) for
visualising particles in my work.
Samantha Davis sld5
4Graphics Development In occam-pi
Initial Program
The set up of the initial program was done so
that a graphics process did all the drawing on
the raster. Each particle sent its co-ordinates
and colour through a shared channel to the
graphics process. The graphics process changed
the raster, and then passed it to the
gridlink.process process. The only user
interaction, is the initial screen size, the
start size of the starting space for the
particles, and the ability to pause the
rendering.
Samantha Davis sld5
5Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
6Graphics Development In occam-pi
2nd Program Development
For the second stage of development I have given
the job of drawing on the raster to a chain of
processes separate to the graphics process. The
graphics process coordinates them simply by
sending the raster (which is a mobile array)
through the chain and back to itself. There is
one drawing process for each particle process.
Samantha Davis sld5
7Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
8Graphics Development In occam-pi
2nd Program Development
In this program, I have also added in the ability
to draw discs as well as particles. To deal with
this, I have extended the user interaction so
that they can pick the size of the discs radii
(by typing 0-9 where 0 means no disc, just a
pixel). To cope with this change, I have added an
additional process which listen for keyboard
presses, and sends the radius size to every
particle process or if the freeze is activated,
it sends a pause to the graphics process.
Samantha Davis sld5
9Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
10Graphics Development In occam-pi
Radius Development
The next development only concerned hastening the
delivery of a user-changed radius to the particle
processes. Having those processes poll for a
possible radius change took too long because we
have to wait for each particle to be scheduled
and then for the keyboard.monitor which only
takes around 10 msecs (depending on where those
processes are in the run-queue) but we have to
do this 10,000 times which takes around 100
seconds!
Samantha Davis sld5
11Graphics Development In occam-pi
Radius Development
Instead there is a separate process,
radius.control, which changes a radius variable
that is SHARED between the particle processes and
radius.control.
Samantha Davis sld5
12Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
13Graphics Development In occam-pi
Radius Development
This is dangerous and illegal it breaks the
strict parallel usage rules of occam-pi! We
cannot allow freely some processes (e.g. the
particles) to use a variables value while
another process (e.g. radius.control) is changing
it.
Samantha Davis sld5
14Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
15Graphics Development In occam-pi
Radius Development
To solve this problem, on each cycle of its
programming the radius.control polls the
keyboard.monitor for a possible radius change and
updates radius accordingly then it synchronises
twice on the barrier.
The particles are programmed to update their copy
of radius only every other time they go around
their loop. Thus, they read the shared radius
only when radius.control is guaranteed not to be
changing it.
Samantha Davis sld5
16Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
17Graphics Development In occam-pi
Radius Development
The punch line is that user-changes to the radius
value now are taken notice by the particle
processes instantly well, within two
round-robin schedulings of all (20,000) processes
about 20 msecs!
Samantha Davis sld5
18Graphics Development In occam-pi
3rd Development
The next development of the program, involves
incorporating good aspects from both of the
previous programs. It goes back to the idea of
just one process changing the raster. Instead of
this being the graphics process, it is now a new
drawing process. This process still receives the
raster from the graphics process, and sends it
back after it has altered it. The particles pass
their co-ordinates, colour and the size of their
radius, through a SHARED channel to the drawing
process. Programming in this way ensures that
performance is made flexible allowing us
freedom to install many different kinds of
drawing processes.
Samantha Davis sld5
19Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
20Graphics Development In occam-pi
Performance Comparison
Samantha Davis sld5
21Graphics Development In occam-pi
Further Than Browning Motion
Once I had researched three different ways of
programming the Brownian Motion theory, I
started to develop blocks to put in the way of
the particles, to restrict their movement. I have
adapted one of my programs to incorporate placing
different blocks and pathways in the way of the
particles.
Samantha Davis sld5
22Graphics Development In occam-pi
Further Than Browning Motion
This program includes a new process that draws
the blocks to the raster (block.drawer). The
particles are provided with (the same) 2D-array
of BOOLs, which has the same dimensions as the
drawing raster and defines which areas of space
are blocked off to the particles. Each time a
particle changes position, it checks to see if
the move is legal. If its not (if it moves the
particle into a block or outside the screen
boundary), it has to bounce. I have been looking
at how these blocks affect the particles
movement, and the programs performance.
Samantha Davis sld5
23Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
24Graphics Development In occam-pi
Network Diagram
Samantha Davis sld5
25Graphics Development In occam-pi
Screenshots
This screenshot shows 1,000 discs moving in
accordance with the Brownian Motion.
This screenshot shows 10,000 particles moving in
accordance with the Brownian Motion.
Samantha Davis sld5
26Graphics Development In occam-pi
Screenshots cont
This screenshot shows 10,000 discs with a radius
of 3, being restricted by the same blocks
This screenshot shows 10,000 particles, being
restricted by two solid blocks
Samantha Davis sld5
27Graphics Development In occam-pi
Learning Outcomes
- To investigate the dynamic construction of the
concurrent drawing processes. - To learn more about designing dynamic concurrent
systems.
Samantha Davis sld5
28Graphics Development In occam-pi
Further Aims
Additional areas of work could include -Further
investigation of using new mobile programming to
aid in possible performance upgrades. -Development
of intelligence in the particles, moving through
mazes, and possibly learning from where its
been -Using the programs I have already
developed, adding graphics such as lines,
rectangles, squares, triangles etc.
Samantha Davis sld5