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.
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.
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.
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.
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).
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)