Thursday, May 10, 2012
Can a programming language be copyrighted?
If you haven't done so already, please don't forget to fill in our survey on the copyrightability of programming languages: the results are due to be published soon!
Max length increased for Javamex forum
The maximum allowed length of entries/comments on the Javamex blog has been increased. It has come to my attention that the previous length was a little short for adding questions plus sample code. If anyone still has trouble posting their question, then please contact me or leave a comment here.
Wednesday, May 9, 2012
Hash codes again: picking the right horse for the course
An interesting question on the Javamex forum concerning hash codes.
Tuesday, May 8, 2012
Using BufferedImages in Java: what type gives fastest performance?
The first pages of a new section on graphics programming in Java includes some information on the performance of different types (formats) of BufferedImage.
As you will be aware if you have used this class, BufferedImage provides a range of different internal formats, specified by a constant at the type of creating the image object. Sometimes it can be non-obvious which format to opt for among apparently functionally similar choices. For example, TYPE_3BYTE_BGR vs TYPE_INT_RGB are functionally similar, as are TYPE_INT_BGR vs TYPE_4BYTE_ABGR. But is there any performance difference between using an int or separate bytes per component? And how much of a peerformance hit is it to include an alpha (transparency) component?
Or perhaps it is better to opt for one of the USHORT types allowing storage in only 2 bytes per pixel, thus requiring less data throughput and presumably higher performance?
As an example, some actual performance tests of BufferedImage.setRGB() are given. Integer storage is shown to be better performing overall than byte-by-byte storage, as is maybe to be expected. But on the test system, a perhaps surprising finding is that when combined with integer storage, including a transparency component actually increased performance, presumably because this combination is closest to the native image format used on this system. Despite the throughput argument, 1- and 2-byte per pixel formats performed poorly. The moral of the story is that measurement is as important as common-sense assumptions!
Comments/discussion about BufferedImage are welcome here or in the corresponding page of the Javamex forums.
As you will be aware if you have used this class, BufferedImage provides a range of different internal formats, specified by a constant at the type of creating the image object. Sometimes it can be non-obvious which format to opt for among apparently functionally similar choices. For example, TYPE_3BYTE_BGR vs TYPE_INT_RGB are functionally similar, as are TYPE_INT_BGR vs TYPE_4BYTE_ABGR. But is there any performance difference between using an int or separate bytes per component? And how much of a peerformance hit is it to include an alpha (transparency) component?
Or perhaps it is better to opt for one of the USHORT types allowing storage in only 2 bytes per pixel, thus requiring less data throughput and presumably higher performance?
As an example, some actual performance tests of BufferedImage.setRGB() are given. Integer storage is shown to be better performing overall than byte-by-byte storage, as is maybe to be expected. But on the test system, a perhaps surprising finding is that when combined with integer storage, including a transparency component actually increased performance, presumably because this combination is closest to the native image format used on this system. Despite the throughput argument, 1- and 2-byte per pixel formats performed poorly. The moral of the story is that measurement is as important as common-sense assumptions!
Comments/discussion about BufferedImage are welcome here or in the corresponding page of the Javamex forums.
Wednesday, May 2, 2012
iPad advertising trouble again...
Apple continues to meet with pressure over the advertising of the iPad 3. This time, it's the turn of the UK's Advertising Standards Authority to pressure Apple into removing references to "4G".
Subscribe to:
Posts (Atom)