Hi, Andrew. The fix looks good then. > my preference is to leave the seek(bitmapStart) in the read() method > in order to reduce potential overhead because readHedaer() is called > very often.
On 9/8/2014 7:31 PM, Sergey Bylokhov wrote: > Hi, Andrew. > I am not an expert in this area, but probably the bug can be fixed in > the readHeader itself? Because currently it call > iis.skipBytes(bitmapOffset) at the end only for the first time. > > On 03.09.2014 16:23, Andrew Brygin wrote: >> Hello, >> >> could you please review a fix for CR 8041465? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8041465 >> Webrev: http://cr.openjdk.java.net/~bae/8041465/9/webrev.00/ >> >> The problem happens if we perform multiple read operations from >> a source which is set only once. For instance, we can try to read >> image in several tiles. >> >> The root case of the problem is that we set stream position >> to the start of raster data only once: when we complete >> the processing of BMP header. A peculiarity of BMP format >> is that raster data can be stored in reverse order, so if we >> request few leading scanlines first, then we skip rest of raster >> data, and subsequent read command does not copy anything to the >> destination buffer, because we never re-set the stream position >> to the start of bitmap. >> >> Suggested fix just saves the bitmap's start postilion and seeks >> the stream to to it each time when we read image. This change >> makes the BMP reader behavior exactly same as other standard plugin >> demonstrate. >> >> Supplied regression test demonstrates the problem. >> >> Please take a look. >> >> Thanks, >> Andrew. > >
