985: Good Lord (I don't care what you're doing)
First things first, don't forget today is April Fools. Time for some of the crappiest pranks around as people who only realise an hour before try to create some elaborate scheme, and fail miserably and end up with "So yeah, I've sold the website to my sister and she's going to turn it pink." Yeah, that day. Still that said, the award for the best use of April Fools, thus far, goes to Phoenix Requiem. Epic winz!
So. Yesterday. I started work on what was possibly the hardest part of my Java project, but mainly because I knew so little of how to do it. Yes, I wanted to save my flipbook projects. After a couple of hours, I had a working system that used ImageWriter to write to an ObjectStream - multiple times. This was all fine and dandy. Sure, the CPU usage shot up to 25% for a second, but it quickly went down. The problem herein lies with the loading of said images. Using entire the reverse operation, I used an ImageReader on an ObjectStream. It loaded fine - but it used 40% CPU, a lot bigger than the writing. But it gets worst, after it had reached 40% it dropped to 30% and then stuck there. At first, I was thinking, well, this isn't entirely unacceptable... its not like its using more than 50% at any point.
Then it hit me: I have two CPUs... so if this were to run on a single CPU, that would be about 80%. And then couple that with the fact that the DCS computers are pretty basic, well, I think you can see where this is heading. I had another idea, but it took me a while to implement it. I was thinking, how about I use ZIP files? Fortunately Java comes with a ZIP library. Unfortunately, Java comes with a crap ZIP library. Hours of messing (it was now about 8pm) still produced no results. It would make a ZIP file fine, it would make the images fine - and if I opened them up in WinZIP, I could see slide0, slide1 and these would load as images in IrfanView. Only when I pressed load, it would throw an IOException: Image not valid.
At 10, the next idea I had was to be a very basic write the bytes to the file, and then include some integer offsets, ie: [Header][ImageSize][Encoded Image][ImageSize][EncodedImage] - rinse and repeat. This was all fine and dandy, but for some godforsaken reason, althought it could encode BufferedImages fine, it would not encode a BufferedImage that had been passed from another object. It was at 11:40 last night, I finally got things working in a really big workaround way, using object streams and a wrapper around the bytes for the image. And you know what, yes, it works.
Oh manz, what a waste of a day. I guess at least I know a little more about Java. Shame that what I know is there are quite a few libraries that are just plain "teh suck".
So. Yesterday. I started work on what was possibly the hardest part of my Java project, but mainly because I knew so little of how to do it. Yes, I wanted to save my flipbook projects. After a couple of hours, I had a working system that used ImageWriter to write to an ObjectStream - multiple times. This was all fine and dandy. Sure, the CPU usage shot up to 25% for a second, but it quickly went down. The problem herein lies with the loading of said images. Using entire the reverse operation, I used an ImageReader on an ObjectStream. It loaded fine - but it used 40% CPU, a lot bigger than the writing. But it gets worst, after it had reached 40% it dropped to 30% and then stuck there. At first, I was thinking, well, this isn't entirely unacceptable... its not like its using more than 50% at any point.
Then it hit me: I have two CPUs... so if this were to run on a single CPU, that would be about 80%. And then couple that with the fact that the DCS computers are pretty basic, well, I think you can see where this is heading. I had another idea, but it took me a while to implement it. I was thinking, how about I use ZIP files? Fortunately Java comes with a ZIP library. Unfortunately, Java comes with a crap ZIP library. Hours of messing (it was now about 8pm) still produced no results. It would make a ZIP file fine, it would make the images fine - and if I opened them up in WinZIP, I could see slide0, slide1 and these would load as images in IrfanView. Only when I pressed load, it would throw an IOException: Image not valid.
At 10, the next idea I had was to be a very basic write the bytes to the file, and then include some integer offsets, ie: [Header][ImageSize][Encoded Image][ImageSize][EncodedImage] - rinse and repeat. This was all fine and dandy, but for some godforsaken reason, althought it could encode BufferedImages fine, it would not encode a BufferedImage that had been passed from another object. It was at 11:40 last night, I finally got things working in a really big workaround way, using object streams and a wrapper around the bytes for the image. And you know what, yes, it works.
Oh manz, what a waste of a day. I guess at least I know a little more about Java. Shame that what I know is there are quite a few libraries that are just plain "teh suck".