Hello everyone, an update this way comes!
Version 1.1.7 of the Polargraph Controller brings some significant fixes AND a couple of new features.
- Density Preview Styles. This is a naive attempt to make the density preview look a bit like the square wave pixel drawing style. It uses diamond-shaped squares instead of round spots.
It also uses transparency to give a kind of preview of what happens when they overlap (more on overlapping next). I was a bit reluctant to add this mode, because it implies that the controller is able to give a preview of what the rendered drawing will look like, rather than simply giving a view of what detail has been captured. But even though it isn’t perfect, it might be useful. It is the new default, but adding controller.density.preview.style=0 to the config file will make it use circles instead.
- Pixel scaling. A customer asked about this image that appears to use a pixel that is scaled AND has variable frequency. I said of course, there are no secrets in this project, anything I can do you can do. But then remembered that that drawing was the result of Tinkering, long ago, and there was no way to do this without more Tinkering though it is a good effect. It was essentially a way to get detail in without obliterating everything else on the page. Kind of worked.
So I’ve added a Scale Pixel function that will allow you to multiply the size of pixel that get’s drawn. A value of 1.0 means the pixel is the same size as the grid – just as it always has been.
A value less than 1.0 makes them smaller than the grid, values larger than 1.0 makes them larger than the grid. This was designed to be used with variable freq square wave, so your mileage may vary when using it with scaled pixels.
- Crash Fixes! This is quite a good one, and worth having if you are working with big queues. This fixes the crash that often occurs when adding large numbers of pixels to an existing queue. The issue was a ConcurrentModificationException when attempting to read from the command queue to draw it on the screen and adding to the command queue at the same time. Not allowed to do that. There are thread-safe versions of the List I use, but they are slow in themselves, so all I did is catch the exception and ignore it and continue on. The issue is entirely limited to how accurate the command queue will look, on-screen, for a couple of milliseconds, so I am happy to behave badly with that one. HOWEVER, it is unlikely to come up again anyway, because…
- Performance is improved with long queues. Previously it would write out all the entries in the queue, even if they weren’t on the page. Now, writing anything to the screen is pretty slow, so this has been made 500 times faster (literally) by not doing that unless there’s something to show. It was pretty lazy coding anyway.
If there’s any issues, please let me know.