# Update: Painter

Recently I wanted to make some pixel art for a mobile version of my website (which is very different to anything I’ve done before, and more confusing than I thought it would be.) To do that I decided to use the Painter tool (Live page) I’d written a few years ago. Unfortunately the tool no longer worked, for reasons that I’m still trying to debug. (Possible to cross-domain restrictions when using the full path, but more likely due to the limits of the GET request.) The old method used PHP to generate the image, and the HTML DOM to manage the editing, using an HTTP request when the image needed to be generated. It’s not hard to see why this is inefficient, so once the canvas became available I decided to transition from PHP to JavaScript and the canvas.

Given my previous experience with the canvas it didn’t take long to code up a new version of the painter, and the biggest challenge was extending the scope of the line paintbrush to create lines at any angles, not just vertical or horizontal. The updated look is more sleek and professional, the performance is better, and there are fewer failure modes. I’ve kept the legacy version for interest, but I have no plans on using that again. I am also considering adding two new featuers in the future: allowing the user to save their image to an online database, and allowing the user to upload an image so they can edit existing images pixel by pixel.

# Recycling old solutions

A few years ago I found myself in need of a simple program to make pixel art. At the time I had access to the PHP suite of graphical libraries, and the ability to manipulate the HTML DOM, so armed with these tools I put together a simple tool that would allow me to create small images online, which I called the Painter. It was not particularly efficient, but it got the job done, and did so for free. (Now that the HTML canvas is supported pretty much everywhere that tools needs to be rewritten for the latest generation of browser technology.) During the development of this tool I found myself wanting to solve the following problem: Given a two dimensional rectangular array of squares, how can I find all squares that reside within a given boundary? It’s a fairly straightforward problem, but one that requires keeping track of two lists of squares, and one that should scale, as far as possible, with $$n^2$$ or lower. After some head scratching and experimenting with a few lines of code I found the solution I needed, tweaked it a bit, and was fairly impressed with its elegance.

Then a few years later I was talking with my current boss and she said something along the lines of “You shouldn’t take on these extra projects, they take up your time and distract you.” It’s a fair point that with over 50 coding projects, and about a dozen more nebulous and time consuming projects, I have a lot on my plate, but on the other hand they serve some very useful purposes that I can’t get elsewhere. One of the most useful contributions they give is that they are often the first testing ground for solving problems. The lessons I learn in Javascript, PHP, and python are often directly applicable to my physics work.

A few months ago I found myself having to deal with the CMS Preshower system. I wanted to make a map of the system to that I could visualise how it looked in three dimensions. The only things I really knew as that it was arranged in a grid of square components (each square component subsequently arranged in strips) and that I had a tool where if I could access a single square I could access all of its neighbours. Since the physical extent of the preshower system gave me an obvious boundary I found myself with a very familiar sounding problem… Without even needing to look up the code from the Painter tool I wrote down the solution in a few lines and in about 10 minutes. What may have taken me a few hours of framing the question, determining how to find the solution, and subsequently implement it was reduced to a trivially solved problem with a minimal footprint of CPU time and memory. This later lead on to the development of the $$\eta-\phi$$ map, which is still under development and may eventually lead to more breakthroughs for the CMS experiment.

I make it a point to not invest much time in a project unless it’s going to teach me a new skill or show me how a new technology or feature works. By exploring what was possible with a few rudimentary tools I was able to unwittingly give myself the solution to a real world problem that saved a lot of headaches and time. Whether the extra projects are worth the extra time is a different discussion entirely (I personally think they are, and also think that what I learn in physics programming today I can use in private enterprise tomorrow) and one that deserves some serious thought. For now I am happy that I have a huge pool of experience to draw on that only keeps growing in time.

# Painter

Many years ago I wanted to make a platform game (I still do) and I needed to be able to make simple and small graphics quickly and easily. Once I realised I could manipulate images using PHP it became easy to create a simple application to make pixel art.

### Overview

The user can create an image pixel by pixel, or with rectangles of colour, or using a simple fill function. The pixel data are stored in an array and when the user asks for the image to be generated the data set sent via a POST request to the server, which then interprets the data and returns a png file.

The drawing area is arranged as an HTML table with event listeners waiting for user input. There is also a thumbnail display that consists of a similar table with cells 1px in width and 1px in height. The user can choose the colour, and choose which “brush” to use (brush, line, rectangle, fill).

### Challenges

Challenge: The page needs to able to respond to the user’s interactions quickly and efficiently.
Solution: The user interaction is handled with a series of automatically generated eventListeners which parse element ids. This works well enough, but it really needs to be replaced with a single event listener and handled with a single element instead of a large array of elements that take up more CPU time and memory. This can be handled by using the canvas instead of an HTML table. (Resolved, to be replaced)
Challenge: The image needs to be generated for the user.
Solution: At the moment the painter uses PHP to generate an image pixel by pixel. This is a very inefficient way to generate the image, as it requires a large bandwidth and for very large images, a lot of server CPU time. This should be replaced with client side processing to remove these uncesseary overheads. (Resolved, to be replaced)
Challenge: The user needs to be able to select a colour from a rich palette.
Solution: This project made me realise how difficult working with colours spaces is. A full colour space can’t be easily represented in two dimensions, so I need to create a colour cube and show slices, making the space somewhat counter intuitive. It works, but it would be nice to develop other respresentations. As with the drawing space, the colour palette should be replaced by a single canvas element. (Resolved, to be revisted)