Open GoogleCodeExporter opened 9 years ago
Owner changed.
Original comment by r.biedert
on 7 Sep 2010 at 3:22
@1: Run two benchmark-suites to verify any performance differences between
writing the data with an ObjectOutputStream, xstream.toXML() and
xstream+Converter
Results: xstream+converter are 2,3 to 2,9 times faster than using our
ObjectOutputStreams.
But to be able to use the converters for reading, all event converters have to
implement all get and set methods for their internal variables (e.g.
EyeTrackingEventContainer has no set methods at all and missing get methods for
the variables "validity" and "version").
@2: I compared the PNGEncoder http://objectplanet.com/pngencoder/ with the
encoding from java ImageIO.
Results: PNGEncoder is about twice as fast as ImageIO.
But I still vote for the usage of Jpeg instead of PNG for desktop/browser
screenshots.
1. The Jpeg files are smaller (80% quality settings) and afaik the conversion
is hardware accelerated (could be wrong).
2. The generated PNGs were sometimes bigger than the uncompressed *.tiff files
regardless of the PNG encoder (Apple Preview, PNGEncoder, ImageIO)
Still have to look for a good PNG decoder and doing benchmarks...
Original comment by arman.va...@gmail.com
on 12 Oct 2010 at 6:09
After implementing the missing getter/setters/constructors for
EyeTrackingEventContainer.java I did another test.
Generating 1000000 sample data in 1.374s.
ObjectOutputStream benchmark without converter took 115.635s.
ObjectOutputStream benchmark with converter took 54.044s.
ObjectInputStream benchmark without converter took 99.019s.
ObjectInputStream benchmark with converter took 32.57s.
The benchmarks speak for themselves I think.
Original comment by arman.va...@gmail.com
on 18 Oct 2010 at 12:32
Do it so :-)
Original comment by r.biedert
on 18 Oct 2010 at 4:34
Do it so :-)
Original comment by r.biedert
on 18 Oct 2010 at 4:34
PNG codec is currently set on hold...
Included a converter for EyeTrackingEventContainer. Other converters might in
the upcoming commitments.
Original comment by arman.va...@gmail.com
on 27 Oct 2010 at 1:54
ARRRRRRRRRR-man, check that converter can deal with NULL types for the various
fields please *g*
Original comment by r.biedert
on 21 Feb 2011 at 5:54
E.g., like this:
<EyeTrackingEventContainer>
<originalEventTime>10513</originalEventTime>
<combinedCenter>
<x>556</x>
<y>449</y>
</combinedCenter>
<leftEyeDistance>0.0</leftEyeDistance>
<pupilSizeLeft>0.0</pupilSizeLeft>
<pupilSizeRight>0.0</pupilSizeRight>
<rightEyeDistance>0.0</rightEyeDistance>
<validity>true</validity>
<version>1</version>
</EyeTrackingEventContainer>
Original comment by r.biedert
on 21 Feb 2011 at 5:55
Please choose: The bug occurs
[ ] while reading
[ ] while writing
[ ] doesn't matter.
;)
Original comment by arman.va...@gmail.com
on 21 Feb 2011 at 6:08
Please choose: The bug occurs
[x] while reading
[x] while writing
[ ] doesn't matter.
Actually I'm not sure if its (or should be considered as) a reading or writing
bug, probably rather a reading bug.
Original comment by r.biedert
on 21 Feb 2011 at 7:11
I've sent you a new version of the converter... It should check while reading
whether the strings in the XML/XStream file are null and set some dummy values
if necessary...
Original comment by arman.va...@gmail.com
on 21 Feb 2011 at 7:15
Original issue reported on code.google.com by
r.biedert
on 6 Sep 2010 at 3:40